1/ We are thrilled to announce a self-service SaaS platform-#KillSwitch, which aims to detect exploitation TXs before their block inclusion and take contingency measures to block the attack or prevent assets from being stolen. It is in-essence a frontrunning-based DeFi protection
2/ #KillSwitch is proposed with the observation that DeFi exploits/hacks pose a significant, serious threat to the security of our ecosystem. In particular, this year’s DeFi hacks have so far resulted in a whopping $2.1B loss, 25% increase from 2021 and 8 times more than 2020.
3/ 🧵How it works? #KillSwitch includes a number of background agents that constantly monitor mempool TXs, locate those malicious ones with real-time simulation, and preemptively neutralize the damage with a just-in-time protocol pause or an emergency fund withdrawal.
4/ To streamline the self-service process, #KillSwitch is divided into three steps: a) specify the triggering condition, b) sign a contingency TX, and c) turn on the protection.
All these three steps are readily accessible within the #KillSwitch platform.
5/ The triggering condition captures the fact of a significant loss from an exploit and requires knowing the protocol address, the asset, and a loss percentage. For multiple assets, we specify the loss for each. #KillSwitch is triggered if any asset is lost up to the percentage.
6/ The contingency TX will be executed by #KillSwitch upon the condition being triggered. It needs to be prepared & signed by the protocol management team to pause the protocol or rescue the funds. Note we do NOT have access to the private key (and will not ask for it either).
7/ #KillSwitch is turned on by constantly monitoring TXs in mempool and simulating each execution to locate and match malicious ones against the above triggering conditions. The self-service platform will automatically collect and report execution results for your access.
2/ The hack is made possible due to the flawed logic its donation and liquidation. Specifically, the donateToReserves needs to ensure the donator is still over-collateralized. And liquidation needs to ensure the *correct* conversion rate from borrow to collateral asset.
2/ The hack is made possible due to a flawed impl in its MasterPlatypusV4 contract. Specifically, the emergencyWithdraw func incorrectly evaluates the insolvency before the collateral removal, resulting in an insolvent debt position of ~41.7M after the emergency withdrawal.
1/ @dForcenet was exploited in a flurry of txs on Arbitrum & Optimism (one hack tx: arbiscan.io/tx/0x5db5c2400…), leading to the total gain of ~$3.65m for the exploiter.
2/ The hack is made possible due to the price manipulation of the @dForcenet wstETHCRV-gauge asset via reentrancy (via wstETHCRV.remove_liquidity), so that the exploiter can liquidate a number of positions w/ the wstETHCRV-guage as collateral.
2/ The hack is made possible due to incomplete reentrancy protection: swapThroughOrionPool func allows user-provided swap path w/ crafted tokens whose transfer can be hijacked into re-entering depositAsset func to increase user balance accounting w/o actually costing funds!
2/ The protocol has a flawed migrate() that is exploited to transfer real UniswapV2 liquidity to an attacker-controlled new V3 pair with skewed price, resulting in huge leftover as the refund for profit. Also, the authorized sender check is bypassed by locking any tokens.
3/ The initial fund (1.76 ETH) to launch the hack is withdrawn from @FixedFloat. Currently all stolen funds are still parked in the following account (880 ETHs, 6.4m DAIs, 11.8m TSUKAs and 74.6trillion CAWs) etherscan.io/address/0xba39…