What does x402 412 permit2_allowance_required mean?

It means the facilitator could not verify a usable Permit2 allowance path for the payment. In a sponsored EIP-2612 flow, first check whether the client actually attached the sponsored permit; an open September 2026 x402 report shows that a signer without readContract capability or an explicit RPC URL can silently skip permit enrichment and then receive this 412 response.

Why can eip2612GasSponsoring be advertised but the x402 client still return permit2_allowance_required?

Advertising the extension says the payment path supports sponsored EIP-2612 approval. The client still needs enough chain-reading capability to inspect allowance and nonce state and build the permit. In the reported TypeScript path, supplying an RPC URL or a signer backed by a public client allowed the permit to be created and the payment to settle.

Should I send a manual Permit2 approval when I see 412 permit2_allowance_required?

Not automatically. First determine whether the server offered a sponsorship extension and whether your client omitted it because it could not read the chain. A manual approval may be a valid fallback when deliberately chosen, but it changes the gas and permission model and should not be used to hide a client-capability problem.

How do I fix ExactEvmScheme for sponsored Permit2 payments?

For the open TypeScript reproduction against x402 2.23.0, either construct ExactEvmScheme with an explicit rpcUrl option or adapt the account into a client signer backed by a public client. Then confirm the retried payment contains the expected EIP-2612 permit before treating a 200 response as proof the problem is resolved.

Editorial

Research guide · x402 · Permit2 · EIP-2612 · 14 September 2026

x402 412 permit2_allowance_required: fix EIP-2612 sponsorship

A 412 permit2_allowance_required response does not always mean the wallet must send a manual approval transaction. In a current x402 TypeScript reproduction, the resource advertised eip2612GasSponsoring, but a signer-only ExactEvmScheme could not read the chain, silently omitted the sponsored permit, and reached the facilitator without the approval path it needed.

Published 14 September 2026 · sources checked 14 September 2026

412

Observed facilitator response

Permit2

Asset-transfer path

EIP-2612

Gas-sponsored approval option

RPC/readContract

Client capability to verify first

The useful distinction

Extension support is not the same as client capability

x402's EVM Permit2 flow can use an EIP-2612 permit so a facilitator can settle without making the payer first spend native gas on a separate ERC-20 approval. The facilitator still needs the payment payload to contain the permit material required by that path.

The open x402 issue was reproduced against 2.23.0 with the same seller, facilitator and fresh wallet. new ExactEvmScheme(account) returned 412 permit2_allowance_required. Adding an explicit rpcUrl, or adapting the account to a signer backed by a public client, produced settled 200 responses in the reporter's tests.

The reported implementation path resolves extension RPC capabilities before building the sponsored permit. If no readContract capability is available, permit enrichment can be skipped. That makes the 412 look like a wallet-approval problem even though the first defect to investigate is the buyer's ability to read allowance and nonce state.

Error map

Read the 412 as a missing precondition, not a diagnosis

Observed symptom	What to inspect next
`412 permit2_allowance_required`	The facilitator did not find a usable Permit2 approval or sponsored-permit path. Inspect the payment payload and client capabilities before approving Permit2 manually.
`eip2612GasSponsoring is advertised, but no permit is attached`	Check whether the EVM payment scheme can read allowance and nonce state through readContract or an explicit RPC URL.
`new ExactEvmScheme(account) fails, RPC-backed registration succeeds`	This matches the open September 2026 TypeScript reproduction. Treat it as version-specific implementation evidence rather than a protocol-wide requirement.

Diagnosis

Seven checks before you send an approval transaction

1. Preserve the original 402. Record the selected scheme, network, asset, transfer method and advertised extensions. Do not debug from the final 412 alone.
2. Confirm the asset actually uses Permit2. The sponsored approval path matters when the selected requirement expects Permit2 rather than an EIP-3009 transfer path.
3. Check for eip2612GasSponsoring. If the extension was not offered, this specific diagnosis does not apply. Use the approval path the requirement actually advertises.
4. Inspect the signed payment payload. Determine whether the EIP-2612 permit was attached. If it is missing, stop before assuming the wallet itself lacks a valid route.
5. Verify chain-read capability. In the reported TypeScript path, provide an explicit RPC URL or a signer/public-client adapter capable of readContract. That lets the client inspect allowance and nonce state before signing the permit.
6. Retry one controlled payment. Keep seller, facilitator, wallet, asset and amount fixed. A/B only the RPC-capable scheme construction and compare the generated payload plus facilitator response.
7. Treat manual approval as a deliberate fallback. If you intentionally choose a direct Permit2 approval, bound the permission and document the gas/allowance change. Do not make a permanent approval workaround for a temporary SDK capability gap.

TypeScript repair pattern

Give the EVM scheme a chain-read path

The public reproduction reports two working shapes: construct ExactEvmScheme with an explicit RPC option, or adapt the account into an x402 client signer backed by a public client. The exact imports can change with SDK releases, so pin the package version and verify the resulting payload rather than copying a versionless snippet blindly.

// Reproduction pattern reported against @x402/* 2.23.0

new ExactEvmScheme(account, { rpcUrl: YOUR_RPC_URL })

// or use a client signer backed by a public client

new ExactEvmScheme(toClientEvmSigner(account, publicClient))

Do not place a private key in a URL, source repository, browser bundle or logging path. The repair is about read capability; it is not permission to expose signing material.

What not to infer

Three conclusions are too strong

“The wallet has no funds”

Not necessarily. The reported failure was an approval/permit precondition while wallet, seller and facilitator stayed constant.

“EIP-2612 sponsorship is broken everywhere”

No. This is an open implementation report against a specific SDK version and construction path.

“A permanent unlimited approval is the fix”

No. First restore the intended sponsored path; only use a direct approval when your policy deliberately chooses it.

Sources

Primary evidence

x402 issue #3458 — open 12 September 2026 reproduction of the signer-only 412 and the two RPC-capable success paths.
x402 EVM Permit2 specification — describes Permit2 allowance checks, EIP-2612 gas sponsorship and the PERMIT2_ALLOWANCE_REQUIRED precondition when no approval path is available.

Continue the implementation path