Skip to content

Intent Execution Boundaries

An intent architecture is safe only when it preserves the user's mandate, resource authority, solver discretion, execution payload, and settlement evidence as separate boundaries.

The design problem

An intent states an acceptable outcome while leaving some execution choices open. That flexibility can improve routing or user experience, but it creates a trust boundary: another actor may choose venues, timing, payloads, or counterparties while using resources the user controls.

The architecture must make the allowed freedom machine-checkable and retain enough evidence to explain why one execution was permitted.

Mandate and resource boundaries

The mandate should bind:

  • input and acceptable output assets;
  • minimum, maximum, or pricing conditions;
  • amount and permitted partial behavior;
  • expiry and replay domain;
  • permitted fillers, solvers, or execution classes;
  • fee and residual-value rules; and
  • settlement destination.

Resource authority should be narrower than the application roadmap. A lock, approval, or signed order identifies the resource, owner, amount, scope, delegate, expiry, and revocation model. It should not silently authorize arbitrary calls or future features.

Discovery and validation

Solvers can produce quotes, routes, payloads, or proofs. Those are proposals until validated against the mandate and current state.

A validation boundary should:

  1. parse the proposal into a bounded execution model;
  2. verify solver or filler eligibility;
  3. check authorization, expiry, nonce, and replay state;
  4. evaluate price or oracle conditions;
  5. simulate or otherwise validate effects where the domain requires it;
  6. cap fees and residual-value behavior; and
  7. produce one exact authorized payload.

Missing or failed validation is a rejection or retryable evaluation state—not permission to execute.

Execution and settlement

Execution consumes the exact authorized payload and records submission separately from outcome. Atomic execution can keep resource movement and exchange in one transaction, but it does not prove user satisfaction until outputs, fees, and residual value are observed and checked.

Delayed or cross-chain execution requires explicit states for expiry, cancellation, partial fulfillment, ambiguity, destination observation, and recovery. No generic “filled” flag should replace the evidence needed by the mandate.

Failure modes and controls

Important failure modes include:

  • a solver payload exceeding the signed mandate;
  • stale oracle or route data passing after conditions move;
  • reusable resource authority being replayed or retained too long;
  • callback or hook reentrancy crossing an authority boundary;
  • residual value or fees going to an unintended party;
  • submission being presented as settlement;
  • a delayed intent becoming unowned after expiry or failure; and
  • third-party protocol guarantees being assumed rather than verified.

Controls should be local to the boundary they protect: exact authorization, nonce and expiry, allowlisted call surfaces, fail-closed validation, bounded callbacks, independent outcome checks, and explicit recovery states.

Alternatives and trade-offs

Direct swaps reduce solver and mandate complexity but expose route choice and timing to the user or application. Request-for-quote systems narrow competition to invited counterparties and can simplify validation, at the cost of less open discovery. Onchain auctions improve transparency but may expose intent information and add latency or transaction cost.

Reusable resource locks can reduce repeated approvals and capital movement, but they increase revocation, lifecycle, and delegate-risk obligations. Atomic financing can reduce upfront principal for a bounded transaction while retaining infrastructure, RPC, operational, gas, and failed-transaction costs.

Validation boundaries

Prototype validation should prove:

  • mandate encoding and signature domain;
  • expiry, nonce, cancellation, and replay behavior;
  • exact asset and amount authority;
  • allowed and rejected solver payloads;
  • callback and reentrancy behavior;
  • oracle and simulation failure handling;
  • output, fee, and residual-value accounting; and
  • recovery after delay, revert, ambiguous response, or partial progress.

Passing local contract tests does not establish an audited protocol, production solver network, partner integration, economic sustainability, or cross-chain security.

Go deeper