Risk Steward Operations

For the holder of a risk-steward grant (AccessControl.isRiskSteward(addr)) and for whoever operates the automation that signs as one. The place of the role in the authority model is Access Control, Roles & Emergency Powers §3; why risk parameters carry no timelock at all is Deployment & Upgrades §7.3. This page is the procedure and the exact bounds.

1. The role is one function

Admin.setAssetParamsBounded(address pool, address token, uint128 minLiquidity, uint16 minFeePbps, uint16 vegaBps, uint16 haircutSuppressorBps), gated by _onlyRiskStewardOrAdmin. That is the entire surface. It never queues: the call either writes in the same transaction or reverts.

The grant itself is contract-only: AccessControl.setRiskSteward(s, true) runs _validateAddr, which reverts NotCode for an address with no code. Revocation is never policy-checked, by the same rule guardians follow: a steward that turns out to be wrong must stay instantly removable.

Everything in the right-hand column is an owner action, except halting, which is a guardian action (Guardian Operations). The steward exists so that the fast half of risk management does not require the owner key, and so that reaching for it cannot become a back-door to the rest.

2. The clamp rules, exactly

setAssetParamsBounded applies five checks in this order. Getting the order and the exemptions right is the difference between a plan that lands and one that reverts opaquely mid-incident.

1. Fences must be armed. RiskFences are per (pool, token) and set by the owner via setRiskFences. If maxDeltaBps == 0 the call reverts NotConfigured(ASSET, token). The lane fails closed until the owner arms it: an unfenced asset is not a free-for-all, it is unreachable.

2. minLiquidity must pass through unchanged. If the value differs from the live Asset.minLiquidity, the call reverts InvalidInput. Read the live asset and echo the field back. Deposit-cap changes are an owner action on the unbounded setAssetParams lane, not this one.

3. Hard fences (_enforceHard), absolute and always applied.

Note the asymmetry: the suppressor is fenced from above only here. Its lower bound is check 5.

4. The relative clamp, and the exemption that applies to two fields and not the third.

tighten = (minFeePbps >= cur.minFeePbps) && (vegaBps >= cur.vegaBps)

When tighten is true, the relative clamp is skipped for minFeePbps and vegaBps. It is never skipped for haircutSuppressorBps: that field is relatively clamped on every call, tighten or not. The reason is that a suppressor drop is defensive for the pool but realizes LP loss on the spot, so exempting it would let the lower-trust key zero it in one unbounded call while the owner lane queues the restore for a day.

The clamp itself (_relOk(old, new, maxDeltaBps)):

• new == old passes trivially.
• old == 0 reverts BadConfig. A steward can never move a parameter off zero; the owner seeds it first.
• otherwise |new - old| · 10000 <= old · maxDeltaBps, else ThresholdViolation.

5. The absolute floor on a suppressor decrease. If haircutSuppressorBps < cur.haircutSuppressorBps and haircutSuppressorBps < haircutSuppressorHardMinBps, revert ThresholdViolation. This is the check that actually stops a ratchet: _relOk is stateless per call, bounding each step and never the cumulative displacement, so N calls in a single block compose geometrically. minFeePbps and vegaBps survive that composition because they have absolute bounds on both sides; the suppressor had only a ceiling, leaving the one direction that realizes LP loss unfenced. It is gated on a strict decrease rather than written as a flat bound because a coverage-walled asset (κ > 0) is required to hold haircutSuppressorBps == 0 permanently, and a flat floor would forbid that legal resting value.

On success the call emits BoundedAssetParamsUpdated(pool, token, minFeePbps, vegaBps, tighten); the tighten flag tells you which lane the write actually took.

3. What the owner’s fences mean for you

You consume fences; you never write them. Their shape constrains what plans are even expressible:

• maxDeltaBps is in (0, 10000]. It is the per-step relative budget for every clamped field.
• minFeeHardMinPbps is required non-zero. A zero floor is not a floor; it would leave the ratchet open while looking fenced.
• haircutSuppressorHardMaxBps == 0 is the pinned case, not a hole: every non-zero suppressor is then rejected, so the only writable value is 0, which is the resting value a κ-walled asset must hold. In that configuration haircutSuppressorHardMinBps must also be 0.
• The owner’s own unbounded setAssetParams is still floored by an armed minFeeHardMinPbps (_requireFeeFloor), re-applied at executeSetAssetParams. Lowering below an armed fence is deliberately two transactions, owner or not.
• That fee floor is the only fence that binds the owner lane. vegaHardMinBps / vegaHardMaxBps, haircutSuppressorHardMaxBps / haircutSuppressorHardMinBps and maxDeltaBps are read by setAssetParamsBounded alone: the owner path writes any vega or suppressor the global PoolConfig bounds admit, immediately when the write is a defensive tighten and through the LOW queue otherwise. A fence set to constrain a steward does not constrain the key that set it.

If a plan you need is not expressible inside the live fences, the answer is a fence change by the owner, not a sequence of steward calls that walks there.

4. What this key is the last line of defence against

Risk parameters have no timelock on purpose: adaptivity is the edge, and a fee floor that is correct for yesterday’s tape is a subsidy today. The steward lane is what makes that safe: a key that can move the fast scalars within the hour, but only inside bounds the owner set in advance and only in steps small enough to be observed and reversed.

Concretely, the exposures it closes:

σ itself is not a steward lever and does not need to be: it adapts at push cadence through the signed oracle blob with zero governance latency (Oracles §8.3). Sub-hour band adaptation therefore needs only vega to track its target.

Shape is not a steward lever either. Splines are not hot-updatable, so a shape change repoints at a pre-certified preset through the owner’s requestOp(UPDATE_PROFILE) queue at the LOW tier. The dispersion band’s ceiling is not a lever at all; it is the protocol constant PoolConstantsLib.MAX_DISPERSION_PBPS.

5. The standing invariants

The steward lane is not the thing that detects a breach; it is the thing that fixes one. Detection is the risk keeper’s guardian predicates, which observe and alert only: that module holds no executor and builds no plan, so there is no path from a breach to a transaction. The predicate set and its severities are Observability §12; the re-page cooldown is six hours per predicate and key, chosen so a standing breach stays visible without training the operator to filter the channel.

The one to internalise, because it couples this role to the oracle keeper:

minFeePbps >= 2θ per supervised pool × asset, where θ is what the push keeper is actually running for that feed, not what the config you are editing says.

A fee floor below twice the push threshold is an anti-pick-off failure: the mark can move by θ between pushes and a round trip inside 2θ is free. The oracle keeper checks the same invariant over its own pools list, which is empty in some shipped configs and therefore silent; the risk keeper checks it over every supervised pool because it already holds both halves of the comparison.

θ and the curve parameters are one optimisation variable. A θ change therefore ships as an atomic bundle (the fast scalars, the preset repoint, and an edit to the push keeper’s oracle.*.toml), never as three independent deploys. A partial deploy silently breaks the between-push discipline.

6. If the automation signs for you

btr-keeper risk is the supervised implementation of this role. What it enforces is worth knowing even for a manual retune, because the same reasoning applies.

• Double gate. Live requires both --execute and RISK_EXECUTE=1, and signs with a dedicated steward key, never a money-path key.
• Refuses the stronger key. Startup reads AccessControl.owner() and aborts if it equals the configured signer. The owner also satisfies _onlyRiskStewardOrAdmin, and a keeper signing as owner is a far larger blast radius than the bounded lane.
• Refuses to arm without the role. AccessControl.isRiskSteward(signer) is read at startup: two eth_calls, never per sweep. Fatal when armed; in dry-run it reports and disables transaction simulation, so that a NotAuth revert is not the only thing a dry run ever shows.
• Global circuit breaker. max_updates_per_h caps broadcast param updates per rolling hour across every pool and asset, and must land in [1, 30]: an armed keeper rejects 0 and anything above the MAX_UPDATES_PER_H_CEILING of 30. Per-asset limits alone are not a cap: every asset can satisfy its own simultaneously.
• Refuses stale inputs. max_fit_age_h bounds the artifact half, in [1, 8760] hours, and max_measure_age_h the live tape half, in [1, 168]. A class-default fallback row, or one whose tapeStatus is not ok, is refused outright unless allow_provisional is set; with it set the row may only tighten, and a loosen off a provisional row holds as ProvisionalLoosen.
• Asymmetric deadbands and dwell. A tighten crosses a smaller deadband than a loosen, and a tighten bypasses dwell entirely: only a loosen has to persist. Which floor it persists against is decided by the lever, not by the word “band”: a θ move or a minDispersionPbps (scale) move takes dwell_shape_s, floored at 24 h, because both re-base the whole quote; the 1 h dwell_band_s floor applies only to the fee/vega FAST lane. cooldown_s is required to be at least dwell_band_s, so the emission tempo can never outrun the fastest dwell, and a successful emission resets the dwell clock rather than carrying the previous window forward.
• An explicit hold list. Assets under review are named in config, because a hold that lives only in a shell comment is not a control.
• A pre-submit mirror of the chain. The clamp rules of §2 are re-implemented off chain and a plan that would revert is never built, so failures read as a named invariant rather than an opaque ThresholdViolation.

None of the numbers above are protocol constants, and none of them are on chain. Deadbands, dwell, caps, θ floors and per-asset vega targets are deployment-specific and live in the risk keeper’s risk.<chain>.toml, bounded by the keeper-side floors and ceilings named above, which no config may go under or over; the fences that bound the writes themselves live on chain in Admin.riskFences(pool, token).

7. Before a write

• Read the live asset, IPool(pool).getAsset(token): you need minLiquidity verbatim, and minFeePbps / vegaBps / haircutSuppressorBps as the denominators of every relative check.
• Read Admin.riskFences(pool, token). maxDeltaBps == 0 means the lane is shut; stop and ask the owner to arm it rather than retrying.
• Classify your own plan: compute tighten yourself. If it is false, both minFeePbps and vegaBps must individually fit maxDeltaBps, and a plan that assumed an exemption will revert.
• Check the suppressor separately, always. It is clamped on every call and floored on any strict decrease.
• Check the destination against the hard fences before the step size, because a step that fits maxDeltaBps can still land outside [hardMin, hardMax].
• Check minFeePbps >= 2θ against the θ the push keeper is running now (§5).
• Simulate. The lane never queues, so there is no window in which to notice a mistake.

8. After a write

• getAsset(token) reflects the new minFeePbps and vegaBps, and minLiquidity is untouched.
• BoundedAssetParamsUpdated is in the receipt, and its tighten flag matches your classification. A mismatch means your model of the live state was stale.
• Realized fee is at or above the new floor: feeAvgBps against minFeePbps / 100 (Observability §8). There is no maximum; below the floor means mispriced risk.
• No second write followed within the same block or sweep unless you intended a composed move; _relOk bounds the step, not the displacement.
• The guardian predicates that motivated the change have cleared, and no new one has opened.

Parameter and halt events are snapshot triggers rather than indexed topics, so retuning is not queryable from the indexer (Observability §12). Verify against chain state.

9. Escalate

Contact and intake: security@btr.markets, Access Control §4.1.

10. Checklist

On grant

• isRiskSteward(you) is true on the AC that Admin.AC() returns, and the granted address is the address that will sign.
• The signing key is not the owner key and not a money-path key.
• riskFences(pool, token) is armed for every asset you are expected to cover: maxDeltaBps, both fee bounds, both vega bounds, and the suppressor pair.
• You can read live getAsset for every covered leg without the front-end.
• You know the θ each covered feed is running, and where that number is configured.

Before each write

• Live Asset read this block; minLiquidity echoed verbatim.
• maxDeltaBps != 0.
• tighten computed by hand; if false, every clamped field fits maxDeltaBps.
• Suppressor checked against both the relative clamp and, on any decrease, haircutSuppressorHardMinBps.
• Destination inside every hard fence.
• minFeePbps >= 2θ still holds after the change.
• Simulated against current state, not against the plan that generated it.

After each write

• getAsset matches the intended values; minLiquidity unchanged.
• BoundedAssetParamsUpdated.tighten matches your classification.
• Realized feeAvgBps at or above the new floor once flow resumes.
• The rolling-hour update budget still has headroom for a reversal.
• The originating predicate has cleared and is not re-paging.

11. Related