Skip to content
AgentSwap Docs
docs/protocol/settlement

Settlement Execution

Settlement occurs permissionlessly via IntentSettlerV3.fill. It executes as an atomic flash-swap, asking the owner’s proxy to pull funds, invoking the solver’s callback, and delivering the required output. V6’s requiredOut is gross: the recipient floor plus the protocol fee.

The execution is strictly protected against reentrancy using an EIP-1153 transient storage guard (Reentrancy). This is why the protocol only supports EVM chains capable of transient storage.

One fill transaction: the settler pulls the input through the owner's proxy, flash-transfers it to the solver, measures the returned output, and delivers it. owner's UserProxyV6 IntentSettlerV3 solver IntentLib.validate floor · override · fee → requiredOut pullForIntent(order, auth) pulls exactly amountIn from the owner the proxy consumes the owner's nonce _requireExactReceipt else InexactInputReceived flash-transfer amountIn fillIntentCallback (order, requiredOut, routerData) ≥ requiredOut of tokenOut the solver keeps its margin by not sending it measure receivedOut else SlippageExceeded two measured legs recipient floor, plus any excess received FeeVault 3 bps fee, paid by the filler _requireConserved · filled[id] = true else SettlerBalanceChanged
One fill transaction. Every step is a measured balance delta on the settler, which is why a fill either satisfies all three checks or reverts whole.

Order of Operations

Section titled “Order of Operations”
  1. Validation: The order is checked against IntentLib.validate. The call reverts immediately if the order has been cancelled, if it is past endTime, or if the solver address is zero. V6 orders may fill before startTime.
  2. Pricing: V6 computes the signed curve floor, applies the outsider’s 25 bps override when applicable, computes the 3 bps fee on that floor, and sets requiredOut to the gross total.
  3. Pulling Input: The owner’s UserProxyV6 verifies auth and pulls exactly amountIn of tokenIn from the owner to the settler. The proxy consumes the owner’s proxy nonce.
  4. Exact Receipt: _requireExactReceipt verifies that the transfer arrived perfectly. The settler’s balance must have increased by exactly amountIn, reverting with InexactInputReceived otherwise.
  5. Flash Callback: The amountIn is flash-transferred directly to the solver. The settler then calls IIntentFiller(solver).fillIntentCallback(order, requiredOut, routerData). The callback must return the gross requirement, not only the owner’s floor.
  6. Output Measurement: The settler measures receivedOut by analyzing its own balance delta. If it received less than requiredOut, it reverts with SlippageExceeded.
  7. Delivery: The settler transfers the gross amount received as two measured legs: the floor to the recipient and the 3 bps fee to FeeVault. An outsider’s 25 bps override is part of the recipient floor. Any additional amount received is sent to the recipient.
  8. Conservation: Finally, _requireConserved runs on both tokens. The settler contract must end the transaction holding exactly the same token balances it started with, or it reverts with SettlerBalanceChanged. V6 also records filled[id], so the same order cannot be filled twice.

A recipient of the settler itself always fails

Section titled “A recipient of the settler itself always fails”

recipient is whatever the owner signed, and the settler never substitutes its own. One value is worth naming because it fails in a way that looks surprising: an order whose recipient is the settler address can never settle. The delivery step measures the recipient’s balance before and after, and an ERC-20 self-transfer leaves that balance flat, so delivered is 0 and the fill reverts with InsufficientRecipientDelivery.

Surplus Distribution

Section titled “Surplus Distribution”

Surplus belongs to the filler by construction, not by a payout rule.

The solver keeps its margin by never sending it to the settler. The fillIntentCallback is expected to return exactly the gross requiredOut to the settler and nothing more.

If the solver happens to overpay and returns more than the gross requirement, the settler transfers that excess entirely to the recipient. The surplus is never refunded to the solver. The protocol fee is not surplus: it is 3 bps of the floor, paid by the filler on top and sent to FeeVault, never taken from the owner’s proceeds.