> For the complete documentation index, see [llms.txt](https://docs.ensemble.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ensemble.io/safety/circuit-breaker.md).

# CircuitBreaker

How transaction limits apply to both routed and direct vault calls.

CircuitBreaker checks whether a deposit or withdrawal is allowed and how much can move. Calling the vault directly still requires these checks.

## What it protects

A transaction must use a supported vault and satisfy the current limits before funds move.

It enforces authorized vault routes, accepted assets, layout compatibility, action pauses, minimums, hard maximums, rolling capacity, receiver/owner rules, and routed account attribution.

It fails closed if the configured asset no longer matches the vault or if the vault layout differs from the version the router expects. Those failures are configuration alarms, not ordinary periods of low capacity.

## Routed deposits and redemptions

The router and vault check the request together. Every required check must pass for the transaction to complete; a failure rolls back the whole transaction.

```mermaid
flowchart LR
    Caller["User or approved conduit"] --> Route["Validate route and identity"]
    Route --> Action["Vault accounting and route-capacity checks"]
    Action --> Result["Complete atomically or revert"]
```

## Limit hierarchy

Several limits can apply at once. The smallest remaining allowance determines how much can pass.

```mermaid
flowchart TB
    P["Protocol: all vaults"] --> V["Vault: one product"]
    P --> A["Account: one actor"]
    V --> VA["Vault-account: actor in one product"]
    A --> VA
    VA --> Allowed["Allowed amount is the tightest remaining capacity"]
```

## What can limit a transaction

A withdrawal can fail because a limit is reached even when your shares still have value.

* Unsupported vault or changed asset.
* Incompatible vault layout.
* Protocol-wide or vault-specific action pause.
* Route minimum or per-transaction hard maximum.
* Protocol, vault, account, or vault-account rolling capacity.
* Vault-level cap, spendable liquidity, lifecycle, or emergency state.

Rolling capacity is tracked separately for deposits and redemptions at protocol, vault, account, and vault-account levels. The contract counts the current and previous time bucket. A new bucket therefore does not necessarily restore all capacity immediately.

## What users experience

A rejected route does not by itself imply lost funds or worthless shares. The decoded error and current state should explain whether to correct an amount, wait for capacity, or stop because operation is paused or incompatible.

Deposit limits are expressed in USDC asset units. Redemption limits are consumed using the net USDC returned after fees even though `maxRedeem` reports shares. The spender depends on the method: routed deposits approve CircuitBreaker, while direct deposits approve the vault. Routed `redeem` pulls approved shares; router `withdraw` uses the share-owner allowance without first pulling shares. Check the chosen method before approving a spender.

## What CircuitBreaker does not control

It does not calculate an alternative NAV, choose strategy positions, confirm HyperCore settlement, or guarantee future liquidity.

## Before a deposit or redemption

Check the selected vault's current capacity and pause state, then review the amount and spender in your wallet. Direct vault entry follows the same policy controls. See [Connect and deposit](/use-ensemble/connect-and-deposit.md) or [Redeem](/use-ensemble/redeem.md) for the holder's transaction steps.