Skip to main content
Circuit breakers enforce configured limits on ERC20 balance changes. They can reject a candidate transaction before it settles. This page compares cumulative and rate-of-change controls.

​
What they watch

  • Adopter: The contract protected by the assertion.
  • Token: The ERC20 balance being watched.
  • Direction: Tokens entering or leaving the adopter.
  • Time: Balance changes across blocks and transactions.

​
Circuit breaker types

Cumulative outflow

Limits net tokens leaving the adopter over a rolling window.

Cumulative inflow

Limits net tokens entering the adopter over a rolling window.

Rate of change

Lets an assertion limit how quickly the watched balance changes.

​
How cumulative and rate limits work together

Cumulative and rate-of-change limits use different semantics. A cumulative limit measures total net flow over a rolling window, while a rate limit measures how quickly the balance changes. An assertion can enforce either policy or both. Both policies use a matching cumulative watcher to invoke the assertion. For a rate limit, the assertion reads the rolling-window rate data during that callback. When checks are combined, the assertion can reject a transaction when either limit is exceeded.

​
Why use a Phylax circuit breaker

A protocol-integrated circuit breaker protects the execution paths wired through it. A Phylax circuit breaker runs as an assertion before the transaction settles. It watches the actual ERC20 balance change of the adopter. Because enforcement runs as an assertion, the protocol does not need breaker-specific hooks or storage. The assertion can reject a candidate transaction when it exceeds the configured policy.

​
Monitoring and incident response

Circuit breakers constrain token flow rather than a specific attack path, so they can limit the impact of different exploit classes, including attacks that begin with oracle manipulation. They bound flow within the configured rolling window; they do not replace monitoring or incident response. Choose a window long enough for your team to receive an invalidation alert, investigate, and apply mitigation before earlier flow ages out of the window. Before production, validate the threshold and window in staging and configure invalidation notifications.