Onchain Guardrails for AI Agents That Trade on Base
Onchain guardrails for a trading agent are limits the smart account enforces whenever the agent's key signs: an allowlist of routers and tokens, a recipient pinned to the account itself, a per-trade size cap, a non-zero minimum output that bounds slippage, a short deadline, and a session key scoped to specific contracts and functions.
Why trading needs different guardrails than payments
A payment moves a known amount of a known token to a known recipient. A policy that checks those three things covers most of the risk. A swap is less constrained in three ways.
The outcome depends on price at execution. The agent commits an input amount and accepts whatever output the pool gives, down to the minimum it specified. A minimum of zero accepts any fill, including one that a sandwiching bot has moved against it.
The calldata decides where the output goes. Router functions take a recipient parameter. A guard that checks which contract is called but not the recipient lets a confused or manipulated agent swap the account's tokens and deliver the proceeds elsewhere.
Approvals outlive the trade. An agent that approves a router for an unlimited amount leaves that allowance standing after the trade, so a later bug or compromise in anything holding it can pull the balance.
So the question for each guardrail is the same one as for payments, which party is constrained and by what, but there are more parameters to constrain.
The guardrails, by layer
These are enforced by the smart account when it validates the agent's signature, or by a hook module that runs on each call, so they hold regardless of what the agent believed when it signed. ERC-7579 defines the modular account interface many such validators and hooks are written against, and ERC-7715 defines how an app requests scoped permissions from a wallet. Both are still draft ERCs, so treat the interfaces as moving targets.
Target and function allowlist
Register the agent's session key for calls to specific contracts only: the router or routers it is meant to use and the tokens it may approve. Narrow further by function selector, so the key can call the swap function but not, say, a sweep or a multicall that wraps arbitrary actions. Anything off the list fails validation before it executes.
Token allowlist and recipient pinning
Decode the swap parameters and check that both input and output tokens are on a short allowlist of contract addresses, compared in full rather than by symbol. Require the recipient to equal the account itself. This one check closes the path from a bad decision to an outright loss of funds to a third party.
Per-trade and per-period caps
Cap the input amount per trade in the token's own units, and cap cumulative volume per period. For pairs quoted in USDC the arithmetic is direct. For other tokens, any cap expressed in dollar terms needs a price source, and that source is now part of the trusted base, so prefer caps in native token units where you can.
Minimum output and deadline
Uniswap-style routers take a minimum output amount in the swap parameters, and many also take a deadline. Reject any swap whose minimum output is zero. A stronger guard compares the implied price of the minimum with a reference price and rejects anything worse than a set tolerance, with the same oracle caveat as above. A short deadline stops a signed trade from executing long after the price it was computed against has moved.
Approvals
Approve the exact input amount for each trade, or have the guard reject approvals above the per-trade cap. Never let the agent's key grant unlimited allowances. Review and revoke stale approvals on a schedule.
Expiry and revocation
Give the session key a short expiry and a tested revocation path from the owner key, held off the agent's host. A guardrail you cannot revoke quickly becomes the ceiling on your worst day.
Where onchain checks stop
Guardrails decide which trades are possible, not which are wise. An agent can lose money one permitted trade at a time, inside every cap, and the account will validate each one. Strategy quality is a separate problem, and nothing here is advice about what to trade.
Oracle-based checks inherit the oracle's failure modes. A stale or manipulated reference price can make a bad trade look acceptable or block a good one. Keep tolerances deliberate and log every rejection.
Hooks cost gas on every call. On Base that cost is usually small relative to the trade, but a complex validator that decodes nested calldata adds both cost and its own bug surface. Simpler, narrower scopes are easier to reason about than clever general ones.
How a transaction is submitted is not an onchain property. Sending through a private transaction channel can reduce exposure to sandwiching, but that is a choice the off-chain stack makes, and the minimum output is the guard that still holds if the choice is wrong.
Testing the guardrails
Fork Base mainnet locally, for example with Foundry's anvil and a fork URL, deploy the account and its modules, and write one test per violation: wrong router, wrong token, foreign recipient, oversize trade, zero minimum output, expired deadline, unlimited approval. Each should revert. Then run the agent against the fork and watch what it tries. Rejected attempts are signal, not noise: an agent that keeps proposing trades the guard refuses is telling you something about its inputs.
Move to Base Sepolia or a small mainnet float only after every guard has failed a test on purpose.
Frequently asked questions
- What are onchain guardrails for AI trading agents?
- They are limits a smart account enforces when it validates the agent's signature: which contracts and functions the session key may call, which tokens may be traded, where output may go, how large each trade and each period may be, and the minimum output and deadline each swap must carry. They hold whatever the agent's reasoning was.
- How do you limit slippage for an agent's swaps?
- Require a non-zero minimum output on every swap, and optionally check that the minimum implies a price within a set tolerance of a reference price. Add a short deadline so a signed trade cannot execute much later. The reference price introduces oracle trust, so choose it carefully and log every rejection to tune the tolerance.
- Can a session key restrict which contracts an agent calls?
- Yes, on a smart account that supports scoped permissions. The session key is registered with an allowlist of target contracts and function selectors, plus caps and an expiry, and the account rejects any call outside that scope during validation. ERC-7579 modules and ERC-7715 permission requests are the draft standards to look at.
- Do onchain guardrails make an agent's trading safe?
- They make it bounded, not safe. Guardrails prevent trades outside the allowed contracts, tokens, sizes, and prices, and they stop output from leaving the account. They cannot tell a good trade from a bad one, so an agent can still lose money through a series of permitted trades within every limit.