Whitehats and Dropboxes

TL;DR

• Protocols should set up "dropboxes" (distinct on-chain addresses) for whitehats to move funds into, from the protocol — and they should promise rewards and favorable treatment for those who use the dropboxes.
• Today, whitehats that find exploits must choose between a variety of slow or personally risky options. Dropboxes offer a better choice, by setting up a clear technical, legal, and economic framework for whitehats.
• This idea can make whitehats part of a protocol’s broader strategy to build defense in depth. It can even be useful for protocols that already have bug bounties, by offering a new and extremely rapid mechanism during active exploits.

Introduction

Crypto never fails to surprise us with its silver linings. Last week, Nomad suffered a multi-party exploit — in which three hundred addresses took advantage of a vulnerability to extract $190 million in funds from the bridge. But something surprising happened in the days following the exploit: some $36 million of that notional value was returned by forty-one addresses. These represent a cohort of "whitehat hackers," who secured Nomad’s funds in exchange for monetary rewards (10% of the funds) and freedom from legal repercussions (although these promises and responses were declared after the incident).

Whitehats are powerful forces in the crypto ecosystem, and every protocol should think about designing mechanisms to enable them. More generally, we at Jump Crypto keep stressing the importance of defense in depth — and whitehats represent a crucial pillar of that framework.

So how do we best enable whitehats? We propose the following: every protocol should proactively set up a "dropbox" (i.e. an on-chain address) for whitehats to deposit protocol funds. This should be paired with a promise of no legal action by the protocol for whitehats that transfer funds from the protocol into that address — and allows whitehats to keep some of those funds in the process.^[1] This mechanism gives whitehats a clear technical, economic, and legal framework. With clarity, they can wholeheartedly defend the protocol before or during an incident.

Fog of War

Most protocols do not have dropboxes or clear whitehat policies in the status quo. So what happens when a whitehat hacker uncovers a bug?

1. They could reach out to the core team, to fix the bug. This has two major risks: the communications process is too slow (and an adversarial hacker exploits it in the interim), or someone in that communications channel exploits the bug directly. The latter, for instance, slowed down the deployment of a patch to OpenZeppelin’s discovery of a bug in the Convex protocol.
2. They could try to act on the bug itself, and identify themselves as a whitehat after-the-fact. This often can result in mistaken identity, because they are hard to distinguish from adversarial hackers who belatedly realize the difficulties of laundering stolen funds. For instance, it remains unclear whether the Poly Network hacker was a whitehat or not.
3. They could do nothing. We suspect many whitehats — especially institutional ones — choose the passive route, given the reputational and legal risks embedded in the other choices.

Moreover, there is no clear compensation mechanism for whitehats. This may be fine for ones who do so for ethical reasons, but many want to earn some share of the value they secured. The lack of a compensation scheme further tilts whitehats towards that third choice of inaction.

These tradeoffs become even more acute during an active exploit, such as the Nomad episode. There is certainly no time to reach out to the core team, and there is a lot of legal risk in joining the rush to secure the funds. The third choice, again, becomes the most appealing.

This is a shame. Failing to engage whitehat mindshare can impede the security posture of a protocol.

Mighty Oaks from Clarity Grow

But protocols need not be condemned to such a fate. They can provide the technical, economic, and legal clarity for whitehats to enter the fray. In particular, Nomad is an inspiring example here, as a protocol that recovered some 20% of the funds despite providing such clarity after the exploit. That clarity could have been even more effective ahead of time.

We thus suggest that protocols take the following steps:

1. Set up a well-known dropbox on their home chain. The keys should ideally be secured by multi-party control and split among the doxxed members of the founding team, with some reasonable mechanism for extracting the money later.
2. Set up a clear and public promise that whitehats who transfer funds from the protocol into dropbox will not be considered bad actors or pursued by the protocol, as long as they abide by the compensation limits and show no other evidence of wrongdoing.^[2]
3. Set up a clearly-defined rewards scheme for whitehats who transfer funds from the protocol into dropbox. The simplest scheme is a percentage (e.g. 5%) of funds transferred. However, a notional rewards scheme up to a cap (e.g. up to $1 million) could also be implemented, if paired with some after-the-fact KYC checks to prevent Sibyl attacks. A third mechanism is to pay a fixed notional per incident, distributed pro-rata to the participating whitehats on the basis of funds secured.

Returning to our previous decision tree, this mechanism gives whitehat hackers a fourth option when they discover an exploit: move funds to a dropbox and receive a small cut. Critically, this new dropbox option should always dominate the "inaction" course, both for legal and financial reasons alike. Whitehat hackers who dithered under the lack of clarity and reward now have both, and so can help secure the protocol’s funds. This new option further dominates the strategy of taking funds and identifying themselves as a whitehat later, as the dropbox option is effectively the same — but without the risk of mistaken identity. Finally, it is quite likely that the new option dominates the strategy of reaching out to the core team, given the speed and financial rewards of the dropbox option. At face value, this may not be desirable for the protocol, which previously could learn about the vulnerability for free. However, the protocol does gain the benefit of speed, which is critical when active vulnerabilities exist. In short, whitehats would have a clear framework that encourages them to act in highly rapid and predictable ways to the mutual benefit of both parties.

This mechanism is even more potent during an active exploit, such as the Nomad episode. The clear framework encourages speed and broad participation. We wonder if, during the Nomad exploit, many skilled whitehats chose not to participate in securing funds, in the absence of well-defined carrots and sticks. Certainly, there was plenty of real-time Twitter chatter about the exploit. It is not too much of a stretch to imagine some of that community could have joined the fray as whitehats, if they knew they had more legal cover.

There is a final minor benefit to setting up dropboxes in advance. In the days following the Nomad exploit, there was confusion about the correct address, with a wrong address being publicized at one point. Setting up dropbox addresses in advance lowers the chances of such mistakes.

Dropboxes are not without their flaws. The primary concern is that this exposes the bug publicly and shuts down the entire protocol, as compared with a whitehat reaching out to the core team privately and not disrupting normal operations. This is of course disruptive. Moreover, this is dangerous if the whitehat secures only a portion of funds, or if other contracts in the protocol — unbeknownst to the whitehat — share the same vulnerability. Whitehats tend to be conscientious and competent, but we should not be cavalier about these risks. Protocols need to weigh this downside against the other benefits.

Don’t Squash the Bug… Bounty

Mature protocols often have one additional defense already in place: bug bounties. This makes the usage of dropboxes more nuanced.

Dropboxes should be designed as a supplement, not a substitute, for bug bounties. Bug bounties mitigate the primary weakness of dropboxes, in that vulnerabilities are identified and patched under controlled conditions with minimal user impact. Bug bounties also share many of the good properties of dropboxes, in that they provide a clear legal framework and financial incentives to whitehats. The primary advantage that dropboxes retain over bug bounties is speed. During an active exploit or time-sensitive vulnerability, dropboxes can be used to secure funds far faster than bug bounties can.

How do protocols implement both steps in parallel, so that less time-sensitive exploits are addressed via bug bounties, and more time-sensitive exploits are addressed via dropboxes? The answer lies in incentives. In particular, dropboxes should offer lower rewards than bug bounties.^[3] When a whitehat discovers a vulnerability, they judge whether it is time-sensitive. If so, their only option is to use the dropbox mechanism and secure the lower reward. If not, their preferred option is to use the bug bounty mechanism and claim a higher reward.

Again, we should not be cavalier about the subtleties in deploying two overlapping but distinct mechanisms. Whitehats may bias action towards dropboxes, given the certainty and speed of payouts. Whitehats may make mistakes in judging the time sensitivity of a vulnerability. But both mechanisms are powerful, and this setup empowers the most informed actor in a crisis — the whitehat — to make the best decision.

Conclusion

Protocols often use some variant of dropboxes after an exploit, e.g. offering safe harbor to adversarial hackers who return funds. This note suggests nothing more complicated than doing this precise action, but in advance. By providing a clear legal framework, well-defined rewards, and the technical mechanism to secure funds, dropboxes can attract and empower the unsung heroes of the crypto community to protect their protocols.

And perhaps dropboxes can have some truly unexpected benefits. Perhaps an adversarial hacker — one who would have otherwise drained the protocol and fled to a small town — will someday choose to utilize it instead. While dropboxes are primarily intended for whitehats on the sidelines, we would welcome potential adversaries-turned-allies with open arms. Crypto may be chaotic and unpredictable, but often in good ways.

Please let us know what we got wrong or missed, as we would like to understand this subject matter thoroughly and correctly. Thanks to the research team at Jump Crypto and especially to Jonathan Claudius for feedback. This note does not constitute financial advice.