A swap can deliver the tokens you wanted and still leave a contract with permission to spend more. What if returning unused tokens and revoking the route's remaining approvals were conditions for letting the trade stand?
The Ethereum Foundation explores that possibility in its October 5 research post on transaction assertions. An agent could choose the swap route, but the transaction would have to leave the balances and approvals required by the account's policy. The route would need to do the cleanup itself. The assertion would only check the result and reject it if something was left behind.
Minimum-output checks already reject swaps that deliver too little. The proposed addition is broader access to net balance and storage changes, including storage a contract offers no function to read. That could let a check ask what else the route changed, beyond the expected token transfer. EIP-7906, a draft implementation, defines limits on what those checks can see; it isn't an exhaustive record of every change.
For this swap condition to hold, the account would have to require a specific, independently approved rule. The app building the route couldn't be allowed to omit it or rewrite its requirements. Otherwise, a check that permits leftover approvals would let the same result through.
Under EIP-7906, a failed check would reverse the execution actions, but gas charges and changes made during the transaction's validation phase would remain. The swap actions would have to sit in the execution body, outside that non-reverted prefix.
This is still a proposal. Its boundary is one transaction on one network. A correctly enforced return-and-revoke rule could reject this swap for leaving those permissions behind; it would not police an older allowance used in a separate transaction.
Sources:
https://blog.ethereum.org/2026/10/05/transaction-assertions
https://eips.ethereum.org/EIPS/eip-7906
Image: AI-generated editorial illustration, not a product screenshot or an actual transaction.
The Ethereum Foundation explores that possibility in its October 5 research post on transaction assertions. An agent could choose the swap route, but the transaction would have to leave the balances and approvals required by the account's policy. The route would need to do the cleanup itself. The assertion would only check the result and reject it if something was left behind.
Minimum-output checks already reject swaps that deliver too little. The proposed addition is broader access to net balance and storage changes, including storage a contract offers no function to read. That could let a check ask what else the route changed, beyond the expected token transfer. EIP-7906, a draft implementation, defines limits on what those checks can see; it isn't an exhaustive record of every change.
For this swap condition to hold, the account would have to require a specific, independently approved rule. The app building the route couldn't be allowed to omit it or rewrite its requirements. Otherwise, a check that permits leftover approvals would let the same result through.
Under EIP-7906, a failed check would reverse the execution actions, but gas charges and changes made during the transaction's validation phase would remain. The swap actions would have to sit in the execution body, outside that non-reverted prefix.
This is still a proposal. Its boundary is one transaction on one network. A correctly enforced return-and-revoke rule could reject this swap for leaving those permissions behind; it would not police an older allowance used in a separate transaction.
Sources:
https://blog.ethereum.org/2026/10/05/transaction-assertions
https://eips.ethereum.org/EIPS/eip-7906
Image: AI-generated editorial illustration, not a product screenshot or an actual transaction.