Blog | Home | GitHub | LinkedIn | Twitter | Medium

Elliot Friedman, Builder, Smart Contract Engineer

TVL: $2,178,650,365  |  Total Transactions: 2,254,490 |  Deployed Smart Contracts: 67 |  Hack Losses: $0.00

Ethereal Sentinels

This article examines three distinct types of software-based security prevention tools for live contracts in DeFi. The exploration revolves around the discovery of a bug in a live contract, outlining how whitehats can safely exploit it while keeping blackhats at bay, even when the issues are unknown.

Pre-Hack Prevention

The first method, pre-hack prevention, involves a trusted third party or a zero-knowledge (zk) proof that an invariant in a protocol has been violated. This approach requires sending a notification to the team and initiating a transaction from a trusted third party to prevent the hack, as a notification alone doesn't stop theft. When employing zk-proofs, a prover contract validates the proof, allowing permissionless withdrawal of funds to a secure address.

A bot likely picks up the invariant violation by monitoring the mempool, simulating the transaction, looking at the call trace, and asserting invariants are not violated after the transaction occurs if a known DeFi smart contract is involved. If an invariant is violated, the bot needs the capability to either pause the protocol or withdraw funds to a safe address by frontrunning the attack transaction. This method could potentially prevent hacks; however, attackers using a private mempool like flashbots would avoid detection.

Time of Exploit Bounties

The second method involves time-of-exploit bounty payouts. This approach allows a hacker to steal funds, move them to a safe address, and receive a predetermined payout specified by the protocol. The protocol must legally agree to terms explicitly permitting itself to be hacked, provided the attacker returns all funds to the agreed-upon contract.

Jump crypto team's prior work with the safu framework addresses this problem. Time of exploit bounties, combined with pre-hack prevention that includes mempool monitoring, could lead to Priority Gas Auctions (PGAs) where large sums are spent on transactions to frontrun other attackers, and most of the profit gets competed away.

Skylock, an exciting solution to time of exploit bounties, uses machine learning to detect hack transactions in real time. However, this solution currently cannot stop a hack from occurring, only notify when one is happening. It will be exciting to see their product roll out. Combining this type of solution with a system that can frontrun the attacker and send the funds to a safe address is essential. The safe address could then atomically reward the frontrunner that stopped the blackhat from taking the funds. Governance would then determine how to give users their funds back with or without a haircut.

Legal issues are important considerations for this type of bounty. If a whitehat executes an exploit, they cannot negotiate with the team afterward because the team is under duress, and any indemnification or bounty agreed upon is not enforceable in a court of law. Furthermore, the team may pursue legal action, even after the funds have been returned if an agreement was reached following the hack but prior to the return of the funds. DeFi protocols would have to sign exhaustive contracts, granting whitehats the ability to hack their contracts, indemnifying and holding them harmless, as long as funds are returned in the same transaction to a known address, with bounty rules defined in advance inside a smart contract system like the safu framework.

Post Hack PvP

The third method, post-hack management, involves a product that holds users' funds. In case of on-chain invariant violations, anyone can permissionlessly withdraw all funds, distributing the proceeds pro-rata to all protocol users. This type of protocol can become complex with lending market products where users can have both assets and liabilities, and the value of a position must be calculated using an oracle.

This service allows risk sharing and protection for less sophisticated users in the case of hacks. This protocol has a fee collected if an invariant violation is triggered, and funds are recovered. The fee is a percentage of funds recovered. An offchain bot scans the chain for invariant violations and sends proof that the prover smart contract verifies of any invariant violations. Each invariant could have its own fee tier, meaning users pay different amounts if different invariants are violated. A portion of the fee could be sent to the address that provides proof of an invariant violation, which triggers position unwinding; this would compensate for the large gas costs associated with unwinding many different positions and recovering available funds.

Invariant violations to check for:

  1. Bad debt above a certain threshold: This fee could be a medium fee tier because it's unlikely that bad debt goes above a certain threshold, and even if it did, this is an expected failure mode, so there is less likely to be a gas bidding war in the mempool to pull funds.

  2. Protocol invariant violations: Compound has basic formulas around borrows, cash, and fees. If these invariants are violated, there is a much higher likelihood for a bidding war to occur, so this would be a higher fee tier as there is a sudden rush for the exits.

  3. Protocol becomes too illiquid: When compound's cash reserves are low, funds can be pulled. The fee would likely be very low for this action as liquidity crunches generally do not cause gas bidding wars. However, price volatility may cause gas bidding wars, which may happen at the same time users pull liquidity. (illiquidity isn't a system invariant, and is quite easy to game with a flash loan, it's more of an example of what this software could detect and potentially react to even in non-failure modes)

This software has two states: open for allocation and closed for allocation. When open, users can interact with the protocol normally. When closed, the only allowable actions are closing positions and removing liquidity.

Conclusion

In summary, pre-hack prevention and time-of-exploit bounties can provide an added layer of protection for live contracts in DeFi. These methods aim to minimize potential damage from hacks and ensure that user funds remain secure. The post-hack method is useful to a point; however, once enough users discover it, all remaining funds after a hack get evenly distributed to all users, canceling the protocol's benefits. By integrating these tools, DeFi protocols can enhance their security measures and promote a more resilient ecosystem.