One x402 endpoint, two ways to pay: USDG on Robinhood Chain (EVM) or USDC on Solana (SVM). Here's how the x402 accepts[] array lets a single resource take payment on two chains — and why the agent picks.
Building a product on Solana data?
Skip the Geyser pipeline — embed KOL flow, deployer reputation, and the all-DEX firehose over REST, WebSocket, or webhooks. The Business tier (€400/mo) is the self-serve embed license at 500k calls/day — Enterprise adds white-label & redistribution.
On both legs the money moves directly from the agent's wallet to ours — on the USDG leg via transferWithAuthorization, which by design can only send the exact signed amount to the exact signed recipient. Our facilitator broadcasts the authorization and pays gas, but it never takes custody of the funds and can't alter the amount or destination. Data-only, non-custodial, on both chains.
Yes. A single HTTP resource advertises an accepts[] array with two entries — one for USDG on Robinhood Chain (an EVM chain, using EIP-712 / EIP-3009 signatures) and one for USDC on Solana (SVM). The agent reads both options in the 402 challenge and signs whichever rail it already holds funds on. The two legs span different virtual machines, but the agent only signs one.
The agent decides. Robinhood Chain is the primary rail because the data is native to it; USDC on Solana is the fallback so the large population of Solana-native x402 agents doesn't have to bridge just to read Robinhood Chain data. Whichever token the agent already holds, it pays with that.
The USDG-on-Robinhood-Chain leg carries a flat $0.04 minimum because MadeOnSol self-relays that settlement and pays the on-chain gas itself (measured around $0.018 per settle). The USDC-on-Solana leg stays at $0.005–$0.02 because that leg's gas is fee-sponsored by the facilitator. Same data, priced to each rail's economics.
No. On both legs the money moves directly from the agent's wallet to MadeOnSol's. The USDG leg uses transferWithAuthorization, which by design can only move the exact signed amount to the exact signed recipient. The facilitator broadcasts the authorization and pays gas but never takes custody and can't alter the amount or destination. Data-only and non-custodial on both chains.
The discovery endpoint shows both legs for every Robinhood Chain endpoint. It's free:
curl https://madeonsol.com/api/x402/rhc
For the payment flow end to end, see How AI Agents Pay for Robinhood Chain Data in USDG; for a working code example, Robinhood Chain KOL Signals from an AI Agent. Endpoint reference and live pricing: the Robinhood Chain x402 page.
Steadier workload? A flat monthly plan bundles both chains at no extra cost — see madeonsol.com/pricing.
Tools mentioned
Live health scores, average ratings, and direct links on MadeOnSol.
MCP server powered by Solana Agent Kit for on-chain actions
Create shareable blockchain actions and blinks for any Solana transaction
Telegram trading bot for Solana — snipe new tokens, set limit orders, auto-sell, and copy trade with built-in MEV protection
Solana ecosystem resource hub with tool reviews and trading guides
Real-time Solana NFT floor prices, analytics, and market data
Build with MadeOnSol API
KOL tracking, deployer intelligence, DEX streaming, and webhooks. Free API key — 200 requests/day.
import { MadeOnSol } from "madeonsol";
// Get a free API key at madeonsol.com/pricing
const client = new MadeOnSol({ apiKey: "msk_your_key" });
const { trades } = await client.kol.feed({ limit: 10 });
const { alerts } = await client.deployer.alerts({ limit: 5 });
const { tools } = await client.tools.search({ q: "trading" });Building a product on Solana data?
MadeOnSol isn't an RPC or another generic token API — it's Solana memecoin intelligence that's painful to build in-house, pulled from dual-region gRPC shred streams: sub-second from the on-chain event to your app.
Signals you'd otherwise build
KOL & smart-money flow from 2,000+ labeled wallets, deployer reputation, coordination clusters, linked-wallet entity resolution, and an all-DEX firehose.
Embed it in your product
The Business tier (€400/mo, self-serve) licenses you to display MadeOnSol data inside your own product — 500k calls/day, 10 WS + 5 firehose connections. Enterprise above adds white-label & redistribution rights and custom endpoints.
Evaluate first, commit later
Test everything on a free ULTRA key — no commitment. If it fits, we scope volume or white-label pricing.
Keep reading
Guides
A common myth says x402 payments only work with USDC. They don't. USDG (Global Dollar) implements EIP-3009, so it works with x402 today — and it settles natively on Robinhood Chain. Here's why, with the on-chain details.
Guides
AI agents can now buy Robinhood Chain KOL and deployer intelligence per call — no signup, no API key, the wallet is the key. Here's how the x402 payment flow works, and why you can pay in USDG on Robinhood Chain or USDC on Solana.
Guides
A working walkthrough: have an AI agent buy live Robinhood Chain KOL trade signals per call, paying in USDG via x402 — no API key, no signup. About 30 lines with viem and fetch.
Guides
A minimal starter repo that pays a MadeOnSol Robinhood Chain endpoint per call in USDG via x402 — clone it, drop in a wallet key, and you're querying live KOL data in a minute. No API key.
Guides
Accuracy in on-chain data is a provenance question. Here's the full chain of custody behind MadeOnSol's Robinhood Chain API: our own synced node, a self-hosted non-custodial x402 facilitator, and no third-party reseller in the middle.
Comparisons
If you need Robinhood Chain data programmatically, you have three options: an intelligence API like MadeOnSol, an analytics tool like RobinX, or a raw RPC node. Here's what each actually gives you — and where they differ.
Enjoyed this article?
Real-time KOL trades, Pump.fun deployer intel, and 1,200+ ranked Solana & Robinhood Chain tools — free to explore.
Open the KOL TrackerMost x402 endpoints take one token on one chain. MadeOnSol's Robinhood Chain endpoints take two — an agent can pay in USDG on Robinhood Chain or USDC on Solana, and it picks whichever it already holds. Same endpoint, same data, two payment rails. This post explains how that works and why it's built this way.
accepts[] arrayWhen an agent calls an x402 endpoint without paying, the server replies 402 Payment Required with a challenge. That challenge contains an accepts[] array — a list of acceptable payment methods, each describing a scheme, a network, an asset, an amount, and a destination.
Nothing in the standard says that list has to be one entry. So our Robinhood Chain endpoints advertise two:
{
"x402Version": 2,
"accepts": [
{ "scheme": "exact", "network": "eip155:4663", "asset": "USDG (Robinhood Chain)", "amount": "40000", "payTo": "0x…" },
{ "scheme": "exact", "network": "solana:…", "asset": "USDC (Solana)", "amount": "5000", "payTo": "…" }
]
}
The agent reads the list and pays the leg it can satisfy. An EVM-native agent holding USDG signs the Robinhood Chain leg; a Solana-native agent holding USDC signs the Solana leg. One resource, two chains, the client's choice.
This isn't multichain for its own sake. The two legs serve two different agents:
transferWithAuthorization (a gasless signature; the agent pays no gas).What makes this genuinely uncommon is that the two legs span different virtual machines — an EVM signature scheme (EIP-712 / EIP-3009) on one leg, and Solana's SVM payment scheme on the other, advertised on a single HTTP resource. The agent doesn't care; it just signs the one it can.
The two legs don't have to cost the same, and ours don't. The USDG-on-Robinhood-Chain leg carries a flat $0.04 minimum — because we self-relay that settlement and pay the on-chain gas ourselves (measured around $0.018 per settle). The USDC-on-Solana leg keeps the lower base price of $0.005–$0.02, because that leg's gas is fee-sponsored by the facilitator. Same data, priced to each rail's economics. The agent sees both numbers in the challenge and decides.
MadeOnSol is a data provider across Solana and Robinhood Chain. We don't execute or hold custody — x402 settlements move wallet-to-wallet directly.