Settlement Execution

Settlement occurs permissionlessly via the IntentSettlerV1’s fill function. It executes as an atomic flash-swap, pulling funds from the owner, invoking the solver’s callback, and guaranteeing the delivery of the required output.

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.

Order of Operations

1. Validation: The order is checked against IntentLib.validate. The call reverts immediately if the order has been cancelled, if the current time is before startTime or past endTime, or if the solver address is zero.
2. Pricing: The required minimum output is evaluated using IntentLib.requiredOut(order, block.timestamp).
3. Pulling Input: Permit2’s permitWitnessTransferFrom pulls exactly amountIn of tokenIn from the owner to the settler contract itself. This specific step consumes the Permit2 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, required, routerData).
6. Output Measurement: The settler measures receivedOut by analyzing its own balance delta. If it received less than required, it reverts with SlippageExceeded.
7. Delivery: The settler transfers everything received to the order’s recipient. If the delivered amount is less than required, it reverts with InsufficientRecipientDelivery. If the delivered amount doesn’t perfectly match receivedOut, it reverts with InexactOutputDelivered.
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.

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

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 requiredOut to the settler and nothing more.

If the solver happens to overpay and returns more than the required floor, the settler transfers that excess entirely to the recipient. The surplus is never refunded to the solver. Refunding it would be an unnecessary round trip returning the solver its own money, introducing complex post-callback token interactions that create ordering hazards. By paying any overpayment directly to the recipient, the invariant is simple: everything that comes in goes to the party the order exists for.