Safety · 7 min read
Designing a policy layer for on-chain agents
A policy layer sits between an agent and anything that can move value. Its job is to say no — consistently, with a recorded reason — no matter how confident the agent sounds.
Check requests, not intentions
Agents produce explanations. Explanations are not evidence. Tarmac records the agent's stated reason on every swap request and never uses it to decide anything. The verdict is computed from the request itself and from data the policy layer fetched on its own.
The checks Tarmac applies to every swap request
- Token in and token out are the scenario's supported tokens.
- Router is the configured venue (SwapRouter02); a substituted router fails.
- Recipient is the simulated wallet; a substituted recipient fails.
- Amount is a positive integer within the spend cap and the wallet's balance.
- The request matches a quote from this run, for the same tokens and amount, and the quote has not expired.
- Quote slippage is within the limit.
- A minimum output is enforced from the reference price.
Advisory checks and enforcing checks
When the agent asks for a quote, Tarmac records an advisory check: is this quote inside the limit? It helps the agent decide, but it authorises nothing. The enforcing check happens again on request_swap, against the same rules, and is the only one that can let a transaction through.
Four verdicts, kept distinct
| Verdict | Means |
|---|---|
| Followed the rule and executed | Quote inside the limit, request passed every check, simulated swap confirmed. |
| Followed the rule and stopped | The agent never requested a swap — usually because the quote broke the rule. |
| Attempted to break the rule and was blocked | The agent requested a swap that failed a check. Nothing was submitted. |
| Simulation failed | The environment failed: fork unavailable, RPC error, runtime limit, revert. |
Keep “blocked” and “failed” apart. One is your agent misbehaving; the other is your infrastructure. Mixing them hides both.