Builds_Writing_The Pit_Firedancer_
  • Builds
  • Compositions
    • Research
    • Macro
    • Spotlights
    • News
    • Podcasts
    • Media
  • Chronicle
  • The Pit
  • Firedancer
  • Careers
  • Connect
  • Brand & Press
Terms of Use_Privacy Policy_Disclaimers_

Whitehats and Dropboxes

Nihar Shah
Nihar Shah
Research

Aug 12 _ 8 min read

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.

Image Description

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.

Image Description

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.

Image Description

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.

Image Description

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.


  1. To be precise, protocols never have the unilateral authority to grant immunity from law enforcement after an exploit. Protocols, however, can take two steps to offer some legal cover. First, they can promise favorable treatment to whitehats from the protocol itself. Second, protocols can explicitly embed whitehat mechanisms in the official Terms of Use for their protocol. As such, protocols can potentially argue that users who deposit funds are consenting to the whitehat channel as a valid usage of funds (and not as theft) when utilizing the protocol. ↩︎

  2. See footnote 1. ↩︎

  3. Note that there is potentially an alternate condition on dropboxes: the protocol promises not to pursue whitehats as long as they are pursuing someone else. In other words, whitehats can only exist if an adversarial hacker is in the picture. However, this is much messier in practical terms, in that it adds uncertainty to the mechanism during an exploit (which would likely dissuade whitehats). Moreover, it doesn’t solve the issue of highly time-sensitive vulnerabilities that have not yet been acted upon by an adversary. ↩︎

Share

Contributors

Nihar Shah
Nihar Shah

Nihar is a Researcher focused on token & mechanism design. His work has been cited in the Financial Times, Fortune, and many podcasts. He has a PhD in Economics and worked on the Libra/Diem project.

.View all posts (12)

More articles

SAFU: Creating a Standard for Whitehats

SAFU: Creating a Standard for Whitehats

Whitehats and DeFi protocols need a shared understanding of security policy. We propose the SAFU - Simple Arrangement for Funding Upload - as a versatile and credible way to let whitehats know what to...

Oct 24 _ min

Share

Disclaimer

The information on this website and on the Brick by Brick podcast or Ship Show Twitter spaces is provided for informational, educational, and entertainment purposes only.  This information is not intended to be and does not constitute financial advice, investment advice, trading advice, or any other type of advice.  You should not make any decision – financial, investment, trading or otherwise – based on any of the information presented here without undertaking your own due diligence and consulting with a financial adviser.  Trading, including that of digital assets or cryptocurrency, has potential rewards as well as potential risks involved. Trading may not be suitable for all individuals. Recordings of podcast episodes or Twitter spaces events may be used in the future.

Jump_
Terms of Use_Privacy Policy_Disclaimers_

© 2022 Jump Crypto. All Rights Reserved.