Threat Model
This document outlines the threat landscape for IntentSettlerV1, detailing the adversaries the protocol anticipates, the structural controls mitigating them, and the residual risks accepted by the design.
Security Boundary
Section titled “Security Boundary”IntentSettlerV1 operates as one immutable, ownerless contract per chain. A user signs a single Permit2 witness detailing an exact order. Any actor can announce or fill this order, and any solver can receive the flash-transferred input during the callback. Delivering at least the signed Dutch or limit floor to the recipient is necessary for the execution to succeed, not sufficient: a valid signature, an unspent nonce, the time window, an exact input receipt, an exact output delivery and end-of-fill balance conservation must all hold too, or the whole transaction reverts.
The contract maintains no administrative controls and keeps no funds across transactions. It is not fundless mid-fill — it holds the input between the Permit2 pull and the flash transfer, and the solver holds it during the callback — but every such position is transient and atomic. Tokens sent to the settler outside a fill are the one lasting balance, and they are trapped.
Adversaries and Controls
Section titled “Adversaries and Controls”Malicious Filler, Solver, or Router
Section titled “Malicious Filler, Solver, or Router”The fill entry point and the solver callback are fully permissionless. While the solver receives the amountIn during the flash callback, the entire transaction strictly reverts unless the settler receives the required output and perfectly delivers the signed floor to the recipient. A transient reentrancy guard (Reentrancy) blocks any nested fills through the shared settler, preventing complex internal accounting attacks.
Forged or Replayed Authorization
Section titled “Forged or Replayed Authorization”The canonical Permit2 contract verifies the owner’s signature and permanently consumes the unordered nonce. The witness cryptographically binds the owner, both tokens, the input amount, the curve parameters, the time window, and the immutable settler contract as the sole spender. Replay attacks are structurally impossible because the Permit2 nonce is spent upon the first successful pull.
Malicious Relayer or Announcer
Section titled “Malicious Relayer or Announcer”Order announcement and gasless cancellation are permissionless broadcasts. A relayer cannot alter a signed order, nor can they redirect its funds. The most a relayer can do is censor or delay their own broadcast. To mitigate this, users retain direct, permissionless paths to self-announce, execute standard on-chain cancel calls, or directly invalidate the Permit2 nonce.
Token Accounting Attacks
Section titled “Token Accounting Attacks”The protocol expects balance-stable ERC-20 tokens. Exact input receipt rejects transfer-taxed inputs, and the recipient must be credited exactly what the settler sent. End-of-fill conservation strictness prevents an external token donation from artificially subsidizing a sender’s short pull.
Tokens taxing legs that the settler cannot physically observe (such as the solver’s transfer to the settler) will settle successfully. This places the burden entirely on the solver to measure and account for exotic routing, preventing the settler from wasting gas to protect sophisticated execution agents.
Cancellation Races and MEV
Section titled “Cancellation Races and MEV”On-chain cancellation transactions do not front-run fill transactions already present in the mempool. The EVM dictates that whichever valid transaction lands first wins the race. The primary protection against adverse execution and MEV is the signed Dutch curve and deadline; the contract does not consult an external oracle.
Accepted Residuals
Section titled “Accepted Residuals”The protocol accepts the following residual outcomes by design:
- A valid order may simply remain unfilled because solver participation and market execution are not guaranteed.
- Announcement logs may carry signatures that later become invalid or nonces that are eventually spent elsewhere.
- Any tokens erroneously donated directly to the settler are permanently trapped.
- Unsupported token mechanics may make an order practically unfillable.
- A user might sign an economically poor curve or floor; the protocol enforces the cryptographic intent, not external market quality.
- Calling
approve(Permit2, 0)is not a permanent revocation if the approval is later restored while an old signature remains active. Nonce invalidation is the durable backstop, at nonce granularity — it kills every signed order sharing that owner and nonce, whilecancelandcancelSignedare the per-order paths.