Repository navigation
Add Solana support to x402 in agents/mcp #596
Description
The current implementation of x402 in packages/agents/src/mcp/x402.ts only supports base and base-sepolia. Solana support needs to be added to this file and any downstream locations to extend support beyond Base, starting with Solana to keep it up to sync with the rest of the x402 ecosystem like Vercel's x402-mcp
Activity
threepointone commentedon Feb 11, 2026
/bonk we updated to the latest versions/packages of x402. What would it take to "support solana"?
adlonymous commentedon Feb 11, 2026
Summary
Add Solana (SVM) chain support to the x402 payment protocol integration in packages/agents/src/mcp/x402.ts, alongside the existing EVM support.
Background
The x402 protocol's modular v2 architecture supports multiple chains via scheme packages:
See: @x402/svm package (https://www.npmjs.com/package/@x402/svm)
Requirements
threepointone commentedon Feb 12, 2026
/bonk do research and tell me what you think
threepointone commentedon Feb 12, 2026
(bonk is our bot, let's see what it says)
ask-bonk commentedon Feb 12, 2026
That's the full analysis. The tl;dr:
@x402/svm@2.3.0exists on npm from Coinbase with the exact same architecture as@x402/evm. The integration is straightforward - widen the types, add dynamic imports gated by signer type, add 3 Solana entries to the legacy network map, and mock@x402/svmin tests the same way@x402/evmis mocked today. About a day of work.github run
adlonymous commentedon Feb 12, 2026
Should be trivial to add the actual support to the SDK, but I think there might be a few minor hitches if you choose to update the examples as well.
Either way would love to co-ord with Solana Foundation to get a PR in for this
threepointone commentedon Feb 12, 2026
What would we need from solana foundation? Feels like we could take a swing ourselves here. (We have some other internal plans and I want to make sure it's designed in preparation for that)
adlonymous commentedon Feb 12, 2026
Solana's public devnet RPC blocks requests from Workers IP and returns a 403 and is pretty strict on rate-limits. The way x402's SVM library is set up is that unlike it's EVM counterpart, it needs a network RPC URL because it needs to fetch the network's latest blockhash and the examples would need an RPC URL that is not blocked. Of course there are ways around that but for the sake of examples, one shouldn't need to use specialized RPCs
I mocked what a PR to this would look like and ran into this issue at the end, but if there are internal plans and design decisions to consider, makes sense for CF to take a swing at this
0xbrainkid commentedon May 31, 2026
One Solana-specific edge to design for is that SVM support probably needs a cleaner split between payment construction and network access than the EVM path.
For Workers/MCP examples, I would test three cases explicitly:
That last point matters for agent tools because a 402 retry loop can otherwise duplicate work. For SATP-style policy checks, the authorization/trust decision should happen before the x402/SVM payload is created, then the payment retry should only refresh payment material, not re-authorize a different tool action.
This keeps Solana support compatible with Cloudflare’s agent runtime constraints while avoiding hidden chain/RPC assumptions in the MCP tool layer.
mohamedkuch commentedon Jul 28, 2026
We operate a live SVM x402 v2 MCP and HTTP service and can provide a public compatibility target for this issue. Production traffic regularly reaches a valid 402 but almost never completes the paid retry, which is consistent with Solana-capable buyer support being absent from general agent runtimes.
A useful acceptance test would be:
withX402Clientwith@x402/svmExactSvmSchemeand a funded, bounded signer.PAYMENT-SIGNATUREretry, a 200 result, and thePAYMENT-RESPONSEtransaction.Utilia already has a live $0.002 endpoint and a merged external SDK integration that completed this exact flow. We can provide the endpoint, expected challenge fields, and a bounded compatibility fixture. Would maintainers accept a focused PR limited to the SVM client path and one end-to-end MCP example?
notorious-d-e-v commentedon Jul 31, 2026
We'd like to take this on. Over in cloudflare/templates we've just migrated
x402-proxy-templateto x402 v2 with multi-network support (@x402/hono+@x402/evm+@x402/svm) and verified it end-to-end with real settled payments on Base Sepolia, Solana devnet, Base mainnet, and Solana mainnet: cloudflare/templates#1087.Happy to bring the same to
agents/x402along the lines sketched above: registerExactSvmSchemealongside the EVM scheme, widen the EVM-typed signer/payTo types, extend the legacy network map with the Solana CAIP-2 ids, mock@x402/svmin the test suite, and make the RPC endpoint configurable (the public devnet RPC 403-blocks Workers IPs, so an env-provided RPC URL matters in practice).@threepointone — you mentioned possibly taking a swing internally back in February; is that still planned? If not, we'll open a PR this week. This would also make the payments docs' Solana claim true (#1863).
mohamedkuch commentedon Jul 31, 2026
Thanks, this aligns directly with the compatibility target offered above. Utilia can provide the bounded Solana mainnet verification once the maintainers confirm the PR path.
Exact target:
The acceptance record should preserve the initial payment-required response, local wallet-policy approval, one signed retry, exactly one tool execution, the returned result, X-Utilia-Receipt-Id, and the Solana settlement transaction. An expired-blockhash refresh must not repeat the tool side effect.
Any coordinated payment will be classified as a bounded compatibility test, not organic demand. No payment is needed until the implementation is ready for end-to-end verification.
feat(x402): register @x402/svm alongside @x402/evm in Agents MCP inte…
feat(x402): accept payment schemes so paid MCP tools work on Solana
feat(examples): add Solana devnet payments to the x402 examples
notorious-d-e-v commentedon Oct 9, 2026
I've built this. Since the repo isn't taking outside PRs, I've put the details in #2543, with a ready branch a maintainer can cherry-pick: main...notorious-d-e-v:agents:feat/x402-solana
withX402andwithX402Clientaccept paymentschemes(the same{ network, server | client }shape the upstream x402 libraries use). An app registersExactSvmSchemefrom@x402/svmitself, so EVM-only users install nothing new.examples/x402andexamples/x402-mcprun on Solana devnet with a configurableSOLANA_RPC_URL, which handles the public-RPC 403 from Workers that @adlonymous mentioned above.It also takes #2273 into account. I'm happy to rebase onto it or move the example over if that's the direction.
Could this issue be reopened, or tracked against #2543? Thanks!
@mohamedkuch, once a maintainer confirms the approach, the
schemesoption should work against your Solana mainnet target as-is.