Matador transaction policy
Transaction policy for delegated operation
Matador is Steer’s transaction policy engine. It validates a proposed action before execution and validates the resulting state after the action returns but before the enclosing transaction can settle.
Financial products require recurring actions such as rebalances, hedges, mints, redemptions, and maintenance. An issuer or manager needs to delegate that work without giving an operator an unconstrained wallet mandate.
A permission system can approve a caller or function. A monitoring system can report a breach after settlement. On a covered path, Matador can also evaluate the actual resulting state and prevent a configured invalid result from becoming final. This makes recurring operation policy-bounded inside the transaction, rather than dependent only on trust or after-the-fact review.
The enclosing transaction reverts. This is enforcement, not an alert after finality.
How a covered transaction works
- Matador binds the caller, product or account, active policy, requested calls, and current state.
- It checks configured preconditions such as authority, targets, functions, assets, parameters, timing, and current positions.
- Approved external calls execute.
- After those calls return, Matador reads the balances, positions, exposures, and permissions required by policy.
- If every configured post-condition passes, the transaction can complete. If one fails, the enclosing transaction reverts.
“Post-execution” describes the sequence inside the transaction. It does not mean a check performed after final settlement.
Worked example
Consider an ETH liquidity account whose policy allows only approved ETH/USDC pools and routers, caps slippage, requires a fresh price input, and keeps the resulting hedge ratio inside a defined band.
Before a rebalance, Matador checks the caller, pool, router, functions, tokens, minimum outputs, oracle freshness, and lifecycle state. An unapproved router or stale input blocks the action before capital moves.
The approved calls then withdraw liquidity, swap assets, redeploy liquidity, and resize the hedge. Market movement, fees, callbacks, or venue state can cause the result to differ from the proposal.
Before settlement, Matador checks the actual positions, balances, token set, and hedge ratio. If a configured invariant fails, the entire covered transaction reverts.
Matador does not decide which hedge band is economically correct. It enforces the band defined by the product’s authorized policy.
Coverage and limitations
| Boundary | Treatment |
|---|---|
| Covered execution paths | An action receives Matador enforcement only when it passes through a configured Matador path |
| Configured rules | Enforcement is only as complete as the active policy and the state inputs it reads |
| Atomic domain | Same-transaction calls can revert together; cross-chain, asynchronous, and delayed settlement require additional controls |
| Safety and liveness | Rejecting an invalid action does not guarantee that a hedge, redemption, or unwind can be completed on time |
Deployment and assurance materials
| Material | Access |
|---|---|
| Product mechanism and worked transaction | Link access on this page |
| Policy specification and version history | NDA |
| Covered paths and deployed-address mapping | NDA |
| Allowed and reverted transaction examples | NDA |
| Test, audit, remediation, and release mapping | Security & operations documents |