One wallet, any chain, every x402 service. Pay Solana Foundation's Gemini API from a Base wallet in ~8 seconds — roughly 10× faster and 50× cheaper than bridging USDC, no embedded-wallet sprawl, settled on Solana.
🎥 Demo video — Base → pay.sh → Gemini in 8 seconds (2 min) · 🌐 Live site · 🔧 MCP manifest · 🚀 Solana Frontier submission
The agent economy has a capital efficiency problem. Every chain that hosts a useful service — Solana for Gemini and BigQuery via pay.sh, Base for Bazaar, Stellar for Anchor data, Algorand for GoPlausible — demands its own pre-funded wallet, its own gas token, its own bridge in. An agent that wants to call ten services across five chains has to maintain ten USDC balances, monitor five gas tokens, and accept the slippage of bridging in and out for $0.01 micropayments. The math does not work.
Pay.sh, launched 2026-05-06 by Solana Foundation in collaboration with Google Cloud, is the most acute example. It exposes 72 providers — including 13 Google Cloud APIs (Gemini, Vertex AI, BigQuery, Vision, Speech, Places) and 16 Alibaba Cloud APIs — through the x402 and MPP (Machine Payments Protocol) standards. The marquee 29 Solana-Foundation-operated providers are MPP-only and accept payment exclusively in Solana SPL tokens. An AI agent on Base, Arbitrum, Stellar, or any other chain cannot call Gemini through pay.sh today without first bridging USDC to Solana — a cost and latency overhead that destroys the unit economics of $0.001-per-call services.
PaySphere is a non-custodial payment relay that lets one wallet on any of ten supported chains pay any x402 or MPP service in pay.sh's catalog (plus the 297 services already in Sippar's existing x402 registry — 369 total). The user pays USDC on their home chain to a threshold-controlled treasury; PaySphere settles the destination payment in the appropriate Solana SPL token, signs it via ICP threshold cryptography, and proxies the service response back. End-to-end demo: a Base wallet calls Google Gemini via pay.sh in ~8 seconds, with Basescan and Solscan tabs showing both legs of the transaction.
The relay does not custody funds (threshold signatures distribute control across ICP subnet nodes — no single party holds keys), does not require per-agent embedded wallets (one wallet pays anywhere), and does not rely on traditional bridges (no wrapped assets, no bridge security assumptions). It is the first non-custodial cross-chain MPP relay — Privy and other custodial agent-wallet providers support MPP via embedded wallets that hold keys on the user's behalf and require one wallet per chain; PaySphere uses ICP threshold cryptography (no single party holds keys) and a single home-chain wallet that pays any chain via relay.
Per Colosseum Copilot search of 5,400+ past hackathon projects, no prior submission combines threshold-cryptography custody with cross-chain MPP settlement (closest similarity 0.06).
# 1. Discover available services (returns 369 entries: pay.sh + 297 Sippar x402)
curl https://sippar.network/api/sippar/paysphere/services?protocol=mpp
# 2. Get a quote
curl -X POST https://sippar.network/api/sippar/paysphere/quote \
-H "content-type: application/json" \
-d '{"service":"google/gemini-pro","homeChain":"base"}'
# → { "amountUsdc": 0.001, "treasury": "0x07fBca...", "settleChain": "solana", "feeBps": 300 }
# 3. Pay Sippar's Base treasury (your wallet / Foundry / wagmi / Privy — your choice)
# Then call relay with the inbound txHash:
curl -X POST https://sippar.network/api/sippar/paysphere/relay \
-H "content-type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"txHash": "0x...your inbound USDC tx on Base...",
"service": "google/gemini-pro",
"payload": { "prompt": "Explain MPP in one sentence" }
}'
# → { "response": "...Gemini answer...",
# "receipts": { "source": "0x...base...", "destination": "...solana sig..." },
# "latencyMs": 8210 }Two integration paths exist — funded wallet (the curl above) and greenfield with ICP-derived address (one MCP call to bootstrap).
┌────────────────────┐ ┌───────────────────────────────────┐ ┌─────────────────────┐
│ Agent Wallet │ │ PaySphere Relay (Sippar) │ │ Pay.sh Service │
│ (Base / Arb / │ │ │ │ (Gemini / BigQuery │
│ Stellar / TON / │ │ ┌─────────────────────────────┐ │ │ / 70 others) │
│ any of 10) │ │ │ crossChainRelayService │ │ │ │
│ │ │ │ + payshRelayService (new) │ │ │ Protocol: x402 v2 │
└──────────┬─────────┘ │ └────────┬────────────────────┘ │ │ or MPP (Solana) │
│ │ │ │ └──────────┬──────────┘
│ 1. USDC pay │ │ │ │
│ on home │ │ │ │
│ chain (x402)│ │ │ │
├─────────────►│ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ ICP Threshold Signers │ │ │
│ │ │ • threshold_signer │ │ │
│ │ │ (Ed25519 t-Schnorr) │ │ │
│ │ │ Solana / Stellar / ALGO │ │ │
│ │ │ • ethereum_signer │ │ │
│ │ │ (secp256k1 t-ECDSA) │ │ │
│ │ │ 6 EVM chains │ │ │
│ │ └────────────┬────────────────┘ │ │
│ │ │ │ │
│ │ │ 2. Threshold- │ │
│ │ │ signed SPL │ │
│ │ │ transfer + │ │
│ │ │ MPP creds │ │
│ │ ├──────────────────►│ │
│ │ │ │ 3. Call svc │
│ │ │ ├──────────────►│
│ │ │ │ │
│ │ │ │ 4. Response │
│ │ 5. Buffered │ │◄──────────────┤
│ 6. Response │ response │ │ │
│ + both │◄──────────────┤ │ │
│ receipts │ │ │
│◄─────────────┤ │ │
└───────────────────────────────────┘
End-to-end latency: ~8 seconds for Base → pay.sh → Gemini (Solana settlement ~400ms; the rest is inbound verification, threshold-sig orchestration, and pay.sh's response). Compare to alternatives:
| Approach | Latency | Cost per $0.01 call | Capital required |
|---|---|---|---|
| Bridge USDC Base→Solana (LayerZero/Wormhole) | 60–300s | $0.30–$1.00 | Same |
| Hold pre-funded balance on every chain | 0s | $0.0007 | N × balance × N chains |
| PaySphere | ~8s | $0.0103 (pay.sh price + 3% relay) | 1 × balance |
Full architecture write-up: ARCHITECTURE.md
Agent already controls a wallet with USDC on Base, Arbitrum, Optimism, Polygon, BNB, Ethereum, Solana, or Stellar (Coinbase CDP, Privy, wagmi, ethers.js, Solana Web3.js — any of them). Pays Sippar's treasury on its home chain, calls PaySphere with the transaction hash. PaySphere verifies the inbound payment, settles on the destination chain from Sippar's destination-chain treasury, returns the pay.sh response in ~8 seconds. No ICP involvement, no derived addresses, no threshold sig on the agent's side.
This is the right path for ~95% of agents shipping today — the agent's existing wallet is the identity, the relay is invisible.
Agent has no wallet. Operator wants a non-custodial setup with no seed phrases, no key management, no exchange accounts. The agent generates an Ed25519 keypair locally (one line of code — the principal is a self-authenticating hash of the public key). Sippar derives a Base address from the principal via threshold cryptography. The operator funds that derived address once with USDC + a tiny amount of ETH for gas. From then on, every payment is threshold-signed by 34 nodes on ICP's fiduciary subnet — the private key is split into shares that never get assembled, anywhere, by anyone.
Honest framing: private key material is fully non-custodial (34 ICP node operators hold shards). The signing authorization layer is currently gated by Sippar's backend (we pass the agent's principal to the canister; the canister trusts our gating). Canister-enforced agent-signed signing requests are the next step on the roadmap.
This is what makes "first non-custodial cross-chain MPP relay" defensible. See docs/INTEGRATION_PATHS.md.
PaySphere is live as an MCP server at https://sippar.network/mcp/tools/paysphere. Five tools cover the full workflow:
| Tool | Purpose |
|---|---|
paysphere_discover |
List pay.sh services with filters (protocol, max price, search) |
paysphere_quote |
Per-call price + Sippar treasury address + exact USDC amount |
paysphere_pay_direct |
Path A: agent pays Sippar treasury, then calls with txHash |
paysphere_pay_with_identity |
Path B: agent's ICP principal authenticates a threshold-signed payment |
paysphere_address_for_principal |
Derive the Base address controlled by an ICP principal |
For Claude Code agents, drop the skill/ directory into any project — /paysphere gives the agent the entire integration in one command, including the Ed25519 identity bootstrap, address derivation, and smart-routing pay wrapper.
Full MCP reference: docs/MCP.md · REST reference: docs/API.md
PaySphere/
├── README.md ← you are here
├── ARCHITECTURE.md ← 4-step flow + threshold-sig + DePIN stack
├── docs/
│ ├── API.md ← REST endpoint reference
│ ├── MCP.md ← MCP tools reference (5 tools)
│ ├── INTEGRATION_PATHS.md ← Path A funded / Path B greenfield
│ ├── SECURITY.md ← Threshold cryptography + 5 safety fixes
│ └── ROADMAP.md ← Post-hackathon priorities
├── apps/
│ ├── web/ ← Marketplace frontend (sippar.network/paysphere)
│ │ ├── components/ ← 10 React components (Hero, ChainPicker, ServiceCatalog, …)
│ │ ├── lib/payshClient.ts ← Typed client + relay execution
│ │ └── public/
│ │ ├── skills/paysphere.md ← Self-install skill markdown
│ │ └── .well-known/ai-plugin.json
│ ├── mcp/ ← MCP tool server (apps/mcp lives at sippar.network/mcp)
│ │ ├── types/paysphereTools.ts ← Tool type definitions
│ │ ├── routes/
│ │ │ ├── paysphereToolsRoutes.ts ← Tool manifest endpoints
│ │ │ └── paysphereProtocolRoutes.ts ← MCP protocol layer
│ │ └── services/paysphereToolsService.ts ← Tool business logic
│ └── api/ ← Cross-chain relay backend
│ ├── routes/paysh.ts ← /health /services /quote /relay
│ └── services/payshRelayService.ts ← Relay orchestration
├── skill/ ← Drop-in Claude Code skill
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── examples/
│ └── notion-agent/ ← Reference Notion MCP agent (PROMPT-v3)
└── media/
├── paysphere-demo-2x.mp4 ← 2-minute mainnet demo
└── architecture.png ← Architecture diagram (SVG/PNG)
The trust-critical Rust canister code (threshold_signer, ethereum_signer, custody derivation, treasury management) lives in the private Sippar repo per Hackathon Rules §9. PaySphere's relay code in this repo calls those canisters via documented HTTP boundaries at https://sippar.network/api/sippar/*.
PaySphere stands on a two-layer DePIN stack:
- ICP — threshold signatures, canister compute, 1:1-backed bridge tokens. Running on dedicated node hardware in independent data centers, not AWS.
- Lava Network — multi-chain RPC reads across 21 chains as a stake-backed provider marketplace. Multi-provider consensus is wired through the DFINITY EVM RPC canister + Lava on EVM chains (Ethereum, Base, Arbitrum, Optimism, Polygon, BNB) — every chain read goes through at least two independent providers that must agree before money moves. For Solana, Stellar, Algorand, and TON, Lava is currently a single stake-backed provider; a second-provider integration (Helius on Solana being the immediate target) is queued.
Neither layer can be subpoenaed, censored, or taken offline by a cloud provider.
One consequence of running on ICP canisters that's easy to miss: the trust-critical layer auto-scales on cycles. Sippar's signing, payment verification, ICRC-3 audit trail, and cross-chain relay logic all live in canisters. As load grows from 0.5 tx/sec to 5 tx/sec (10× the entire current organic x402 market), there are no instances to provision, no autoscaling groups to configure, no DevOps to do. The only scaling operation is topping up cycles. Within the ICP subnet ceilings (6.5 Ed25519 sig/sec sustained, 11× current market headroom), it's the closest thing to a serverless primitive for non-custodial payment infrastructure that exists.
| Layer | Tech |
|---|---|
| Frontend | React 18 + TypeScript + Tailwind, deployed at sippar.network/paysphere |
| API | Node 22 + Express, deployed on VPS, called via HTTP from frontend |
| MCP server | TypeScript MCP SDK, served at sippar.network/mcp/tools/paysphere |
| Threshold signatures | ICP threshold_signer canister (vj7ly-diaaa-aaaae-abvoq-cai) for Ed25519 (Solana / Stellar / Algorand / TON), ethereum_signer (4yiex-siaaa-aaaak-qxbwq-cai) for secp256k1 (6 EVM chains) |
| Multi-chain RPC | Lava Network + DFINITY EVM RPC canister (multi-provider consensus on EVM) |
| Inbound verification | Lava (EVM), Helius (Solana queued), Horizon (Stellar), AlgoNode (Algorand), TonAPI (TON) |
| x402 facilitators | GoPlausible (Algorand), PayAI (Solana), OpenZeppelin (Stellar), Sippar (TON) |
| MPP | Solana Foundation pay.sh SDK + custom SipparTransactionSigner adapter |
Build Paths hit:
- #1 — Agents + Tokenization. PaySphere is agent-payment infrastructure — any agent (ElizaOS, Solana Agent Kit, Claude Code MCP, etc.) calls any tokenized service on any of 10 chains through one integration. The agent SDK ships as an npm package; the MCP server publishes 5 tools.
- #7 — Mobile. Phantom mobile (Solana) and WalletConnect (EVM) are first-class citizens. A user on a phone authorizes a Base payment from Phantom Mobile and gets a Solana service response — the entire flow is mobile-native.
- #8 — Payments + Commerce. Machine-to-machine commerce across chain boundaries. Every API call is a real on-chain settlement, on mainnet, in less than ten seconds.
Net-new code during judging window (April 6 – May 11, 2026): ~30 hours of focused engineering — 1 new backend service, 2 new endpoint routes, 1 new frontend route, 8 React components, 5 MCP tools, 1 Claude Code skill, 1 ops script. Full breakdown in ARCHITECTURE.md § What we built this week.
Prior IP (per Hackathon Rules §9): Sippar's deployed cross-chain payment infrastructure — crossChainRelayService, x402ClientService, threshold_signer canister, ethereum_signer canister, lava_rpc canister, 297-service x402 registry, treasury addresses on 10 chains, VPS infrastructure. Full attribution in ARCHITECTURE.md § Powered by Sippar.
The closest direct competitor is Privy Agent Wallets (docs.privy.io/recipes/agent-integrations/mpp). Different model:
| Dimension | Privy Agent Wallets | PaySphere |
|---|---|---|
| Wallets per agent | 1 per chain (N total) | 1 wallet, N chains accessible |
| Custody | Privy-hosted embedded wallets | Threshold cryptography (ICP subnet, no single key holder) |
| MPP support | Yes — via agent's Solana Privy wallet (custodial, same-chain) | Yes — any home-chain wallet to any chain's MPP service (non-custodial, cross-chain) |
| Pre-funding | Each chain wallet holds balance | Single home-chain wallet only |
| Capital efficiency for cross-chain agents | Low (N × balance) | High (1 × balance) |
Privy's model wins when an agent operates predominantly on one chain. PaySphere wins when an agent needs cross-chain reach without N times the working capital — which describes most real-world agent-to-agent commerce flows.
See docs/ROADMAP.md. Highlights:
- Canister-enforced agent-signed signing requests — closes the policy-custody gap on Path B
- Pre-signed authorization pool — 100ms cached payments, 10× cycle-cost amortization
- External security audit (~$50k, 4-6 weeks)
- Streaming response support for LLM endpoints (Gemini, Vertex AI)
- Solana Foundation partnership — co-marketing + integration depth, not capital
- Additional chains (Aptos, Sui, anywhere Sippar adds threshold support)
- Agent SDK ecosystem distribution — ElizaOS plugin marketplace, Solana Agent Kit, Claude Code registry
- Coinbase Bazaar / PayAI / 402 Index adapters (months 3-6)
Elad Mintzer — solo founder, building Sippar and PaySphere from Berlin. Background in Web3 ecosystem strategy and developer engagement. Development workflow is AI-augmented (Claude Code as primary collaborator).
Currently consulting for ICP Hub Germany (developer engagement, partnership integrations). Prior consulting: Celo Foundation, Q Protocol, DAOstack. Earlier: Program Manager at Celo Camp. Reichman University (IDC), BA Business Administration.
Founder of:
- Sippar — universal payment bridge for AI agents (parent infrastructure)
- Nuru AI — agentic AI infrastructure vision
Contact:
- LinkedIn: linkedin.com/in/eladmi
- Twitter: @elad_mi
- Email: elad@sippar.network
- Timezone: Europe/Berlin (GMT+1)
- Live site: https://sippar.network/paysphere
- MCP manifest: https://sippar.network/mcp/tools/paysphere/manifest
- AI plugin manifest: https://sippar.network/.well-known/ai-plugin.json
- Self-install skill: https://sippar.network/skills/paysphere.md
- Sippar (parent project): https://sippar.network
- Pay.sh: https://pay.sh
- Solana Foundation MPP SDK: https://github.com/solana-foundation/mpp-sdk
Apache 2.0 — see LICENSE. Trust-critical Rust canister code remains private per Hackathon Rules §9 and Sippar Labs' commercial licensing terms.