Goldsky x Circle: Nanopayments as the payment layer for blockchain data
In 1991, the original spec for internet standards reserved a status code: "402" with a one-line description: "Payment Required." The note alongside it said the code was "reserved for future use." That future is now.
tl;dr: Starting today, any agent or developer can access Goldsky's Edge RPC: 40+ EVM networks without creating a Goldsky account.
They pay per-request in stablecoins via Circle Nanopayments and the x402 protocol. No API key provisioning, no human in the loop.
And soon, any Goldsky user can do the same thing with their own subgraphs: flip a switch, set a price, and your indexed data becomes a paid API endpoint reachable by agents and developers across your ecosystem. Goldsky and Circle handle the payment rails. You collect the revenue.
The problem with APIs and agents
Agents can make HTTP requests. That part works fine. What they can't do is sign up for a billing account, enter a credit card, wait for an email confirmation, and then get the API key they need with the credentials to spend that money. The payments barrier is managed by a credentials barrier; neither of which is designed for agents: these systems have historically assumed a human is sitting at the keyboard and that assumption is no longer a sound one. So how does an agent discover, negotiate, and pay for API access programmatically, with no prior relationship with the provider?
With x402 - an open protocol that gives the HTTP 402 status a real job. The mechanics are simple:
Agents make a request to an API endpoint
The server responds that payment is required with "402"
The agent pays; constructing a stablecoin transaction and including the payment proof, and then sends another request
The server verifies and responds with the requested data. No credentials needed, as credentials were always partially a gateway to managing payments.
In the future, the agent can remember the API requires payment, and include a payment in advance rather than getting the 402 first.
What makes this viable now at a per-request level, rather than just theoretically interesting, is Circle Nanopayments.
The problem with x402
Traditional on-chain payments have a gas problem. If a single RPC call costs fractions of a cent, paying for it on-chain with even a $0.01 gas fee makes no economic sense. You'd spend more on settlement than on the actual service.
For example, Goldsky's hosted RPC service - Edge - charges $5 per million requests, or $0.000005. Even if the gas fee were one thousandth of a cent - very reasonable by blockchain standards - users would be spending more in executing the transaction than paying for the API call, breaking the economics both for the buyer and the service provider.
Circle Nanopayments solves this with a payment channel model. Rather than settling every transaction on-chain individually, payments are batched and settled periodically, while per-request authorization happens off-chain. The result: sub-cent payments that are actually sub-cent, not sub-cent-plus-gas.
What this looks like for Edge RPC
Goldsky Edge is our RPC layer: a globally distributed, finality-aware proxy across 40+ EVM-compatible networks. It handles provider failover, caches finalized blocks aggressively, and routes requests to the nearest healthy node. For a full technical breakdown of how Edge works under the hood, see our Edge architecture post.
With Circle Nanopayments enabled, Edge RPC now has a second access path alongside the standard API key flow:
Standard path: Create a Goldsky account, generate an endpoint, use your API key. Same as before.
x402 path: Hit the x402-enabled endpoint with no credentials. Receive a 402 with payment instructions. Pay with a funded wallet and get your data, or if you pre-pay you get your data immediately on the first call.
Pricing is identical across both paths. Our standard Edge RPC plan runs $5/million requests. Through the Nanopayments layer, that same per-request rate is what gets encoded into the 402 payment payload your agent receives. What this means in practice:
An agent can discover and access blockchain data dynamically. No operator needs to pre-provision credentials. The agent handles the full payment handshake autonomously.
Multi-chain access is immediate. The same endpoint covers Ethereum, Base, Arbitrum, Polygon, and 37+ other networks. The agent doesn't need separate accounts or keys per chain.
The bigger picture: Goldsky as the monetization layer
Our own product - Edge - via Circle Nanopayments is the proof-of-concept. The larger vision is to enable every Goldsky user to monetize their infrastructure without having to touch the payment rails. We're opening a beta for subgraph monetization via x402. Here's how it works:
Deploy a subgraph on Goldsky, or use one you already have running.
Enable x402 on that subgraph from your dashboard.
Set a price per request and provide a deposit wallet address.
Goldsky takes a flat minimum fee to cover operating costs. The rest routes to your wallet automatically.
That's it. Your subgraph becomes a paid API endpoint, reachable by any agent, without creating a burden on your infrastructure. Calls made via X402 are excluded from your rate limits, allowing for third-party developers and builders to access your infrastructure without placing a burden on your own usage. No payment contract to write. No settlement service to run. No billing to manage. Goldsky handles custody, routing, and settlement. You set a price and collect revenue.
If you've built a high-quality subgraph indexing a protocol, a chain, or a dataset that other developers need, you can now charge for access directly and make it available to the growing ecosystem of agents consuming on-chain data programmatically.
For agent developers: The X402-enabled Edge RPC endpoint is live today. No account required, just a funded wallet. View the docs →
For subgraph owners: Sign up for the monetization beta → Set your price, provide a wallet address, and we'll handle the rest.
For everyone else: Create a free Goldsky account → Standard Edge RPC access, 40+ networks, no credit card required to start.