BalancerV3VaultOutflowAssertion limits the net outflow of one ERC-20 from the Balancer V3 Vault singleton. Attach it to the Vault that holds the tokens, not an individual pool address.
Constructor
2_000, and 86_400. Both addresses must be nonzero. The threshold must be from 1 through 9,999 bps; the window must be at least 10 seconds and no greater than type(uint64).max.
The callback verifies that the configured Vault is the adopter, then reverts whenever the executor reports a threshold breach. A 10,000-bps threshold is rejected because dispatch requires a strict breach: reaching 100% would not trigger it.
Scenarios
Assume a 1,000,000-token window baseline and a 20% limit. Each row is an independent scenario.
The threshold applies to the Vault’s aggregate custody for that token. It does not assign a separate budget to each pool or measure gross withdrawals.
Operational fit
Size the policy around legitimate swaps, liquidity removals, buffer operations, and fee collection. Protocol-fee collection can transfer an accumulated ledger in one operation; do not assume it can be split to fit the limit. Test those operations with your FDE before choosing the threshold and window. The breaker does not value wrapped positions or compensate for rebasing behavior. A different custody model needs a different policy. See the adapter’s scope notes.Run the supplied tests
From the reviewed library checkout:ArmedOutflowBreaker test variant replaces the cumulative watcher with a call trigger to execute the callback locally. It does not test rolling aggregation or threshold dispatch. Test the table above against the actual executor before production activation.