EIP: 7265 - Circuit Breaker Standard

This standard outlines a smart contract interface for a Circuit Breaker that triggers a temporary halt on protocol-wide token outflows when a threshold is exceeded for a predefined metric. This circuit breaker does not assume the structure of the underlying protocol, and mainly serves as a pass-through vehicle for token outflows. In order to maintain correct internal accounting for integrated protocols, and to provide maximum flexibility for developers, developers can specify if the circuit breaker contract should delay settlement and temporarily custody outflows during the cooldown period, or revert on attempted outflows.

Implementation/ testing:

We would love some feedback on this proposal!


In onTokenOutflow it says:

Before calling this method, the protected contract MUST transfer the EIP-20 tokens to the circuit breaker contract.

Have you considered instead having the protected contract approve the tokens and the circuit breaker using transferFrom? This would be more efficient if there’s no rate limit because the circuit breaker can transfer directly from the protected contract to the recipient.

Edit: It turns out this doesn’t really improve net gas costs, and it relies on a larger refund which might be better to avoid, so I think two transfers is good.

1 Like

Thanks for validating this!

Excited to getting this PR merged. It will allow for increased modularization of the CircuitBreaker.

1 Like

Hey, I really like the EIP and the concept of limiters is very promising.

I got a question after taking a quick look. I noticed there’s an AssetRegistered event for the registerAsset function:

event AssetRegistered(address indexed asset, uint256 metricThreshold, uint256 minAmountToLimit);

However, there’s no counterparty for the updateAssetParams, which means that an indexer would be able to know the initial parameters of a registered asset but won’t be able to track further updates. Is this intentional or am I missing something?