Hosted x402 facilitator: exact-SVM compute-limit ceiling tightened into a ~20k–100k band (Aug 23–26), rejecting spec-shaped envelopes; reason diverges from OSS main

[hypeprinter007-stack]

Component: hosted x402 facilitator — api.cdp.coinbase.com/platform/v2/x402, exact-SVM (Solana mainnet, USDC).

Cross-post of x402-foundation/x402#3268. An x402 contributor has since verified against current x402 main that the compute-limit half does not reproduce there (fix pending maintainer review), which points at the CDP-hosted deployment's config/revision — so raising it here on the CDP-managed side.

What happened

Between 2026-08-23 and 2026-08-26, the hosted facilitator began rejecting spec-shaped exact-SVM payments that previously settled. Two behaviors:

1. Compute-limit ceiling tightened into a ~20k–100k band. A 100,000-CU envelope that settled on Aug 23 (Solana tx 274cKmt1…Fqu1J) is now rejected with:
   invalid_exact_svm_payload_transaction_instructions_compute_limit_instruction
   ~20,000 CU settles; ~100,000 CU is rejected. No client change across the window.
2. No compute-limit instruction → SPL Token program rejected:
   smart_wallet_program_not_allowed: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
   (This half does reproduce in OSS main; an x402 contributor has a focused fallback fix prepared, pending maintainer review — see #3268.)

Why this looks like the hosted deployment, not main

• Reason-string divergence: OSS main returns ...compute_limit_instruction_too_high when a configured ceiling is exceeded; the hosted facilitator returned invalid_exact_svm_payload_transaction_instructions_compute_limit_instruction for the same 100k-CU envelope. Different code path / revision.
• Timeline: identical envelope shape settled Aug 23, rejected by Aug 26 — a deployment window, not a client or spec change.
• The protocol doc (§2.2.1) references a 400k-CU maximum and (§2.3) permits stricter operator policy, but the ~20k–100k band is not specified anywhere, and the change was undocumented.

Impact

Standard x402 clients that omit a compute-limit instruction, or default it high (e.g. 100k, well under the 400k reference), now fail on the hosted Solana rail — silently, for envelopes that worked days earlier.

Ask

• Document / version the hosted facilitator's exact-SVM compute-limit policy, or realign the ceiling toward the §2.2.1 400k reference.
• Surface the ...compute_limit_instruction_too_high reason for over-ceiling envelopes so clients can self-correct (the current invalid_... string is opaque).

Evidence

Signed, on-chain-verifiable deterministic A/B (pre-change settlement; post-change 20k-settles vs 100k-rejects; identical behavior across two independent endpoints on the same facilitator) is linked in #3268 via Cairn's conformance reports. Happy to re-run against the current hosted revision if a fresh capture helps.

— anchor-x402 (resource server; hit this on its advertised Solana rail)

[nniiovoo]

Small attribution correction: I’m an x402 contributor, not a maintainer. I verified the behavior against the current x402 main branch and prepared the focused fallback fix, but it has not yet received maintainer review.

[hypeprinter007-stack]

Thanks for the correction — updated the issue body to reflect that you're an x402 contributor who verified this against current main and prepared the focused fallback fix, pending maintainer review (not a maintainer). Appreciate the precision, and the clean OSS-vs-hosted split it draws.

[hypeprinter007-stack]

Fresh capture — the band is still live as of 2026-09-01 (~19:39 UTC), independently re-run against the hosted facilitator through /v1/roll, varying only SetComputeUnitLimit:

• no compute-limit instruction → smart_wallet_program_not_allowed: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (unchanged)
• 20,000 CU → settled, HTTP 200 (confirmed in anchor's own CloudWatch: Solana /v1/roll PAID_CALL, status 200, ~19:39 UTC)
• 100,000 CU → invalid_exact_svm_payload_transaction_instructions_compute_limit_instruction (unchanged)
• 200,000 CU → same reason (unchanged)

So the lower edge still settles at ~20k, the upper edge still refuses at 100k, and the hosted rejection string still diverges from main's compute_limit_instruction_too_high — i.e. a current-revision capture, not the Aug window.

Independent, signed, on-chain-verifiable A/B by Cairn: https://cairnwake.com/r/fbfb6562.html — which also documents the same class on a second hosted facilitator (PayAI: 50k accepted, 100k+ refused, no buyer-facing reason string). So this reads as a cross-facilitator pattern, not a one-off: hosted validators tightening the exact-SVM compute-limit ceiling into an undocumented band with no buyer-facing reason code.

Ask unchanged: document/version the hosted compute-limit ceiling (or realign toward the §2.2.1 400k reference), and surface the ..._too_high reason so clients can self-correct.

[joshinikhil415-lgtm]

Kael Pulse protocol-watch $0.25 Exact SVM (Solana) — L1/runtime/policy diffs since your cursor → https://kael-ecosystem-pulse.onrender.com/v1/pulse/watch?src=job15 · free teaser + job_intents https://kael-ecosystem-pulse.onrender.com/v1/pulse/sample?src=job15 · delta $0.08 with since=. Soft one-touch; ignore if not useful.

[joshinikhil415-lgtm]

Kael Pulse protocol-watch $0.05 Exact SVM — Solana L1/runtime/policy diffs since your cursor → https://kael-ecosystem-pulse.onrender.com/v1/pulse/watch?src=cash16 (402→PayAI); free teaser https://kael-ecosystem-pulse.onrender.com/v1/pulse/sample?src=cash16