CircuitBreaker complexity introduces unnecessary attack surfaces

The CircuitBreaker, aka EIP-7265↗, is a contract that handles protocol-wide token-withdrawal circuit-breaking functionality once liquidity exceeds tolerable transfer limits. However, this contract is both erroneous and complicated.

1. It tracks liquidity changes, which does not capture token volatility. This means, as token value decreases, more liquidity is needed to meet the same transfer demands. Likewise, as asset price increases, liquidity transferred will be significantly lower and huge-value transfers are required to hit the circuit's liquidity threshold. Requiring manual intervention to update liquidity params might not be fast enough for volatile tokens to provide meaningful protection against value changes.

2. When the circuit is triggered, if reverts are disabled, lockedFunds are tracked. After the rateLimit is removed, the locked funds are instantly claimable. Anyone with sufficient capital can hold funds hostage, transferring large amounts in order to trigger the Circuit Breaker. An admin must intervene, but if they remove the rate limit so that some users can withdraw, the offending user that triggered the rate limit can continue to pull the entire balance at the exact same time as all other users. There is no preferential withdrawal to earlier users; as such, there is no defense against massive price manipulation as a result of the sudden withdrawal.

3. There is also no recovery mechanisms for hacked assets. Admin members cannot rescue funds after the locked funds are recorded and redistribute them as intended.

With these points, it is strongly worth considering the need for circuit-breaker functionality, the need for an external contract handling protocol-wide protection, and whether iterating through all transfers after each transfer provides sufficient reward to compensate problems if additional flaws in the circuit-breaker logic are discovered.