Token approvals for AI agents

​

When to use this

• The user’s source token is an ERC-20 and you’re about to build a Market transaction, a Delta order, or an AugustusRFQ fill.
• You’re deciding whether to ask the user for a separate approve transaction, or whether to bundle a permit / permit2 payload into the build call instead.
• An earlier swap or order failed with an allowance error and you need to figure out which spender actually needed the approval.

​

The rule (read this first)

• Take the spender from the execution mode of the quote response, not from the user’s natural-language intent. If the quote response carries a top-level delta object, the Delta contract is the spender. If it carries a top-level market object, Augustus v6.2 is the spender.
• If the user asked for a Delta or RFQ flow on a chain without that contract, surface the limitation and offer the available alternatives. Do not silently fall back to a different mode.

​

Permit and Permit2: agent rules

• Detect Permit/Permit2 capability before asking the user for an on-chain approve; collect the signature instead when supported.
• A Permit/Permit2 signature is a user authorization, not a free no-op. Confirm with the user before requesting the signature, the same way you would confirm an on-chain approval.
• Permit/Permit2 signatures bind to a specific spender, amount, deadline, and (for Permit2) nonce. If you requote into a different mode, the existing signature is not transferable: collect a new one for the new spender.
• Delta LIMIT orders and TWAP rest or settle over time, so a permit’s nonce or deadline expires before settlement. Use an on-chain approval for these, not a permit. See Limit Orders and TWAP use on-chain approval.

​

Allowance checks before signing

​

Failure modes

​

Examples

​

Branching by quote response

1. GET /v2/quote?mode=ALL with chainId, srcToken, destToken, amount, partner
2. If response has top-level `delta`:
   - spender = 0x0000000000bbf5c5fd284e657f01bd000933c96d (Delta contract)
3. Else if response has top-level `market`:
   - spender = 0x6a000f20005980200259b80c5102003040001068 (Augustus v6.2)
4. Else:
   - Stop. No route. Do not request an approval.
5. If srcToken is native placeholder:
   - Skip approval. Proceed to build.
6. Else:
   - Read allowance(srcToken, owner=user, spender)
   - If allowance < amount:
     - If srcToken supports Permit/Permit2: collect signature, attach to build
     - Else: request approve(spender, amount) on the quote's chainId
   - Wait for approval confirmation before continuing
7. Continue to build → sign → submit

​

Switching modes mid-flow

• Requote in the new mode.
• Recheck allowance against the new spender. The previous approval does not carry over.
• Either approve again to the new spender, or attach a fresh Permit/Permit2 signature to the new build request.
• Confirm the user understands they’re approving a second contract.

​

Guardrails

• Take the spender from the quote response shape, not from natural language.
• Never approve Augustus for a Delta order. Never approve the Delta contract for a Market swap.
• Skip ERC-20 approval entirely for native source tokens; use the canonical mixed-case placeholder.
• Detect Permit/Permit2 capability before requesting a separate approve transaction.
• Use an on-chain approval, never a permit, for Delta LIMIT orders and TWAP.
• Re-check allowance against the new spender any time the execution mode changes.
• Treat Permit/Permit2 signatures as one-shot authorizations bound to spender, amount, and deadline; they do not transfer across modes or builds.
• Never assume an infinite allowance to one spender covers another.