Token Model

The IntentSettlerV1 protocol natively supports balance-stable ERC-20 tokens only.

Tokens with rebasing mechanics, fee-on-transfer mechanics, or arbitrary transfer hooks are not supported. This restriction exists because the settlement process utilizes balance-delta accounting. When the contract checks its balance, it cannot cryptographically distinguish between “the solver paid me” and “a balance I already held naturally grew.”

The Exact Guarantees

Within that model — and only within it — the following hold no matter how a solver behaves:

• The owner is never debited more than amountIn.
• The recipient is never credited less than the required floor.
• No stray donation can subsidize a fill.

The last guarantee is enforced through strict token conservation: the settler must end the execution holding the exact same balances it started with. Any direct token donations sent to the contract are permanently trapped. The contract deliberately omits a sweep function, as any administrative recovery path would require granting an entity authority over shared balances.

What is Not Guaranteed

Earlier iterations of the protocol claimed that “every exotic token fails closed.” That statement was too strong and no longer applies.

The protocol only measures the two legs that directly interact with the user:

• The pull from the owner to the settler.
• The delivery from the settler to the recipient.

A token out that taxes only the solver -> settler hop is completely invisible to the settler by construction (because the settler measures what it received, never what the counterparty sent), and will settle successfully. Symmetrically, an input token that taxes the flash-transfer (settler -> solver) shortchanges the solver.

Neither of these solver-facing paths are validated. Measuring the first is impossible under balance-delta accounting, and measuring the second would waste gas protecting sophisticated solvers who are fully capable of measuring the delivery and choosing their own tokens and routes.