# Automating "Social Consensus" Recovery Vitalik's recent [blog post](https://vitalik.ca/general/2023/05/21/dont_overload.html) highlights the dangers of putting expecations on Ethereum's social consensus. One such expectation is to fork out a large smart contract exploit, like the DAO-fork. These [expectations](https://youtu.be/xzyWGZCfhJQ?t=2839) are creeping up around crypto's version of the too-big-to-fail banks such as liquid staking tokens and popular rollups. Some rollups are [particularly hopeful](https://twitter.com/gluk64/status/1660384996241096705) a catastrophic exploit of one of their smart contracts would be forked out. Of course smart contract developers want to be protected by Ethereum's social consensus - developers need to be right every time, an exploiter only needs to be right once. Launching an application without the wink wink nudge nudge "we got you" from Ethereum's social consensus is daunting. Despite the daunting task for developers Ethereum should remain as neutral as possible. Ethereum was not designed to bear the burdens of smart contract risks born by its applications. Pilot, on the other hand, is a L2 network we have designed to explicitly insure applications and automatically recover from exploits. ## Automatic Recovery Recovery of an application exploit can follow one of two general paths: 1. Take the stolen funds from the exploiter 2. Go back in time and revert the exploit transaction Taking back stolen funds requires custom edits to the network's node software. The social consensus decides on the implementation details, most importantly how to move the funds from the exploiter back to the exploited. But who and where to take funds from can get tricky. For example, the exploiter may have swapped all of their stolen ETH for PEPE on Uniswap and benevolent LPs may have withdrawn that ETH onto a CEX account[^1]. [^1]: The DAO hack was fortunate to have a small blast radius because the stolen funds were subject to a warm-down period within the smart contract they were stolen from. Stolen funds did not leave the vulnerable smart contract, making the manual takeover of funds much cleaner than it generally would be. Alternatively, nodes can go back to the exploit block and rebuild the state after failing the exploit transaction. This path can be taken immediately upon exploit identification as there is no discretion in choosing who or where to take funds from. The rebuilt chain believes the hack never occured so any subsequent transactions made by the exploiter that relied on the presence of stolen funds now fail. Pilot uses the latter path to automatically recover from an application exploit. When an exploit is identified the nodes go back to the exploit block and treat the vulnerable application as paused, meaning transactions that target it are reverted including the original exploit transaction. All transactions to the tip of the chain are re-applied and a subset of those transactions that relied on stolen funds or targeted the vulnerable application may have their output changed. After a vulnerable application is paused, an upgrade can be proposed to the network to patch the smart contract vulnerability. If the network marks the upgrade as valid and safe then the application is unpaused and transactions targeting the application continue as normal. ## What's the point? Pilot's recovery mechanism allows applications to have real value, real users, and real feedback before facing the daunting task of losing user funds forever. Once an application has found product-market fit they can freeze their feature set and the enormous investments in security should begin. The Pilot network will co-invest in the security of its applications, cycling transaction fee revenue back to applications in the form of audits and bug bounty programs. ## Learn more & reach out Please reach out on twitter and give us your feedback or thoughts: https://twitter.com/sam___iamm https://twitter.com/itsDSPawer Follow Pilot on Twitter: https://twitter.com/Pilot_HQ Join our Discord: https://discord.gg/Rs3T7CXDq9