Paying for API work from an autonomous agent: x402 v2 exact + Permit2 on Ethereum mainnet

A field guide with sources. Research date: 2026-09-25.

---

0. How to read this guide

Every substantive claim carries a tag and a source ID (the sources are listed in §10):

Tag	Meaning
[F]	Fact. Stated in a primary source (spec text, contract source, reference SDK source) or observed directly on chain.
[I]	Inference. My reasoning from the facts. It is not stated in any source.
[U]	Uncertain. Sources disagree, the behaviour depends on the implementation, or I could not verify it.
[Q]	Open question. I could not answer it from the sources available.

Primary sources. All citations are pinned to fixed commits:

• the x402 specification and reference implementation, x402-foundation/x402 at commit 4fcf836 (2026-09-25). The v2 spec names this repository as its basis [S2 §1]. An older clone of coinbase/x402 (dd927a2, 2026-04-21) carries the same Permit2 design;
• Uniswap Permit2, Uniswap/permit2 at commit cc56ad0;
• direct JSON-RPC reads against Ethereum mainnet at block 26,056,849 (2026-09-25 20:27 UTC) [S19].

0.1 A correction to the brief

The brief describes the flow as "a Permit2 witness signature and a second EIP-712 signature that binds the payment to the quote", and lists "a payment hash that does not match" as a failure mode.

• [F] The normative x402 v2 exact/EVM/Permit2 flow needs one client signature: the Permit2 PermitWitnessTransferFrom EIP-712 signature. The payload contains only signature and permit2Authorization [S1 Phase 2]. Nowhere in the core spec, the HTTP transport or the exact-EVM scheme is the client asked to sign a quote, and none of them defines a "payment hash".

• [F] The spec does define a second EIP-712 signature, but the resource server produces it, not the client. This is the signed Offer in the optional offer-receipt extension, signed under the domain {name:"x402 offer", version:"1", chainId:1} [S13 §4]. It commits the server to resourceUrl, scheme, network, asset, payTo, amount, validUntil. It is not checked on chain, and it is not tied cryptographically to the client's Permit2 signature.

• [F] Two other things are close to a "payment hash":

  • the auth-capture scheme, which is a different scheme from exact, derives paymentInfoHash and a salt-binding commitment [S15];
  • the repository's e2e test facilitator computes sha256(JSON.stringify(paymentPayload)) to check that a payload reaching /settle was verified within the previous 5 minutes [S23]. This is test code, not protocol.

• [I] So the guide below does two things:

  1. It documents the standard flow exactly as specified.
  2. It treats "second signature binding payment to quote" as a binding layer. You can build that layer from the signed Offer plus the accepted echo plus payment-identifier, or a particular facilitator may add a proprietary version of it. §2.3 and §5.4 cover what such a layer protects against and how it fails.

  If your facilitator really does require a client-signed quote binding, it is vendor-specific. Get its type string and domain from that vendor. Do not guess them (see §9 Q1).

---

1. The components

Component	On Ethereum mainnet (eip155:1)	Evidence
Canonical Permit2	0x000000000022D473030F116dDEE9F6B43aC78BA3	[F] Constant in SDK [S6-const]; bytecode present on mainnet [S19]
x402ExactPermit2Proxy (the only permitted spender)	0x402085c248EeA27D92E8b30b2C58ed07f9E20001	[F] Spec canonical address [S1 Annex]; bytecode present on mainnet, and PERMIT2() returns the canonical Permit2 address [S19]
Default mainnet stablecoin in the SDK	USDC 0xA0b8…eB48, EIP-712 name "USD Coin", version "2"	[F] [S20]
Client	Your agent. Holds the payer key, signs, and retries the HTTP request	[S2 §3]
Resource server	Issues the 402 challenge, calls /verify and /settle	[S2 §3, §7]
Facilitator	Verifies, then broadcasts proxy.settle(...) and pays the gas	[F] "the Facilitator … pays the gas … cannot modify the amount or destination" [S1 Summary]

Why Permit2 on mainnet?

• [F] Mainnet USDC supports EIP-3009. The spec says that when extra.assetTransferMethod is absent, clients default to eip3009, and Permit2 is used only when the server sets "assetTransferMethod":"permit2" [S1 Summary; §2 extra definitions].
• [I] In practice, you will meet Permit2 on mainnet for tokens that lack EIP-3009, or when a server deliberately chooses Permit2. Your client must follow what the challenge says and must not assume a method.

---

2. The full message flow

Agent (client)                Resource server                 Facilitator                 Ethereum mainnet
     |  (0) optional: discovery / price list (Bazaar)                 |                             |
     |--(1) GET /resource ------------->|                              |                             |
     |<-(2) 402 + PAYMENT-REQUIRED -----|  (price quote = accepts[])   |                             |
     |      [+ optional signed Offer]   |                              |                             |
     |  (3) policy check, allowance/balance pre-check (reads) ------------------------------------->|
     |  (4) sign Permit2 witness (EIP-712, domain Permit2/chainId 1)   |                             |
     |--(5) retry + PAYMENT-SIGNATURE ->|                              |                             |
     |                                  |--(6) POST /verify ---------->| sig, allowance, balance,    |
     |                                  |<-- isValid ------------------| window, amount, simulate -->|
     |                                  |  (7) do the work             |                             |
     |                                  |--(8) POST /settle ---------->|--(9) proxy.settle(...) ---->|
     |                                  |<-- tx hash ------------------|    Permit2 checks + transfer|
     |<-(10) 200 + PAYMENT-RESPONSE ----|  [+ optional signed Receipt] |                             |

2.1 Price quote and HTTP 402 challenge (steps 1–2)

• [F] The server responds 402 Payment Required. It carries a base64-encoded PaymentRequired object in the PAYMENT-REQUIRED header [S3].
• [F] Each accepts[] entry is the quote: scheme, network (CAIP-2, eip155:1 for mainnet), amount (atomic units, a string), asset, payTo, maxTimeoutSeconds and extra [S2 §5.1.2].
  • For Permit2, extra.assetTransferMethod MUST be "permit2".
  • extra.name and extra.version are required only when the token supports EIP-2612 gasless approval [S1 §2].
• [F] The reference server SDK sets maxTimeoutSeconds to 300 s when the route does not configure it [S11].
• [F] A server that uses the offer-receipt extension can add a signed Offer for each accepts[] entry, with an optional validUntil [S13 §4.1–4.2].

2.2 The Permit2 witness signature (step 4) — the only client signature in the standard flow

• [F] EIP-712 domain: { name: "Permit2", chainId: <from network>, verifyingContract: 0x0000…78BA3 }. There is no version field [S6 L648; S18 L15–17].
• [F] Primary type and full type string, as Permit2 reconstructs it on chain [S17 L31–32; S4 L22]:

PermitWitnessTransferFrom(TokenPermissions permitted,address spender,uint256 nonce,uint256 deadline,Witness witness)
TokenPermissions(address token,uint256 amount)
Witness(address to,uint256 validAfter)

• [F] How the reference client fills the fields [S6 L590–629]:

Field	Value
permitted.token	accepted.asset
permitted.amount	accepted.amount
spender	the x402 exact proxy (not the facilitator) [S1 Phase 2]
nonce	256 random bits [S10 L61]
deadline	now + maxTimeoutSeconds
witness.to	accepted.payTo
witness.validAfter	0 ("allow some clock skew")

• [F] The wire payload is { signature, permit2Authorization: { from, permitted, spender, nonce, deadline, witness } }. It sits inside a PaymentPayload that also echoes the chosen requirements as accepted [S1 Phase 2; S2 §5.2].

What this signature authorizes

• [F] It authorizes one pull of exactly permitted.amount of permitted.token from from:
  • only through Permit2;
  • only when msg.sender == spender, because Permit2 hashes msg.sender into the digest in the spender slot [S17 L93];
  • only to witness.to, because the proxy passes witness.to as the transfer destination and hashes it into the witness [S4 settle(); S5 L127–135];
  • only while block.timestamp ≤ deadline [S16 L60];
  • only when block.timestamp ≥ validAfter [S5 L130];
  • at most once, because of the nonce [S16 L63, L150–156].
• [F] The exact proxy always requests exactly permit.permitted.amount [S4 settle()]. The facilitator cannot change the amount or the recipient [S1 Summary].

What it does not bind

• [I] From the type string above: the signature does not cover the resource URL, the HTTP request, the quote identity, the server's identity, or which facilitator will settle it.
  • For comparison: [F] the upto scheme adds witness.facilitator "preventing unauthorized settlement by other parties" [S14 L66]. exact does not do this.
• [I] Anyone who obtains a valid exact payload before it settles can submit it. The only thing they can achieve is paying the intended payTo the intended amount. That cannot steal funds, but it can burn the nonce or front-run the server's settlement.
• [I] The signature also does not stop a payee from reusing a payment you signed for request A to gate request B at the same price, because nothing on chain links the payment to a particular request. Only the server's own bookkeeping does. This gap is what a "quote-binding" second signature would close (§2.3).

2.3 The "second EIP-712 signature" — what exists and what it binds

Artifact	Signer	Domain	Binds	Enforced where	Source
Permit2 witness sig	Client	Permit2 / chainId / Permit2 address	token, amount, spender(proxy), nonce, deadline, to, validAfter	On chain	[S1, S16, S17]
Signed Offer (offer-receipt ext.)	Server	"x402 offer", v"1", chainId 1 always	resourceUrl, scheme, network, asset, payTo, amount, validUntil	Off chain, by the client/auditor; the server "MAY reject" when now > validUntil	[F] [S13 §3.2, §4.3, §4.6]
Signed Receipt (same ext.)	Server	"x402 receipt", v"1", chainId 1	network, resourceUrl, payer, issuedAt, optional tx hash	Off chain	[F] [S13 §5]
payment-identifier id	Client (unsigned string)	—	idempotency key. The server should bind it to a fingerprint of scheme/network/asset/amount/payTo/route	Server/facilitator. Same id + different payload → 409	[F] [S12]

Using the Offer and accepted together as the binding layer

• [I] A client can get most of the "payment ↔ quote" binding like this:

  1. Verify the signed Offer, including the signer-authorization check that [S13 §4.5.1] requires. A valid signature on its own proves nothing about who is entitled to sign.
  2. Check that the Offer fields equal the chosen accepts[] entry, and the entry equals the Permit2 fields (asset = permitted.token, amount = permitted.amount, payTo = witness.to).
  3. Set the Permit2 deadline to no later than validUntil.
  4. Send a payment-identifier id so that retries are idempotent.

  Both sides then hold the same signed terms, and the on-chain transfer can only execute those terms.

• [U] The spec gives no way to carry an Offer hash inside the Permit2 witness. The exact witness type is fixed at Witness(address to,uint256 validAfter) and was reduced post-audit ("post-audit: extra removed from Witness") [S1 Annex, L378]. A binding that is cryptographically enforced on chain would need a different proxy or witness type, i.e. a different contract.

2.4 Verification (step 6)

[F] The spec's ordered checks [S1 Phase 3]:

1. The signature recovers to from.
2. ERC20.allowance(from, Permit2) ≥ amount. If it is not, a sponsoring extension must be present; otherwise the error is PERMIT2_ALLOWANCE_REQUIRED.
3. The balance is sufficient.
4. The amount covers the payment.
5. deadline has not passed and validAfter is active.
6. Token and network match.
7. Simulate proxy.settle (recommended).

[F] The reference facilitator is stricter than the spec [S8 L97–222]:

• spender must equal the exact proxy;
• witness.to must equal payTo;
• deadline ≥ now + 6 s (a 6-second buffer);
• validAfter ≤ now;
• amount exactly equal to requirements.amount;
• token equal to asset;
• signature verified the way Permit2 does it: ecrecover for code-less addresses, strict EIP-1271 for contracts;
• then a simulation. When the simulation fails, a diagnostic multicall reports whether the proxy is missing, the balance is short, or the allowance is short [S6 diagnosePermit2SimulationFailure].

2.5 Settlement (steps 8–9) — facilitator pays gas

• [F] /settle re-runs verification (simulation is off by default) and then calls x402ExactPermit2Proxy.settle(permit, owner, witness, signature) [S8 L384–456].
• [F] The proxy then:
  • reverts on amount==0, owner==0 or to==0;
  • reverts with PaymentTooEarly when now < validAfter;
  • calls PERMIT2.permitWitnessTransferFrom [S5 L127–135].
• [F] Permit2 then:
  • reverts SignatureExpired when now > deadline;
  • reverts InvalidAmount when the requested amount exceeds the permitted amount;
  • consumes the nonce;
  • verifies the signature;
  • transfers the tokens [S16 L60–65].
• [F] When the transaction is broadcast but its receipt cannot be confirmed, the facilitator MAY return the non-terminal settlement_pending with the tx hash. The caller should reconcile on chain before retrying [S2 §9; S1 Phase 4].
• [F] Sponsored-approval variants:
  • settleWithPermit: an EIP-2612 permit to Permit2, executed atomically inside the proxy. The proxy requires permit2612.value == permitted amount [S5 L154] and does not revert when the 2612 permit call fails, in case the allowance already exists [S5 _executePermit].
  • erc20ApprovalGasSponsoring: the facilitator batches a funding transfer, approve(Permit2), then settle [S1 Phase 1 B].
• [I] On mainnet, the facilitator's gas cost per settlement (a Permit2 transfer through a proxy) is large compared with micro-payments. Expect facilitators to set minimum amounts or fees, or to decline to serve mainnet. The spec does not address this economics question (§9 Q3).

---

3. Why the signature cannot be replayed elsewhere

Replay attempt	What stops it	Source
Another chain (L2, testnet)	The EIP-712 domain separator includes block.chainid and Permit2's address, so a mainnet signature fails verification anywhere else	[F] [S18 L27–34]
Another spender (facilitator EOA, a malicious contract)	Permit2 hashes msg.sender in the spender slot, so only the exact proxy produces a matching digest	[F] [S17 L93]
Another recipient	witness.to is inside the signed witness hash, and the proxy uses it as the destination	[F] [S4; S5 L133–135]
A larger amount	Permit2 reverts InvalidAmount when requested > permitted, and the exact proxy always requests exactly permitted.amount	[F] [S16 L61; S4]
Another token	permitted.token is signed	[F] [S17]
The same payment twice	The unordered nonce bitmap: the bit is flipped on use, and a second use reverts InvalidNonce	[F] [S16 L142–156]
Later, after the job is abandoned	deadline	[F] [S16 L60]
The upto proxy or another Permit2 integrator	Different spender address and a different witness type string (upto adds facilitator), so the digest differs	[F] [S14 L313]; [I] type-string argument
Another resource at the same server/price	Not prevented on chain. It depends on server bookkeeping and payment-identifier request binding	[I] from the type string; [S12 Request Binding]
Another facilitator submitting it	Not prevented for exact. The outcome is still "pay payTo the signed amount once"	[I]; contrast upto [S14 L66]
The server's signed Offer replayed	validUntil, if present; the spec warns about long-lived offers	[F] [S13 §10]

---

4. Nonces, deadlines and quote expiry

4.1 Nonces

• [F] Permit2 SignatureTransfer nonces are unordered. The upper 248 bits select a 256-bit word in nonceBitmap[owner] and the low 8 bits select a bit [S16 L142–145]. Using a nonce XOR-flips its bit, and the call reverts when the bit was already set [S16 L150–156].
• [F] The reference client draws 32 random bytes [S10 L61].
• [I] Consequences:
  • no sequencing is needed, so parallel payments from one wallet do not block each other;
  • random 256-bit nonces make collisions negligible;
  • nonces are per owner, not per spender, so one nonce space is shared by every Permit2 signature-transfer that wallet ever signs, including those for non-x402 apps.
• [F] An owner can cancel outstanding signatures ahead of time with invalidateUnorderedNonces(wordPos, mask) [S16 L130–134].
  • [I] This is the only way to revoke a signed but unsettled payment before its deadline. It costs gas on mainnet.
• [F] The nonce is consumed before the signature is verified, within the same transaction [S16 L63–65].
  • [I] The whole transaction reverts on any failure, so a failed settle does not burn the nonce. Only a successful transfer does.

4.2 Deadlines and validity window

• [F] Permit2 enforces the upper bound: block.timestamp > deadline → SignatureExpired [S16 L60].

• [F] The proxy enforces the lower bound: block.timestamp < validAfter → PaymentTooEarly [S5 L130].

• [F] The reference client uses validAfter = 0 and deadline = now + maxTimeoutSeconds [S6 L600–602].

• [F] The reference facilitator rejects deadline < now + 6 at verify time [S8 L140–147].

• [I] The window has to cover all of these:

  1. the time the server spends doing the work in the default authorization flow (verify → resource → settle [S2 §6.1]);
  2. /settle latency;
  3. mainnet inclusion (~12 s slots, plus congestion).

  A deadline that is too short fails after the server has already done the work. The spec leaves the server's handling of that case undefined. One that is too long widens the window during which a leaked payload stays valid.

4.3 Quote expiry and how the three clocks interact

• [F] There are up to three expiry clocks:
  1. maxTimeoutSeconds from the quote [S2 §5.1.2];
  2. the optional Offer validUntil, which the server "MAY" enforce [S13 §4.6];
  3. the Permit2 deadline, which is enforced on chain.
• [I] Recommended rule: deadline = min(now + maxTimeoutSeconds, offer.validUntil (if non-zero), now + your own policy cap).
  • Never sign a deadline later than the quote's own expiry.
  • Treat a quote as dead once now + expected_work_time + ~30 s (mainnet inclusion margin) > deadline, and fetch a new 402 instead.
• [I] A re-quote must produce a new nonce and signature. Resending the old payload after the window has passed fails with permit2_deadline_expired.
• [I] Clock skew: validAfter=0 sidesteps skew on the lower bound. On the upper bound, the facilitator's clock (verify) and block time (settle) are what count, not yours.

---

5. The concrete ways a payment fails

The error strings are those of the reference TypeScript facilitator [S9]. Other facilitators may use different strings [U].

5.1 Missing Permit2 allowance

Symptom	Verify returns permit2_allowance_required. The spec calls for 412 Precondition Failed / PERMIT2_ALLOWANCE_REQUIRED [S1 Phase 3 step 2]; the SDK returns an invalidReason string [S6 verifyPermit2Allowance]
Cause	token.allowance(payer, Permit2) < amount, and no valid eip2612GasSponsoring or erc20ApprovalGasSponsoring extension is attached
Fix	Send approve(Permit2, X) on mainnet, paying ETH gas, or attach a sponsoring extension that the server/facilitator advertises. Then retry with a fresh signature if the deadline has passed
Note	[U] The spec says 412, but the HTTP transport table maps a verification failure to 402 [S3 Error Handling]. Handle both

5.2 Insufficient balance

Symptom	permit2_insufficient_balance (diagnostic) or generic insufficient_funds [S9; S2 §9]
Cause	Token balance < amount at verify time, or at settle time, e.g. a parallel payment drained the wallet between the two
Fix	Reserve funds locally before signing (§8). Keep the balance above your in-flight total

5.3 Expired or not-yet-valid window

Symptom (verify)	permit2_deadline_expired (includes "expires in < 6 s") or permit2_not_yet_valid [S8 L140–155]
Symptom (settle)	Permit2 SignatureExpired or proxy PaymentTooEarly, mapped to invalid_permit2_signature or permit2_payment_too_early [S6 mapSettleError]
Fix	Re-request the 402 and sign again with a new nonce. Size the deadline as described in §4.2
Note	[F] The reference mapper folds SignatureExpired into invalid_permit2_signature [S6], so an "invalid signature" at settle may actually mean "expired"

5.4 Payment does not match the quote (the "payment hash mismatch")

In the standard flow, a mismatch appears as one of these errors:

• permit2_amount_mismatch: amount ≠ quote. It must be exactly equal in the reference implementation.
• invalid_permit2_recipient_mismatch: witness.to ≠ payTo.
• permit2_token_mismatch.
• invalid_permit2_spender: spender ≠ exact proxy.
• invalid_exact_evm_network_mismatch.
• invalid_permit2_signature: any field changed after signing changes the EIP-712 digest, which is the effective "hash mismatch" [S8 L105–222].

Other layers can also report a mismatch:

• payment-identifier: the same id with a different payload → 409 Conflict [S12].
• The signed Offer: if the Offer fields do not equal accepts[i], the client should refuse to pay [S13 §4.1.1].
• [U] A proprietary quote-binding signature, if your facilitator uses one, would fail on its own hash comparison. Its format and error codes are not standardized.
• [I] Common causes:
  • decimal/string mistakes ("1.00" instead of "1000000");
  • checksum or case differences that are not normalized before hashing;
  • sorting Witness wrongly in the EIP-712 types;
  • the wrong chainId (for example, reusing a Base config);
  • signing against a stale accepts[] after the server changed its price.

5.5 Reused nonce

Symptom	Settle reverts with Permit2 InvalidNonce, mapped to permit2_invalid_nonce [S16 L155; S6 mapSettleError]. Usually caught earlier as permit2_simulation_failed at verify time
Cause	The same payload is submitted twice (a retry after a successful but unacknowledged settle), a nonce was deliberately reused, or an earlier invalidateUnorderedNonces covered it
Fix	Before retrying, check on chain whether the prior tx landed (settlement_pending carries the hash [S2 §9]). Use payment-identifier so the server returns the cached result instead of settling again [S12]. Never recycle nonces

5.6 Other failures to handle

• permit2_proxy_not_deployed. [F] Not an issue on mainnet today [S19].
• settlement_pending. [F] Non-terminal: reconcile, do not re-sign blindly [S2 §9].
• permit2_simulation_failed (generic).
• invalid_exact_evm_payload_undeployed_smart_wallet. [F] Relevant to smart-account payers [S9].
• EIP-2612 extension errors (eip2612_deadline_expired, eip2612_spender_not_permit2, …) [S9].

---

6. Pre-flight checklist for client authors (one page)

Before the first payment (wallet setup)

• The wallet is a dedicated hot wallet used only by this agent (§7).
• allowance(wallet, Permit2) on the token is set to a bounded value, not MAX_UINT256. [F] The SDK helper createPermit2ApprovalTx approves MAX_UINT256 by default [S7 L13, L61], so override it.
• The wallet holds a little ETH for approval and invalidateUnorderedNonces, or you have confirmed that the server advertises eip2612GasSponsoring / erc20ApprovalGasSponsoring.
• Hard-code and pin the addresses: Permit2 0x000000000022D473030F116dDEE9F6B43aC78BA3, exact proxy 0x402085c248EeA27D92E8b30b2C58ed07f9E20001, and an allow-list of token addresses.

On every 402 challenge

• x402Version == 2, scheme == "exact", network == "eip155:1", and extra.assetTransferMethod == "permit2". Skip any paymentFlow you do not recognize [S2 §6.1].
• asset is on your allow-list. amount is parsed as an integer in atomic units, not a float.
• amount ≤ per-payment cap, and amount + reserved in-flight + spent today ≤ daily budget.
• payTo is on the allow-list, or matches the verified signed Offer and its signer authorization [S13 §4.5.1].
• If an Offer is present: its fields equal accepts[i] and validUntil has not passed.
• Balance ≥ amount + in-flight reservations. Allowance to Permit2 ≥ amount.

When signing

• Domain {name:"Permit2", chainId:1, verifyingContract:Permit2} with no version.
• spender = the exact proxy. witness.to = payTo. permitted = {asset, amount}, both copied exactly.
• nonce = 32 CSPRNG bytes; never reused, never derived from a counter visible to others.
• deadline = min(now+maxTimeoutSeconds, validUntil, now+policy max), and more than 6 s + expected work + inclusion margin into the future.
• validAfter = 0 unless you have a reason to delay.
• Record {payment-id, nonce, deadline, amount, payTo, resource} in a local ledger before sending.

When sending and afterwards

• Send PAYMENT-SIGNATURE over HTTPS only, and include a payment-identifier id. Reuse the same id on retries [S12].
• On settlement_pending: look up the tx hash on chain before doing anything else.
• On an expiry or mismatch error: re-fetch the 402 and re-sign with a new nonce. Never edit a signed payload.
• On permit2_allowance_required: stop and ask for approval (escalate to the operator). Do not approve automatically without a limit.
• Decode PAYMENT-RESPONSE and check that transaction exists on chain with the expected Transfer(from, payTo, amount).
• Release or commit the budget reservation according to the final on-chain outcome.

---

7. Spending controls the agent operator should enforce

• [F] The core spec states that "client-side budget management" is out of scope [S2 Document Scope] and describes budget controls as "implementation-specific" [S2 §12.1].
• [I] Everything below is therefore operator responsibility. It comes from the mechanics above, not from a standard.

1. Per-payment cap.
   • Reject any accepts[] entry whose amount exceeds a hard cap before signing. Enforce it in the signer and not only in the agent prompt or planner, because the signature is the last point you control.
   • Add a daily or rolling cap, a per-payTo cap, and a rate limit on the number of signatures per minute.
2. Bounded allowances.
   • ERC20.approve(Permit2, X) gives the Permit2 contract the right to move up to X. Any valid Permit2 signature from this wallet, for any spender or app, can draw on it.
   • Set X to roughly one day's budget and top it up deliberately. Do not use the SDK's MAX_UINT256 default [S7].
   • Keep in mind that the balance, not the allowance, is the real ceiling. That is why the wallet is kept small.
3. Dedicated hot wallet with a small balance.
   • Use one key per agent (or per agent × environment), funded with a working float of perhaps a few days of expected spend, and refilled from cold storage by a separate, human-gated process.
   • A compromised key then loses at most the float, even though Permit2 signatures carry no scope beyond each payment.
   • Monitor outgoing Transfer events and alert on any to that is not on the allow-list.
4. Short deadlines and revocation readiness.
   • Keep deadlines short (§4.2).
   • Keep an ops runbook for invalidateUnorderedNonces so that signed-but-unsettled payments can be killed, and for approve(Permit2, 0) to shut off all Permit2 pulls.
5. Sign-only boundary.
   • Keep the private key in a signer service or KMS that only signs PermitWitnessTransferFrom where spender = exact proxy, chainId = 1, the token is on the allow-list and the amount is within the cap.
   • It should refuse arbitrary typed data. The signer does not need to know about HTTP.

---

8. Worked example: sizing numbers (illustrative only)

[I] An agent pays ≈ $0.05 per call in USDC (50,000 atomic units) and makes ≈ 2,000 calls a day.

• Per-payment cap: 100,000.
• Daily budget: $150 (150,000,000).
• Permit2 allowance: 150,000,000, refreshed daily.
• Hot-wallet float: $300 plus about 0.01 ETH for approvals.
• Deadline: ≤ 120 s for jobs expected to take < 60 s.

These numbers are policy choices, not protocol values.

---

9. Open questions and known limits

• [Q1] Is a specific facilitator or vendor behind the brief's "second EIP-712 signature binding the payment to the quote" and "payment hash"? I found no such client-side signature in the x402 v2 specs, extensions or reference SDKs at 4fcf836 [S1–S3, S12–S14]. If a vendor defines one, obtain its type string, domain, and the rule for combining it with the Permit2 nonce and deadline.
• [Q2] Which production facilitators currently list eip155:1 + exact + Permit2 in /supported? The SDK can register mainnet [S8 register example; S20], but I did not query any live facilitator's /supported endpoint.
• [Q3] What are mainnet fee and minimum-amount policies of facilitators, given L1 gas? This is not specified anywhere.
• [U4] Status code for a missing allowance: the scheme text says 412, the transport table says 402, and the SDK returns an invalidReason string. Clients should handle all three.
• [U5] Behaviour of the verify → work → settle race when the deadline passes during the work: the spec does not say whether the server must still deliver or should refund. This is a server policy question.
• [U6] Tokens with non-standard approve semantics (for example, some tokens require setting the allowance to 0 before changing a non-zero value) affect "top up the bounded allowance" procedures. I did not verify this for specific mainnet tokens here.
• Limits of this research:
  • The research relies on specs and reference code at pinned commits and on two on-chain reads.
  • No live payment was executed.
  • No third-party facilitator was tested.
  • The audit status of the proxy is taken from the spec's statement that it is "audited, battle-tested" [S1 Implementer Notes] and was not verified independently.

---

10. Sources

X = https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3 P = https://github.com/Uniswap/permit2/blob/cc56ad0f3439c502c246fc5cfcc3db92bb8b7219

• S1 x402 exact scheme on EVM (Permit2 phases, proxy reference, canonical addresses) — X/specs/schemes/exact/scheme_exact_evm.md — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/specs/schemes/exact/scheme_exact_evm.md

• S2 x402 Protocol Specification v2 (§5 types, §6.1 flows, §7 facilitator API, §9 errors, §10 security, scope) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/specs/x402-specification-v2.md

• S3 x402 v2 HTTP transport (PAYMENT-REQUIRED/PAYMENT-SIGNATURE/PAYMENT-RESPONSE, status mapping) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/specs/transports-v2/http.md

• S4 x402ExactPermit2Proxy.sol — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/contracts/evm/src/x402ExactPermit2Proxy.sol

• S5 x402BasePermit2Proxy.sol (_settle, _executePermit) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/contracts/evm/src/x402BasePermit2Proxy.sol

• S6 Reference TS shared Permit2 logic (client payload construction L590–629, signing domain L648, allowance check, error mapping, diagnostics); constants — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/typescript/packages/mechanisms/evm/src/shared/permit2.ts ; S6-const: https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/typescript/packages/mechanisms/evm/src/constants.ts

• S7 Reference TS client Permit2 helpers (createPermit2ApprovalTx uses MAX_UINT256) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/typescript/packages/mechanisms/evm/src/exact/client/permit2.ts

• S8 Reference TS facilitator Permit2 verify/settle — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/typescript/packages/mechanisms/evm/src/exact/facilitator/permit2.ts

• S9 Reference facilitator error codes — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/typescript/packages/mechanisms/evm/src/exact/facilitator/errors.ts

• S10 Nonce generation createPermit2Nonce (L61) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/typescript/packages/mechanisms/evm/src/utils.ts#L61

• S11 Server default maxTimeoutSeconds 300 (L813) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/typescript/packages/core/src/server/x402ResourceServer.ts#L813

• S12 payment-identifier extension (idempotency, request binding, 409) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/specs/extensions/payment_identifier.md

• S13 offer-receipt extension (server-signed EIP-712 Offer/Receipt, validUntil, signer authorization) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/specs/extensions/extension-offer-and-receipt.md

• S14 upto scheme on EVM (witness includes facilitator; separate proxy) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/specs/schemes/upto/scheme_upto_evm.md

• S15 auth-capture scheme on EVM (payment-info hashes, salt binding; a different scheme) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/specs/schemes/auth-capture/scheme_auth_capture_evm.md

• S16 Permit2 SignatureTransfer.sol (deadline L60, amount L61, nonce L63/L142–156, invalidate L130) — https://github.com/Uniswap/permit2/blob/cc56ad0f3439c502c246fc5cfcc3db92bb8b7219/src/SignatureTransfer.sol

• S17 Permit2 PermitHash.sol (witness typehash stub L31–32, msg.sender as spender L93) — https://github.com/Uniswap/permit2/blob/cc56ad0f3439c502c246fc5cfcc3db92bb8b7219/src/libraries/PermitHash.sol

• S18 Permit2 EIP712.sol (domain with chainid and contract address) — https://github.com/Uniswap/permit2/blob/cc56ad0f3439c502c246fc5cfcc3db92bb8b7219/src/EIP712.sol

• S19 On-chain observation, Ethereum mainnet via https://ethereum-rpc.publicnode.com, block 26,056,849 (2026-09-25 20:27:35 UTC):

  • eth_getCode for 0x000000000022D473030F116dDEE9F6B43aC78BA3 → non-empty (9,152 bytes);
  • eth_getCode for 0x402085c248EeA27D92E8b30b2C58ed07f9E20001 → non-empty (2,913 bytes);
  • eth_call PERMIT2() (selector 0x6afdd850) on the proxy → 0x…22d473030f116ddee9f6b43ac78ba3.

  These results can be reproduced with any mainnet RPC.

• S20 SDK default assets (mainnet USDC, L59) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/typescript/packages/mechanisms/evm/src/defaultAssets.ts#L59

• S21 EIP-712 Typed structured data hashing and signing — https://eips.ethereum.org/EIPS/eip-712

• S22 Uniswap canonical deployments (Permit2 address reference cited by S1) — https://docs.uniswap.org/contracts/v4/deployments

• S23 e2e test facilitator createPaymentHash (sha256 of payload, 5-min verify→settle window; test code, not protocol) — https://github.com/x402-foundation/x402/blob/4fcf836cc393174130e1358577ce5d37356da1c3/e2e/facilitators/typescript/index.ts#L528