SAFU: Creating a Standard for Whitehats

The great irony of technology is that every new solution either dies a technical problem or lives long enough to become a social problem. This is obviously true for traditional tech companies, but the same dynamic is fast becoming apparent in crypto as usage grows. The question in DeFi, for instance, is no longer how to drive demand but how to handle the failure modes when that demand arises. Nowhere is this more important than in protocol security, where over $5 billion to date has been lost through hacks, exploits, and other vulnerabilities. While we can design for robustness with tools such as bytecode verification and formal specification, as well as thorough manual audits, human fallibility guarantees that something will always slip through the cracks.

Fortunately, crypto also benefits from one of the world’s most impressive whitehat communities,  ready to leap into action and help teams defend themselves against critical vulnerabilities. Whitehats, or ethical hackers, search for latent security issues in a protocol or platform and work with its developers to correct these issues before they can be exploited. However, the current state of DeFi security presents daunting obstacles to any would-be savior:

1. Legal uncertainty: While most protocol teams offer some grace period after an exploit for a hacker to declare themselves a whitehat, there are no guarantees, and a team could always decide to take legal action. Security researchers have always lived with this risk - even the basic notion of good-faith security research only received official recognition earlier this year - but the stakes are far higher when user funds are involved.
2. Lack of clarity: Assuming good faith on the part of both the whitehat and the protocol team, there is still the question of what to do with the funds received through an exploit. Are they to be returned to the original protocol address or sent to a newly created address? If protocol governance is decentralized, who speaks for the protocol and can that person be trusted with users’ capital?
3. Execution risk: The response to an exploit is generally conducted in the fog of war - a state of extreme urgency and confusion. Conflicting proposals or instructions (possibly including impostors or fraudulent addresses) may lead to mistakes that are hard or impossible to reverse.

While bug bounties help protocols establish a known process and encourage responsible disclosure, they are only part of the solution. Early-stage protocol teams may not be able to provide sufficiently large bounties, or if they do, whitehats may not trust the team to fulfill their commitments. Furthermore, many vulnerabilities (such as those produced by an upgrade) may be too urgent for a whitehat to rely on the multi-day communication cycle that bug bounties require. In extreme cases, as with the Nomad hack involving over 300 addresses, there may only be time to replay an active exploit with a different recipient.

What we need is a way to reach a common understanding - ideally, one agreed upon and communicated before the exploit. Our previous piece, Whitehats and Dropboxes, proposes just that: a “dropbox” at a pre-announced address that can serve as the receptacle for preemptively secured funds. Nonetheless, several questions remain:

• Will whitehats trust the protocol team enough to use the dropbox? If a reward is promised, how do whitehats know it will be honored? Governance alone offers few guarantees. For instance, Tribe DAO backtracked on repaying victims of the $80M Rari hack before finally agreeing after the fourth vote.
• How can we create effective norms that both whitehats and protocols support? If every protocol creates its own policy, whitehats may not have the time or resources to review these policies properly, and flaws or ambiguities may not become apparent until it is too late to fix them.

To solve these issues, we introduce the SAFU, or Simple Arrangement for Funding Upload.

Read on for a deeper discussion of the inspiration and design principles of the SAFU project, or dive directly into our reference implementations with policy statements and Solidity contracts on Github.

SAFU: Simple Arrangement for Funding Upload

The SAFU is intended as a simple yet extensible way to specify a post-exploit policy for whitehats, particularly rewards and distributions. It comprises two elements, for which we provide general guidelines as well as reference implementations:

1. Statement for Whitehats: A clearly and simply phrased declaration from the protocol team that commits not to take legal action against whitehats. The Statement also specifies several key policy elements:

• Source addresses from which funds may be taken in the event of a vulnerability
• Dropbox address or contract to which funds should be deposited
• Reward claimable by whitehats, specified as a percentage with an optional cap
• Conditions required to claim, along with evaluation process and timeline for resolution

2.  Dropbox for Protocol Funds: An address or contract to which funds taken from the protocol should be deposited. Dropbox contracts may be automatic, handling claims and rewards on a per-depositor basis without human input, or conditional, requiring additional input such as governance approvals or identity verification. The current address should always be listed in the Statement, and the Dropbox parameters should mirror the conditions spelled out there.

Taken together, the Statement and Dropbox provide a standardized yet flexible framework that any protocol can use to encourage the safe return of user funds. We believe this solution is vastly superior to post-exploit negotiations, which often amount to “take it or leave it” offers the protocol has little choice but to accept.

While it is not yet a formal legal contract, as the regulatory environment of DeFi must settle to make such a contract practical, we believe the SAFU will serve as an important step providing better technical, legal, and economic clarity in precisely the moments where it is most needed.

The Need for a Common Understanding

As outlined in our previous piece, the playing field of crypto security has evolved faster than the rules governing it. Not only is there a legal gray area surrounding the activities of whitehats, but there is no clear standard of behavior for what an ethical hacker should do after uncovering a critical vulnerability. Sufficiently high-profile hackers can create their own policies (including the dreaded “u up?” a la samczsun), but this is neither effective nor scalable for ordinary researchers.

We view the status quo as a coordination problem, one which is natural given the pace of change in DeFi, but one which must be addressed before the industry can mature. Rather than scrambling to respond in the moment, teams must pre-communicate what whitehats should do in the event of a crisis (via the Statement) and pre-commit to honoring that policy following an exploit (via the Dropbox). Establishing a set of shared norms – where policies are clearly stated up front, and both whitehats and users feel fairly treated – will enable the crypto industry to provide better assurances for protocols and their customers.

With the SAFU framework, we hope to create a Schelling point to which participants can default in the absence of communication. Naturally, anyone can create a standard (and many inevitably do), but in this case we believe there is a particularly powerful model to inspire our approach: Y Combinator’s SAFE, or Simple Agreement for Future Equity.

SAFE, SAFT, SAFU

To present a stylized origin story, in the dark ages of pre-YC venture capital, each firm created its own customized term sheets, even for extremely early-stage companies. First-time founders often possessed neither the background nor the legal resources to properly understand the proposed terms, and unscrupulous investors could take advantage of their naiveté with subtle methods such as dilution and liquidation preference.

The introduction of the SAFE by YC in 2013 solved this lack of standards. This instrument, which essentially offers a streamlined form of convertible debt, enabled founders to understand term sheets easily and compare offers on an apples-to-apples basis. [1] Terms could be communicated in a single sentence - a $1M SAFE at a $20M cap requires no explanation - allowing founders and investors to interact with one another transparently and efficiently.

Similar early-stage issues often arise in crypto, especially when token offerings take place at the beginning of a protocol’s lifecycle. Protocol Labs’ SAFT, which replicates the SAFE for token raises, has thus seen similarly wide adoption since its introduction in 2017. Together, SAFEs and SAFTs render a broad and complex topic (early-stage investment) immediately understandable, solving one of its primary coordination problems by providing a standardized framework that is nonetheless adaptable to the full range of standard concerns. By introducing the SAFU, we hope to accelerate that same process in crypto security research.

Design Principles

What qualities do we need to ensure in order to provide a similar combination of simplicity and adaptability? We see at least two major variables over which any solution should generalize:

1. Trust in the protocol: Must handle different levels of human involvement. On one extreme, a zero-trust approach requires a fully automated dropbox contract, which dispenses rewards and returns funds with no human interaction even if the team itself is untrusted. On the other, a high-trust approach would allow one or more designated addresses (governance, multisig, etc.) to exert granular control over every claim.
2. Commitments from whitehats: Must handle different levels of whitehat disclosure. A fully anonymous solution must allow any address to deposit and claim, whereas a full-disclosure approach may require whitehats to pass a compliance/KYC screening, be approved by governance, and/or fulfill additional obligations such as incident write-ups.

Embedded in these two axes are all the usual “crypto properties” such as decentralization, trustlessness, permissionlessness, and sovereign identity. Additionally, since areas such as governance and identity are complex topics with dedicated and rapidly evolving solutions, a well-designed dropbox should compose well with any of these, including future releases.

On that note, we also aim to fulfill the following design principles:

1. Simple: Should be possible to summarize the full scope of the policy in a single sentence.
2. Explicit: Should provide clarity on the legal and economic intentions of the protocol, as well as the technical implementation of the contract (open-source).
3. Sensible: Should offer defaults that work for most protocols with little or no adaptation.
4. Flexible: Should accommodate different levels of trust, conditionality, and anonymity.
5. Credible: Should be clear what conditions must be fulfilled to claim rewards, and what minimum reward can be guaranteed for a given level of valid deposits.
6. Non-exploitable: Should, at a minimum, prevent untrusted (non-protocol) entities from cheaply sabotaging the contract’s intended function, for instance by diluting or delaying rewards. A fully automated dropbox should prevent sabotage by all entities, owner/protocol included.

Stay SAFU: A User’s Manual

A SAFU consists of a Statement and a Dropbox, but within those bounds a protocol has considerable discretion over the process governing rewards and return of protocol funds. Below, we outline the key choices the protocol team will need to make when establishing the SAFU.

Statement for Whitehats

The essence of the Statement is twofold. First, it involves a commitment not to pursue legal action against whitehats who act in accordance with the Statement. Second, it involves an outline of the reward policy, the conditions required to fulfill it, and a high-level description of the process and timeline by which claims will be resolved. More precisely, we expect most protocols will specify the following:

• Reward policy: A portion of deposited funds to which whitehats are entitled, typically specified as a percentage (e.g. 5% of funds) or capped reward (e.g. 1000 ETH). These may be denominated in a total amount or on a per-token basis, though we expect that the Dropbox itself will use per-token specifications to avoid oracle dependencies.
• Timeline: The sequence of events by which funds can be deposited and claimed. For clarity, we encourage protocols to resolve claims on a case-by-case basis, not an event basis (for instance, did the Nomad exploit constitute one hack or 300?). A basic timeline includes:

1. Deposit interval - the grace period in which a sender must deposit funds in the Dropbox after removing them from the protocol. Direct and immediate transfers are likely preferable from a legal perspective, but this may not be possible in all cases.
2. Claim delay - a minimum waiting period before a sender may claim rewards. We recommend at least 24 hours, during which the extent of an exploit will become clear.
3. Sender claim interval - a maximum waiting period after which the protocol may reclaim the sender’s reward, to avoid leaving funds stranded in the contract.

• Sender approval process: The steps, if any, a sender must complete (such as identity verification) in order to claim funds. Should specify how the process will take place (governance vote, emergency council, Kleros court, etc.), who will be responsible for approving claims, and the maximum delay after which decisions will be made.

The Statement should be displayed prominently and publicly by the protocol (e.g., top-level link on website or Twitter bio), and ideally should incorporate some form of verifiable history allowing observers to know exactly what was posted at the time of an exploit. We recommend Arweave, but any “write once, view forever” solution will do.

Dropbox for Protocol Funds

In the simplest case, the Dropbox can be nothing more than a pre-specified address controlled by the protocol, e.g. via multisig or governance. However, we believe that a smart contract, such as the templates offered through the SAFU repo, will help protocols build trust in the return process by specifying rewards and dependencies unambiguously in code. In that spirit, we define an interface with the following functions (technical specification in GitHub):

• Deposit: Accepts tokens, registers the sender, and updates the per-token allocated reward according to specified pro rata and cap.
• Claim: Disburses sender’s share of currently unclaimed rewards. Requires that sender claim delay has elapsed, sender is approved if necessary, and (if claim interval has elapsed) the reward has not yet been reclaimed by the protocol.
• Bounty: Shows potential bounty and current approval status for a given deposit.
• Withdraw and WithdrawToken: Disburses protocol funds, excluding any allocated sender rewards (unless past claim cutoff).
• ApproveBounty and DenyBounty: Approves/denies claim for a given deposit; intended to be called after the completion of any identity verification or other sender-specific processes.

Our implementation also includes the following parameters:

• BountyPercent (per token): The percent of deposited funds that senders can claim as rewards.
• BountyCap (per token): The maximum amount of funds that can be allocated for rewards. Can be increased by the contract owner.
• Approved (per deposit): A per-deposit approval flag; true by default if no identity verification or other claim approval process is required.

The above interface is meant to cover the full range from no human intermediation (either necessary or possible) to disclosure and governance-based approval for every sender:

• Fully automated: Once the minimum delay has elapsed, a sender may immediately claim their reward, which cannot be limited or denied in any way by the protocol.
• Fully conditional: The contract owner must approve rewards individually for each sender. (We expect this will be preferred or required for protocols working with institutions and/or within a US-centric regulatory environment.)

The interface and our reference implementation, which can accommodate either mode, are available on GitHub.

Caveat Developooor

While we hope that our default implementations will meet the needs of most EVM-based protocols, we encourage developers working with other chains and languages to extend our model. However, we would advise caution when extending functionality or changing the claim process - it is much easier to introduce a vulnerability than to eliminate one. We considered all of the following during the design process:

• Griefing: A malicious sender can cheaply delay claiming of rewards or funds.
• Dilution: A malicious sender can cheaply dilute other senders’ claimable rewards.
• Overpayment: Some sequence of actions causes total rewards to exceed the specified cap.
• Stranded funds: Some sequence of actions produces a permanently locked balance.

As DeFi itself has proven time and again, every mechanism introduces the potential for unintended or exploitative behavior. Don’t make the recovery mechanism the weak link!

Creating a Better Consensus

As any engineer will admit, braving the dark forest that is crypto security carries with it a certain romance. However, the ultimate sign of success in any industry is to become boring - to institute a solution that works so well as to deflect attention elsewhere. As mathematician Alfred North Whitehead wrote, “Civilization advances by extending the number of important operations which we can perform without thinking about them.” Just as SAFEs and SAFTs accomplished this for early-stage equity and token deal structure, we hope SAFUs will serve as a streamlined and easy-to-understand tool to help protocols and whitehats coordinate - with or without the “u up”.

To add a SAFU to your project, just get started with our GitHub repo.

Please feel free to reach out to all of us to share your thoughts or let us know anything we missed! Thanks to the research team at Jump Crypto and especially to Neeraja Jayakumar, Daniel Gerhardstein, and John Nagel for feedback. This note does not constitute financial or legal advice.

Appendix: Our Implementation

We provide a Solidity implementation that can be deployed as either an automated or a conditional dropbox. In the automated mode, whitehats can claim rewards from the dropbox without any discretionary checks. While in the conditional mode, whitehats can only claim rewards after being approved by the protocol. The former is more predictable for both parties, as the interactions between protocols and whitehats are tightly governed by transparent code. However, the latter mode may be desirable for protocols that wish to perform KYC or governance checks, for either compliance or investigative purposes.

In this section, we first describe the implementation, then illustrate certain design elements that (at the price of some complexity) discourage manipulation.

Implementation Lifecycle

To launch, the protocol team deploys the Safu dropbox contract. The following parameters should be specified when initiating the contract:

• the share (bountyPercent) given to whitehats,
• a flag governing whether rewards are claimable automatically or not (autoApprove),
• the minimum time interval the whitehat must wait to claim their share of rewards, and the maximum time interval before the protocol can confiscate the reward back (minDelay and maxDelay, respectively), and
• the governing authority of the contract (authority).

In addition, a protocol may wish to call the function increaseBountyCapForToken at launch.

• By default, the contract sets the cap for all tokens to zero. To incentive whitehats, the protocol should raise the cap for selected tokens. Note that if a bounty is offered in multiple tokens, a whitehat may choose to deposit funds in the token with the highest-value cap unless specified otherwise in the Statement.
• Note that this function can be called as often as desired, and it only will increase the cap for a given token each time. To protect whitehats awaiting their rewards, the cap can never decrease.

Suppose a whitehat finds an exploit in the protocol and secures funds. The whitehat would deposit the funds into the SAFU contract by calling the deposit function, which issues them a receipt for the deposit.

• The receipt is approved automatically if the flag autoApprove is set to true.
• Otherwise, the protocol must manually approve the receipt (perhaps after the whitehat undergoes a check) using the approveBounty function. Note that once a receipt is approved, either automatically or manually, it cannot be disapproved later.
• If the protocol does not approve the receipt, it can call the denyBounty function which deletes the receipt and marks all deposited funds to be claimable by the protocol.

Assuming the whitehat receives an approved receipt, they now wish to withdraw their rewards from the protocol. They do so by calling the claim function, which processes the approved receipts for their deposits that have waited at least the minDelay period of time.

• The whitehat cannot claim prior to minDelay elapsing. In addition, if the whitehat waits too long — until after maxDelay elapses — the whitehat may find that the protocol has taken the whitehat’s rewards. Thus, whitehats should claim their rewards in the window of time between minDelay and maxDelay.
• The whitehat’s reward is related to two variables: the share of funds secured and the total token cap. If the sum of rewards on outstanding and paid receipts does not exceed the cap, then the whitehat gets paid their pro-rata share of funds secured. If the cap is exceeded, then the whitehat receives a pro-rata share of the remaining cap space. This is discussed more in the next section.

Finally, the protocol team may reclaim their own funds. They do so by calling the withdrawToken function for a given token (or the withdraw function, which sweeps all token types). The function works as follows:

• First, compute all funds available from outstanding receipts that either were declined or have exceeded their maxDelay.
• Next, sum the funds, minus the maximum possible payout, for all receipts that were approved and have exceeded the minDelay wait.
• Receipts are deliberately excluded if they have been neither approved nor declined (until maxDelay is reached). This is to incentivize the protocol to make a decision, and to not leave these receipts and their whitehats in limbo.
• Approved receipts that have not exceeded minDelay are also excluded. While this may seem unnecessary, it prevents an exploit vector outlined in the next section.

The protocol can continue to withdraw at intervals. Finally, once every outstanding receipt has crossed the maxDelay threshold, the protocol can sweep all remaining funds — a mix of deposits, unclaimed rewards, and buffer rewards — in the contract.

Finally, we implement a shutdown function that the protocol can call, which prevents new funds from being deposited into the contract. This can help a protocol retire a contract safely, and cannot be undone.

Computing the Payout

The payout logic is designed to issue rewards in proportion to funds secured, subject to an optional cap. To illustrate, suppose a protocol has $100 million in TVL, has offered a 10% share to whitehats, and has set a max cap of $8 million. Moreover, suppose there are three whitehats who deposit in sequence: Alice with $50 million, Bob with $40 million, and Charlie with $10 million.

• If Bob and Charlie deposit during Alice's minimum waiting period (the minDelay parameter), their total potential claims of $5 million, $4 million, and $1 million exceed the cap of $8 million. They all get a pro-rata allocation: Alice gets $4 million for securing 50% of TVL, Bob gets $3.2 million for securing 40%, and Charlie gets $0.8 million for securing 10%.
• If Bob and Charlie deposit after Alice withdraws (i.e. sometime after her minimum waiting period elapses), the allocation is different. In all cases, Alice gets her full $5 million (as 10% of the $50 million secured), because all claimed and potential rewards did not exceed the cap of $8 million at the time of her withdrawal.
• In the latter case, Bob and Charlie's allocations now depend on whether Charlie deposits before or after Bob withdraws.

1. If Charlie deposits before Bob withdraws his reward, they split the remaining $3 million of rewards. Bob gets 80% ($2.4 million) and Charlie gets 20% ($0.6 million).
2. If Charlie deposits after Bob withdraws, then Bob receives the remaining $3 million reward (since he holds the only outstanding receipt) and Charlie earns nothing.

As shown above, this design also creates a strong incentive to deposit early and claim the maximum share of the remaining reward.

Watching the Watchman

The contract logic attempts to enforce good behavior on behalf of both the protocol and the whitehat. Below, we explain five potential issues and how to mitigate them.

1. Griefing: the ability to cheaply stall payouts, either to whitehats or to the protocol. At first glance, a natural design might use some concept of an “incident” (such as a specific hack), which starts with a deposit and ends when some period of time elapses without any deposits. The contract can then compute and disburse rewards. However, a malicious user could take advantage of this design by sending repeated small deposits to the contract, so the incident would never be considered closed. Instead, our contract handles each deposit largely in isolation, with deposits interacting only through the contract's maximum payout cap.
2. Race to Claim: an outcome in which rewards are unfairly weighted towards early depositors. This contract introduces a minDelay parameter before claiming, even for approved receipts, to avoid race conditions between whitehats when rewards are capped. To illustrate, take our earlier example of a protocol with $100 million, a 10% bounty, and an $8 million cap. Two whitehat hackers — Alice and Bob — each secure $50 million within minutes of each other. Without a minimum delay, Alice could claim $5 million, leaving only $3 million for Bob, despite the fact that their contributions were essentially identical. Worse, if there are funds left in the contract, other whitehats would lack an incentive to secure them, as the cap prevents them from earning rewards. By contrast, instituting a minDelay allows all whitehats to secure funds in that interval and be rewarded fairly, e.g. $4 million to Alice and $4 million to Bob.
3. Stranded Funds: an outcome in which funds are permanently locked in the contract. Our implementation features a maxDelay after which the protocol can reclaim all funds from a deposit, including the reward. This is necessary to prevent funds from getting stuck in the contract if a sender fails to claim their reward.
4. Slow Approval: to give the protocol an incentive to complete the approval process (assuming autoApprove is false), we prevent the protocol from reclaiming its own funds on a given deposit until it has approved or denied that deposit. Of course, a protocol can always wait out the maxDelay interval or reject all receipts, but this approach would be both obvious and reputationally costly. Of course, the maximum-clarity approach is simply to set autoApprove to true.
5. Dilution: an outcome in which senders securing funds collectively receive a smaller reward than the share to which they should be entitled. Recall the example in which a protocol has $100 million in TVL, secured by Alice and Bob, with a cap of $8 million. If the protocol is able to withdraw its own funds immediately, it can withdraw and redeposit the non-earmarked $92 million during the minDelay period, massively reducing the overall reward paid to Alice and Bob. To avoid this, we also require the protocol to wait minDelay before reclaiming. Of course, a protocol can still dilute rewards with an alternative source of capital, or once minDelay expires, but this approach makes it harder to do so with the protocol’s own TVL. (We could improve the guarantee by making the protocol's own minDelay slightly longer, but decided in favor of simplicity for the reference implementation.)

Endnotes

[1] Conceptually, the SAFE replaces convertible debt by functioning as a no-interest, open-ended loan that converts to equity at the next-round valuation, optionally with terms such as a valuation cap or discount rate. This mechanism also solved a second issue for investors: the difficulty of valuing early-stage companies. Rather than force a commitment to a particular valuation, which at the seed stage is essentially the weighted average of divergent outcomes, the SAFE allowed founders and investors to defer valuation until the next round. By that time, the company would have the chance to develop better product-market fit, and both sides would be able to take a more informed view.
[2] Last updated April 2023.