Layer 7: Circuit Breakers

Currently the most sexy and controversial topic among the security community

TriWei.io
6 min readJan 14, 2024

“Why would you ever let 100% of your TVL leave in 10 seconds or five blocks?” — Diyahir Campos, EIP-7265 Author

Drawing parallels from the Circuit Breakers' roles in electrical systems and financial markets, these mechanisms act as crucial safeguards. Just as electrical circuit breakers prevent damage from current overload, and financial market circuit breakers were introduced post-Black Monday 1987 to halt trading during severe market dips, in Web3, circuit breakers serve a similar purpose. They are designed to temporarily suspend operations like token outflows when certain conditions, such as abnormal transaction volumes or price fluctuations, are detected. This allows time for evaluation and response to potential risks, thereby enhancing stability and user confidence in the platform.

As we have seen in the previous article, off-chain monitoring tools are unable to reliably front-run an exploit transaction. Circuit Breakers overcome this limitation by incorporating the control logic into the protocols’ smart contracts.

Proposed Standard Implementation: EIP7265

EIP7265 introduces an adaptive, rate-limiting pass-through mechanism that works well with token protocols. It adopts two different intervention mechanisms:

  1. Rate Limiter
    The rate limiter module functions by allowing fund transactions to proceed normally until they reach a pre-set maximum threshold, essentially the maximum possible immediate loss. Operations remain atomic, meaning user operations can settle in one transaction until this limit is reached. Upon reaching this limit, the transaction is blocked, and a timelock mechanism is activated. Designing such a module is complex; it requires minimal dependence on external data (oracles) and robust resistance to Denial of Service attacks.
  2. Timelock
    The timelock module disrupts transaction atomicity to provide a window for protocol maintainers to intervene. It is designed to automatically complete transactions after a set period, ensuring the system remains active and responsive.

An example scenario of Incident Response with EIP7265 implemented:

  1. An attacker discovers a bug and attempts to exploit it
  2. A portion of funds is immediately lost through the rate-limiter
  3. The remaining amount is locked and has to wait for the timelock
  4. Monitoring alerts protocol admins about abnormal behavior
  5. The protocol administrators evaluate the situation and decide whether to pause the protocol
  6. The administrators create the recovery snapshot
  7. The bug gets fixed and the contract upgraded
  8. The timelock is unpaused and the snapshot applied

Some funds are lost anyway, but a lot of additional damage has been prevented.

Where and how to integrate circuit breakers

While the application of circuit breakers to DeFi primitives would be unfeasible due to their need for composability, they make total sense for many DeFi protocols and bridges.

DeFi protocols can adopt two approaches regarding CBs: they can maintain them permanently active, or implement them temporarily after launch, deactivating them once the protocol proves to be stable and secure over time. This strategy is effective as most hacks occur in the early stages of a protocol’s lifecycle, making the initial months particularly vulnerable. In scenarios where CBs are eventually disabled, a black-hat hacker might delay exploiting any discovered vulnerabilities until after the deactivation. However, this delay also allows for the possibility that a white-hat hacker might identify and report these vulnerabilities through a bug bounty program, thereby mitigating the risks.

When discussing bridges and CBs, it’s crucial to differentiate between two types of bridges: trustless and non-trustless bridges. Trustless bridges, which are secured through genuine crypto-economic incentives, should ideally reach a level of maturity where they can operate without circuit breakers. They might still retain an emergency shutdown mechanism to address extreme scenarios, such as a collapse in the staking token’s value. In contrast, non-trustless or multisig bridges operate differently. These bridges always face the risk of their quorum being compromised, a risk that may increase over time. Therefore, such bridges should maintain circuit breakers, complemented by on-chain monitoring and emergency shutdown systems, to ensure ongoing security and stability.

Circuit Breakers Limitations

To achieve their damage prevention capabilities, circuit breakers involve several trade-offs:

  1. Extensive Monitoring is still needed. Circuit Breakers involve more than just coding; they demand robust monitoring and a well-defined incident response protocol. Human oversight is a critical component in this process, as individuals are responsible for monitoring and approving transactions. There is always a possibility of human error, which could lead to the approval of malicious transactions. Therefore, while implementing CBs, it’s essential to factor in both the technical and human aspects to ensure comprehensive security.
  2. Impact on User Experience: If a circuit breaker is incorrectly triggered (false positive), it could slow down or even temporarily halt the movement of funds, potentially leading to delayed or locked transactions.
  3. Higher Transaction Fees: The on-chain evaluation of circuit breaker triggers adds extra steps to user operations, resulting in increased gas costs. However, considering the ongoing developments in Layer 2 solutions this added expense is relatively minor.
  4. Increased Centralization: Depending on the implementations, circuit breakers may grant specific authorized parties the power to block or censor transactions. This level of control introduces some centralization, but it is less than what is typically seen in upgradeable protocols.
    Additionally, the settings of circuit breakers would often require management by a Decentralized Autonomous Organization (DAO). While this is a decentralized approach, it still carries the inherent limitations of any human-driven process, such as being slow, inconsistent, and time-consuming.
  5. Degraded Composability: When circuit breakers disrupt atomicity, the ability to seamlessly be integrated by other protocols is affected. This necessitates a redesign of downstream integrations. Consequently, DeFi primitives, which rely heavily on composability, are not ideal candidates for implementing circuit breakers.

Increased Complexity

The introduction of circuit breakers in protocols necessitates careful consideration of their effects on stakeholders and system integrations. Customizing circuit breakers is crucial to cater to the diverse needs of participants, especially significant stakeholders. This customization might include setting varied thresholds for activation, considering factors like the magnitude of withdrawals or the protocol’s overall stability. It’s important to note that improperly managed circuit breakers can be exploited to manipulate markets.

Auditors have a critical role in guiding developers to fine-tune circuit breakers for each specific project. Key configuration decisions include whether triggers should be on-chain or off-chain, whether to partially or completely freeze the protocol, the extent of function rate-limiting, the creation of trigger allowlists, and whether to include privileged roles or rely solely on conditional triggers.

Furthermore, auditors are instrumental in ensuring proper integration of circuit breaker libraries into the target protocol. Integration errors, such as overlooking certain fund flow paths, could result in significant financial losses. Therefore, meticulous planning and expert oversight are essential in the effective implementation of circuit breakers.

SphereX Protect: a different approach

Unlike EIP7265 which tracks funds at the protocol layer, SphereX purpose is to filter out malicious transactions. It adopts a black-box approach through machine learning to analyze transaction signatures. Through smart contract modules embedded within the protocols’ contracts, it monitors “execution fingerprints” of transactions, which are unique patterns produced during transaction execution. SphereX Protect then compares these patterns with established safe execution patterns, reverting any transaction that deviates. This method ensures that only verified behaviors are allowed, providing a proactive defense against zero-day attacks and preserving decentralization and censorship resistance.
SphereX’s distinctive approach differs from EIP7265, leading to unique applications and limitations.

In the near future, we can expect to see an evolution in circuit breaker technologies, with new and varied architectures being developed.

That’s a wrap on our seven-part series about Web3 security! If you’ve missed any articles, make sure to check them out. Each one has important tips and information that can help you keep your Web3 projects safe. You can find all the articles at triwei.io/education. And don’t worry, there’s always more to learn. We’ll keep sharing new material about Web3 security, so stay tuned for more updates! Stay safe and keep learning!

--

--

TriWei.io
TriWei.io

Written by TriWei.io

Three experienced solo auditors joined to create TriWei, a Smart Contract auditing firm. Lean process, high quality, competitive pricing. www.triwei.io

No responses yet