You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HoneyPause lets whitehats safely and atomically prove a smart contract exploit <i>on-chain</i>, pause the affected protocol, then collect a bounty. Protocols can opt into the system by registering a bounty on the smart contract. The entire system is permissionless, non-custodial, and free!
3
+
HoneyPause is a permissionless on-chain exploit bounty tied to a circuit breaker. HoneyPause lets whitehats safely and atomically prove a smart contract exploit <i>on-chain</i>, pause the affected protocol, then collect a bounty. Protocols can opt into the system by registering a bounty on the smart contract. The entire system is permissionless, non-custodial, and free!
4
4
5
5
For Ethereum applications that can be exploited in a single transaction, this adds another form of proactive defense that can supplement traditional (off-chain) bug bounties and monitoring.
6
+
6
7
## Flow
7
8
8
9
### Protocol Registration
@@ -19,33 +20,52 @@ Note that the HoneyPause contract never custodies bounties. It is up to the prot
19
20
A whitehat that has discovered an exploit on a registered protocol will post a `claim()` transaction **TO A PRIVATE MEMPOOL**, providing an **Exploiter** contract that will perform the exploit when called by the HoneyPause contract. The HoneyPause contract will:
20
21
21
22
1. Call into itself to enter a new call frame.
22
-
1. Call into the **Exploiter**, applying the exploit.
23
-
2. Run the protocol's **Verifier** to assert that the protocol has reached an exploited state.
24
-
3. Revert the call frame, undoing the exploit and bubbling up the result of 2.
23
+
1. Run the protocol's **Verifier** to assert that the protocol has not been exploited yet and to track any necessary state.
24
+
2. Call into the **Exploiter**, applying the exploit.
25
+
3. Run the protocol's **Verifier** again to assert that the protocol has reached an exploited state (success means exploited).
26
+
4. Revert the call frame, undoing the exploit and bubbling up the result of 3.
25
27
2. If the exploit was successful, we will then:
26
-
1. Call into the protocol's **Pauser** to freeze the protocol!
28
+
1. Call into the protocol's **Pauser** to freeze the protocol.
27
29
2. Call into the protocol's **Payer** to pay the bounty to the whitehat.
28
-
3. Ensure the whitehat received the stipulated bounty amount.
30
+
3. Ensure the whitehat received the agreed bounty amount.
29
31
30
32
> ⚠️ It is critical that the whitehat uses a private mempool to submit the transaction to in order to prevent an MEV bot from extracting the exploit from the unmined transaction and frontrunning the claim!
31
33
32
34
As a further safeguard against extra clever MEV bots, it is recommended that the deployment of the **Exploiter** contract be performed in the same transaction as (prior to) the `claim()` call.
33
35
34
36
## Writing Verifiers
35
37
36
-
TODO
38
+
Verifiers should essentially confirm that some critical invariants or health checks have been violated by the exploit. Protocols need to do the legwork of identifying a robust and comprehensive set of checks that would be considered critical enough to warrant pausing the entire protocol. These would typically be invariants that do not get checked during normal user interactions due to gas constraints.
39
+
40
+
The verifier contract should expose two methods: `beforeExploit()` and `assertExploit()`. As the names imply, the former is called before the exploit is executed and the latter is called after. Both methods accept an arbitrary `verifierData` bytes array that is provided by the exploiter to help identify an exploit. This may be needed if, for example, the exploit occurs on a specific pool that is not easily discoverable on-chain. You should document the uses of this data in your verifier.
41
+
42
+
A verifier's `beforeExploit()` function may also return arbitrary, intermediate state data, which is another bytes array. This will ultimately be passed into `assertExploit()`. A verifier can use this data to remember things between calls without affecting state.
43
+
44
+
### Risks
45
+
Verifiers should try to ensure that the protocol is not in an exploited state when `beforeExploit()` is called. Otherwise an attacker can exploit a protocol beforehand but still collect the bounty, effectively double-dipping.
46
+
47
+
If the verifier performs state changes (even transient ones), they should restrict the caller to the HoneyPause contract. Otherwise the verifier may inherit invalid state from a prior call that could affect validation.
48
+
49
+
## Writing Pausers
50
+
51
+
Pausers should generally be designed to pause the *entire* protocol. Only the HoneyPause contract should be allowed to call `pause()` on the Pauser contract.
52
+
53
+
## Writing Payers
54
+
55
+
Because the system is non-custodial, the Payer contract must be invoked by HoneyPause to transfer the bounty to the whitehat. Only the HoneyPause contract should be allowed to call the `payExploiter()` function. HoneyPause will track the balance of the whitehat to ensure funds have been delivered.
56
+
57
+
Instead of reserving a pool of payment coins for the bounty, a protocol may choose to perform some kind of just-in-time conversion of its assets towards the bounty. But note that the call to `payExploiter()` actually occurs *after* the protocol has been paused. The delivery mechanism used needs to be distinct from usual operations affected by a pause. Also, be wary of complex conversions as that increases the chances of a secondary exploit occurring in the Payer.
37
58
38
59
## Deployed Addresses
39
60
40
61
| Chain | Address |
41
62
|-------|---------|
42
-
| Ethereum Mainnet |`TBD`|
63
+
| Ethereum Mainnet |`TBD (will deploy if we get on stage)`|
0 commit comments