Kasra Khosravi

Aram Alipoor

: Starting today, any agent or developer can access Goldsky's Edge RPC: 40+ EVM networks without creating a Goldsky account.

You can pay per-request in stablecoins via Nanopayments powered by Circle Gateway and the x402 protocol. No API key provisioning or human in the loop required.

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 Nanopayments handle the payment rails. You collect the revenue.

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.

Traditional onchain payments have a gas problem. If a single RPC call costs fractions of a cent, paying for it onchain with even a $0.01 gas fee makes no economic sense. 

You'd spend more on settlement than on the actual service.

Take Goldsky Edge, our hosted RPC service. It costs $5 per million requests, or $0.000005. 

A gas fee of even 1/1000 of a cent (very reasonable by blockchain standards) would triple the cost of the call.

 Users would be spending more on executing the transaction than paying for the API call, breaking the economics both for the buyer and the service provider.

How Nanopayments makes sub-cent pricing viable

Nanopayments sidesteps the gas problem with a batched settlement model.

 Rather than settling every transaction onchain individually, per-request authorization happens off-chain and payments are settled onchain in batches.

An agent deposits USDC into a Gateway wallet once (the only call that costs gas). From there, each payment is a signed authorization that Nanopayments validates instantly; the merchant gets confirmation and releases the data. Thousands of these authorizations settle together in a single onchain batch, with Nanopayments covering the batch-level gas at settlement.

The buyer pays gas once; the seller pays none at all. The result: sub-cent payments that are actually sub-cent, not sub-cent-plus-gas.

AI agents can access blockchain data via Edge RPC

 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 

With Nanopayments enabled, Edge RPC now has a second access path alongside the standard API key flow:

Pricing is identical across both paths. Our standard Edge RPC plan runs 

. Through the Nanopayments layer, that same per-request rate is encoded into the 402 payment payload your agent receives. What this means in practice:

Monetizing subgraphs via x402 with Nanopayments

Edge RPC via Nanopayments is only the beginning. 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:

That's it. Your subgraph becomes a paid API endpoint, reachable by any agent. Calls made via x402 are excluded from your rate limits, so traffic from third-party developers and builders can access your infrastructure without eating into your own usage. Circle handles custody and settlement, Goldsky handles routing and payouts, and you don't have to write a payment contract or run a billing system. 

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 onchain data programmatically.

The X402-enabled Edge RPC endpoint is live today. No account required (just a funded wallet!) 

Set your price, provide a wallet address, and we'll handle the rest.

Standard Edge RPC access, 40+ networks, no credit card required to start.

Circle x Goldsky: Nanopayments as the payment layer for blockchain data

In 2024, we were building an EVM indexer and battling the same RPC problems every web3 team deals with: providers going down, stale data, rate limits at the worst possible moment.

So we built our own proxy to fix it, and eventually open-sourced it as 

. Teams like Circle and Morpho started contributing and using it. Then Goldsky acquired us.

, a managed version of eRPC that runs on a global edge network. This post shares more about how we got here, what Edge does under the hood, and a few things we learned along the way.

 Goldsky Edge is a single RPC endpoint that leverages a multi-region architecture to route requests across 8+ global regions, validates responses via cross-node consensus, and fails over within milliseconds. Flat $5/million requests with no upcharges. Supports most EVM chains and 60+ standard JSON-RPC methods.

Why we built an open-source EVM RPC proxy

July 2024 was when we first started building eRPC. Like many products, it was initially built to solve a problem we were facing ourselves.

At the time, we were working on an EVM indexer called Flair (actually a Goldsky competitor at the time!). We kept running into annoying problems with our RPC stack: reliability was poor, resiliency was low, failovers were nonexistent, and speed was inconsistent. Every RPC provider promises fast, reliable, and cheap. But almost all of them let you down at least 10% of the time.

The typical workaround is to either stick with one provider and hope for the best, or you put a basic round-robin proxy in front of a few and pretend that's high availability and redundancy. But a proxy that actually understands the EVM (knows what a re-org means for cached data, knows RPC call methods behave differently across providers, knows a node can be "up" but still serving stale blocks, etc.) didn't exist.

So we built an internal version for ourselves. It was a proxy layer that handled caching, failovers, rate limiting, and smart batching to help keep Flair running smoothly.

And it worked pretty well! Well enough that we began talking to other teams in the space. Unsurprisingly, almost everyone building serious web3 infrastructure had either built their own internal RPC proxy or was suffering without one.

The problem was universal, but nobody had open-sourced a proper solution. Why did this matter? Because to be fully comfortable, this tool needed to be open-source so that you could run it next to your infra while having full control over the configs.

That's when we decided to release eRPC as an open-source project. We put it out in August 2024 and started sharing it with people in the ecosystem.

Adoption came faster than we expected. We quickly saw forks, clones, and PRs from the likes of Polygon, Circle, Morpho, Succinct, Nethermind, and more.

One of those people was Jeff at Goldsky. We reached out to him early on, and he was interested; Goldsky had already built their own internal solution for the same problem.

A few months later, in December 2024, Jeff came back to us. Goldsky used a similar architecture for their indexing product and he saw potential synergies between what we were building and what they needed.

The conversations kept going because the alignment was obvious: we were solving the same problem from different angles. Joining together meant we were going to solve much harder problems together at a larger scale.

In January 2025, Goldsky officially acquired us.

eRPC continues to remain fully open-source and maintained.

Every blockchain team rebuilds the same flawed RPC layer

If you've built anything on EVM chains, you've dealt with RPC issues that quietly ruins your Thursday afternoon.

Your indexer silently falls behind because a provider started returning stale block heights. Your frontend hangs for 2 seconds because 

 routed to a node on the other side of the planet. Your 

 response comes back missing half the events, and you don't find out until a user files a bug report (or worse, you face revenue loss).

Most teams deal with this by duct-taping together multiple providers, writing custom retry logic, and building health-check scripts that page them at ungodly hours. Some teams build an internal proxy layer (like we did). Well-funded teams hire a person whose entire job is managing RPC infrastructure.

None of these are great solutions. They're just varying degrees of coping with the same underlying issue: 

the standard RPC endpoint is a single point of failure that doesn't know anything about the requests it's serving.

it doesn't matter how good a provider's reputation is. During reorgs, even "benchmark trusted" providers return wrong data.

No single upstream is immune, even those with internal layers of proxies and node redundancies. There had to be a smart middleware layer to handle this. Something that validates before it returns.

How Edge handles RPC caching, routing, failover, and validation

Edge sits between your application and the upstream RPC providers. It's a proxy layer, functioning with the reliability of an AWS Network Load Balancer, but calling it that undersells what's happening inside. Here's a simplification of what happens when your app makes an RPC call:

Global edge routing: your request hits the nearest node

Finality-aware caching: the cache checks if it already has the answer

Multiplexing: identical requests get merged

Adaptive node scoring: Edge picks the best upstream for your RPC call method

Auto-splitting: large queries get broken up and stitched back together

Cross-node consensus: responses are validated before they reach you

Automatic failover: if anything goes wrong, you don't notice

All of this is visible from day one. Edge endpoints come with an advanced Grafana dashboard with request volume, latency percentiles, error rates, upstream provider health, etc. out of the box. We also surface detailed error logs with full context: which method, which chain, which upstream, what went wrong.

We'd be lying if we said we building Edge was smooth sailing. Far from it.

There were moments we nearly threw in the towel. We battled complex, cascading memory pressure bugs. And our consensus feature, the one we were most committed to, sometimes caused more problems than it solved. Not because our logic was wrong, but because some chains were in a broken state and nodes had no way to agree. We pushed through those and made the system more robust each time.

Our first caching layer was too aggressive.

 We cached responses that could become stale during chain reorgs, and served them to indexers that needed the canonical chain data. We had to build reorg-aware cache invalidation to track the chain tip and purge entries when blocks get replaced. This is the kind of thing that works fine 99.99% of the time and catastrophically fails during the 0.01% that matters most. Reorgs on Polygon and HyperEVM are particularly brutal, where providers silently return stale data with no indication anything is wrong.

This led to an unexpected rabbit hole: block cache corruption.

 It's not just "bad RPC data". There's a complex interplay of cache delays, reorgs, consensus timing, and downstream indexing assumptions that all compound on each other. It led us to rethink the entire validation architecture from scratch.

Consensus doesn't help if everyone is confidently incorrect.

 Sometimes four nodes agree on a block, and they're all wrong. During reorgs, multiple providers can serve the same orphaned block with full confidence. You have to layer in finality awareness, track the canonical chain state independently, and be willing to invalidate data that passed consensus seconds ago.

We also underestimated how much variation there is between providers for the same method.

 implementation might handle a 10,000-block range without flinching while another returns a rate limit error at 1,000 blocks. Our auto-splitting logic had to get smarter about learning each upstream's actual limits rather than assuming uniform behavior. Much of this is undocumented and can only be learned through experience with hundreds of billions of queries to catch every edge case.

Multiplexing sounded straightforward until we ran into edge cases around request timing windows and error propagation.

 If 200 users request the same block at the same time and the upstream returns an error, you need to be careful about how you propagate that failure. Retrying once and fanning out the result is different from fanning out the error.

One thing that frustrated us about the RPC market is pricing complexity. Most RPC providers use compute unit (CU) systems where an 

 call might cost 75 CUs for example and a 

 costs 1 CU. You can't predict your bill without knowing your exact method distribution, which changes as your application and user traffic evolves.

And every method costs the same. No compute unit multipliers, tiered method pricing, or hidden surcharges. You'll know your exact cost based on how many requests you've sent.

User experience is the #1 deciding factor for every single decision at Goldsky, and pricing is no exception. If we're routing your requests efficiently and caching some expensive ones, the cost to us per request flattens out. Passing that simplicity through to pricing just makes sense. Unlike providers that charge different rates for 

 methods, Edge treats every call the same: archive queries, trace calls, log fetches, they’re all the same price.

Volume discounts kick in at 500M+ requests/month. Chat with us if you're at that scale for even better pricing.

eRPC stays open-source while Edge builds on it at scale

Edge is built on eRPC, which will continue to be maintained as open-source under Apache 2.0. The core proxy logic (like routing, caching, failover, circuit breaking) is all in the public repo, making it easy to integrate with tools like Terraform.

Edge adds the managed infrastructure layer on top: the global CDN, monitoring stack, upstream provider relationships, and the operational work of keeping it running at scale.

Because eRPC is open-source, you can also run it as a sidecar inside your own indexer. You get full context on validation, consensus, and retry logic, with complete control and visibility into what's happening because it’s an open box.

If you want to self-host, you can. If you want us to run it for you, that's Edge. The open-source project gets better because the managed product funds development, and the managed product gets better because the open-source community finds bugs and contributes features. It's a flywheel that's already spinning – community PRs from teams like Circle and Polygon have directly improved Edge, and Edge usage surfaces bugs that get fixed upstream in eRPC.

If you're running infra at scale and want to talk about volume pricing or dedicated CDN nodes, 

We built this because we needed it. We think you might like it too.

Real-time Data

RPC Infrastructure

Automation

Open Source

Follow

Kasra Khosravi

Kasra's articles