Most wallet security still assumes the user signs what the chain executes.
Intent architectures break that assumption on purpose. The user signs an order: asset pair, amount bounds, deadline, maybe a fee cap or allowed filler set. A solver, router, or relayer later assembles the calldata that satisfies those constraints and submits the transaction. The settlement may be a batch, a partial fill across venues, or a path the user never saw in a single preview pane.
That is not a UX detail. It is a new trust boundary. If your review stops at the settlement contract, you are auditing the referee after the play was designed by someone else.
This note is for protocol teams shipping intent infrastructure, aggregators wrapping solver networks, and security leads who still threat-model swaps as transferFrom plus swap.
What the user actually authorizes
In classic DEX flow, the wallet decodes calldata (or a simulation of it) and the user approves a concrete call graph: router, pools, amounts, recipients.
In intent flow, authorization is usually one of:
- A typed order struct (EIP-712) with economic bounds
- A Permit2 signature over token movement within those bounds
- A limit order or RFQ acceptance with offchain matching
- A "fill this intent" message where the filler supplies execution
The signed object answers: what outcome is acceptable within these limits? It does not answer: which contracts will be touched, in what order, with which callbacks, at which block position?
Solvers compete or are selected to maximize surplus, capture spread, or minimize gas. That optimization is invisible in the signature screen unless the product deliberately surfaces it.
If your threat model ends at "the user signed an order," you have not modeled who chooses execution.
Where the solver sits in the stack
Treat the solver layer as infrastructure with privilege, not as passive transport.
Solvers typically can:
- Choose routing across pools, bridges, and private liquidity
- Decide batching with unrelated user intents
- Pay gas and recover it from the trade surplus
- Select submission timing and builder relationships
- Fail to fill, or fill late, within deadline semantics
They usually cannot forge a fill outside the signed constraints. They can often choose how to fill inside them, including paths that leak value, trigger downstream liquidations, or activate hooks the user did not mentally include in "swap A for B."
The security question is not only "can a malicious solver steal outright?" It is "can an honest-but-optimizing solver, or a compromised solver client, produce a valid fill that harms the user or the protocol under the rules as written?"
Failure modes we keep finding
### 1. Simulation that is not settlement
Products show a quote or a Tenderly-style simulation at sign time. Settlement happens later, in a different block, with different pool state, a different solver, or extra calls in the batch.
Gaps show up when:
- Slippage bounds are wide enough to absorb MEV the UI labeled "protected"
- The preview path uses a public RPC state root while the solver submits via a private builder
- Callback-heavy routes (flash accounting, hooks, ERC-777-style tokens) differ between preview and execution
- Partial fills change the effective price without a clear user-facing invariant
Audit question: what state is bound at signature time, and what is only promised by policy?
### 2. Partial fills and order identity
Partial fills are a feature until idempotency breaks.
Patterns:
- The same logical intent filled twice under different batch nonces
- Remainder handling that leaves dust in a vault the user cannot recover
- Cancellation races: user revokes while a solver's transaction is in flight
- "Best effort" fills that satisfy the letter of min-out but not the product's implied single-shot trade
If the protocol keys fulfillment on order hash plus filler, trace what happens when two fillers believe they won, or when one fill consumes allowance in a way that bricks the second leg.
### 3. Batching and unrelated execution
Solvers batch intents to save gas. Batching also batches trust.
A user's intent may share a transaction with:
- Another user's swap
- A liquidation
- A governance vote relay
- A callback into a lending market
If the settlement contract does not isolate failure domains, one leg's revert or one leg's malicious hook can grief the batch. If it does isolate, understand who pays for that revert and whether the solver can reorder legs for advantage.
The user signed their intent. They did not sign the batch composition.
### 4. Hooks, callbacks, and reentrancy at fill time
Intent settlement often calls external protocols during fill: Uniswap v4 hooks, flash loans, bridge adapters, native wrap/unwrap.
Classic reentrancy and read-only reentrancy do not care that the entrypoint is named fillOrder instead of swap. Cross-function paths between "open fill" and "finalize fill" are common when surplus is skimmed or fees are distributed after the user's leg completes.
Review the fill path as a control-flow graph, not as an order book feature.
### 5. Solver set, reputation, and allowlists
Many systems advertise "permissionless solvers" with an onchain allowlist, stake, or slashing that is never enforced in practice. Others use a fixed set of partners with offchain SLAs.
Field questions:
- Who can add or remove a solver address, and with what timelock?
- Is stake sized for the daily flow through the contract, or for show?
- Does the UI route to one solver API that is effectively custodial?
- What happens when the only solver with inventory is also the protocol's market maker?
Decentralization of settlement is a claim. Map the actual selector of execution.
### 6. Cross-chain and RFQ intents
Cross-chain intents add a second execution path: message passing, relayers, and destination-chain fillers. RFQ and private-flow intents move price discovery offchain.
The user signs on chain A. Value moves on chain B. The solver or market maker sees the order before the public mempool does.
Threat-model:
- Relayer censorship or selective inclusion
- Destination filler that uses a different bridge than the user assumed from marketing copy
- Offchain quote expiry vs onchain deadline mismatch
- Signature replay across domains or chain IDs if typed data is loose
If cross-chain messaging is in scope for your bridge review, intent bridges need the same discipline on message identity and receiver handlers.
### 7. Surplus, fees, and hidden extraction
Protocols often let solvers keep positive surplus within the user's max slippage, or charge a protocol fee on output. Misconfigured fee recipients, surplus caps, and referral hooks are recurring bug classes.
Also watch "solver pays user gas" economics: the solver recovers from spread. Aggressive recovery can push users into worse pools that still satisfy min-out.
A practical review boundary
When we scope intent infrastructure, we extend the diagram past the settlement contract:
- Signed object: fields, versioning, cancellation, replay protection, cross-chain domain separation
- Constraint semantics: min-out, partial fill rules, expiry, token allowlists, recipient binding
- Fill entrypoints: who can call, reentrancy surface, batch isolation, failure/refund behavior
- Solver policy: allowlist, stake, slashing, ordering, private submission paths
- Preview honesty: what simulation binds vs what is advisory
- Downstream protocols: every external call during fill, including views other systems read mid-batch
- Ops: who runs the solver API, key custody on relayers, incident playbooks when fills stall
If any row is "the solver partner handles that," it is still in your incident channel when user funds move.
Closing note
Intent architecture trades calldata clarity for better execution. That trade is rational. It is also a relocation of trust from the wallet preview to the solver layer and the settlement rules that constrain it.
Teams that review only the onchain settlement contract will miss the failures that look like "the fill was valid." Teams that model solver selection, batch composition, and preview-to-settlement drift find them before the surplus disappears into someone else's inventory.
AN3 Intel · field notes on DeFi execution and trust boundaries.