How the edge layer powers faster RPC on Alchemy

Alchemy runs its own edge layer on bare metal rather than fronting RPC traffic with a third-party CDN. Geoproximity DNS resolves each request to the nearest Alchemy region — US East, US West, EU Central and Southeast Asia — and regional health checks fail traffic over to the next-closest region automatically, with no action from you. After the October 2025 rollout, APAC P99 latency fell from 150 ms to 20 ms.

Trillions of dollars in value now move through blockchain infrastructure every year. A DeFi swap on Solana, a stablecoin transfer on Ethereum, a prediction market settlement on Polygon: each of these transactions depends on RPC calls that travel through layers of networking before reaching a node. When financial activity runs onchain, every millisecond in that path is money at risk.

For an infrastructure provider serving trillions of requests across 100+ blockchain networks, the layer between the user and the data center is where performance is won or lost. That layer is the edge. And in late 2025, Alchemy rebuilt it from scratch.

Why does RPC latency matter for onchain finance?

Blockchain users and applications are distributed globally. A trading bot in Singapore, a wallet app in Frankfurt, a DeFi protocol's backend in Virginia: they all make RPC calls to read blockchain state and submit transactions. The faster those calls resolve, the better the experience.

In DeFi, latency translates directly to execution quality. A slower eth_call means stale price data. A delayed transaction submission means worse fills or failed trades. For wallet applications, every extra 100ms of load time degrades the user experience that keeps people onchain.

But latency is only half the equation. Reliability matters just as much. If your RPC provider routes all traffic through a single third-party CDN, that CDN becomes a single point of failure. When it goes down, every network, every customer, and every request goes down with it.

What is the Alchemy Edge Proxy?

Think of the Edge Proxy as the front door to Alchemy's RPC infrastructure. Every API request, whether it is reading Ethereum state, querying Solana accounts, or submitting a transaction on Base, passes through this ingress layer before reaching the serving infrastructure behind it.

For years at Alchemy we used a major CDN as that front door. CDNs are a popular industry choice for good reason: they ship out of the box with DDoS protection, geographic routing, WAF rules, and SSL termination. For most web applications, that bundle is good enough. CDNs have spent two decades being the default ingress layer for everything from e-commerce to streaming, and they earn that position.

Onchain finance has different demands. RPC traffic is bursty, latency-sensitive, geographically global, and security-critical in ways that ordinary web traffic is not. A trading bot reading state across three chains in parallel does not care that a CDN can cache a marketing page in 50 cities. It cares about the time between issuing eth_call and getting a response. A wallet syncing balances does not need a WAF rule for SQL injection. It needs the closest possible edge node and a TLS handshake that completes in single-digit milliseconds. A protocol settling positions on a derivatives exchange cannot tolerate a third-party CDN's incident timeline as a ceiling on its own uptime.

To meet those demands, we built a custom edge proxy on bare metal: a purpose-built ingress layer designed from the ground up for high-throughput, low-latency blockchain RPC traffic. It runs on Alchemy-controlled infrastructure across multiple global regions, replaces every CDN-layer protection with an equivalent or stronger layer that we can tune per network, and removes a third-party dependency from the critical serving path entirely.

In the October 2025 rollout, P99 latency in APAC fell from 150 ms to 20 ms and median latency from about 35 ms to about 5 ms, measured across 100+ networks.

How does the Alchemy Edge Proxy work?

The Edge Proxy architecture consists of two core components running on dedicated bare-metal servers across multiple global regions (US East, US West, EU Central, Southeast Asia, and others).

Istio Ingress Gateway

The first component is an Istio Ingress Gateway running Envoy as the data plane. This handles TLS termination, connection management, and request proxying. Envoy is the same proxy that powers Lyft, Google Cloud, and AWS App Mesh under load. Its async non-blocking C++ core, HTTP/2 multiplexing, and pre-warmed upstream connection pools make it well-suited to high-throughput, low-latency ingress.

Edge Proxy Control Plane (EPCP)

The second component is a custom control plane that runs alongside Envoy as an ext_authz filter. For every incoming request, the EPCP evaluates:

• Where to route the request based on URL, headers, and the target blockchain network
• Which backend clusters are available for that request (e.g., archive node clusters, AWS-hosted services, region-specific endpoints)
• Whether the request should be blocked for security or compliance reasons
• Which networks are healthy in the local region (via health checks)

The EPCP then injects routing headers that tell Envoy where to forward the request. This design keeps the hot path fast (Envoy handles the proxying) while keeping routing logic flexible and dynamically configurable.

Request lifecycle

Here is how a typical successful request flows through the system:

1. The client sends an RPC request to *.g.alchemy.com.
2. Geo-based DNS resolves the request to the nearest Edge Proxy region.
3. The Istio Ingress Gateway receives the request and passes it to the EPCP via ext_authz.
4. The EPCP validates the request (OFAC checks, security rules), determines the destination cluster, and returns routing headers.
5. Istio forwards the request to the appropriate backend.
6. The response returns directly to the client.

Geo-based DNS routing

The Edge Proxy uses geoproximity-based DNS resolution. This means the DNS layer is chain-agnostic and network-agnostic: a request for Ethereum mainnet and a request for Solana mainnet both resolve to the same regional Edge Proxy. The Edge Proxy itself handles network-aware routing internally.

This design has several advantages:

• DNS resolution and TLS handshakes happen at the closest edge location regardless of which blockchain network is ultimately needed.
• Adding new blockchain networks requires zero DNS changes.
• Regional health checks run at the Edge Proxy level. If an Edge Proxy region goes unhealthy, DNS automatically fails over to the next-closest region.

Dynamic configuration

The Edge Proxy pulls its routing configuration from our internal configuration platform. This enables runtime changes without redeployments:

If a region needs to be drained, a network needs rerouting, or a new security rule needs enforcement, the configuration updates propagate without touching the running proxy.

How does the security model work without a CDN?

Removing the CDN dependency meant rebuilding every security protection from scratch. The Edge Proxy replaces the CDN's protections with a layered approach:

The key insight: these protections are not weaker than the CDN's. They are more targeted. Alchemy controls every layer, can tune thresholds per network, and is not dependent on a third party's incident response timeline when something goes wrong.

What results has the Alchemy Edge Proxy delivered?

The Edge Proxy rolled out across 100+ blockchain networks over three weeks in October 2025, with zero customer migration required. The results were immediate.

Latency

Customer-side telemetry showed similar magnitude improvements across diverse workloads, with the most latency-sensitive seeing the largest gains.

For current public provider data, compare RPC latency benchmarks across chains, regions, and common methods.

Reliability

Across the same window where the previous CDN-fronted setup would have been exposed to upstream incidents, Alchemy's infrastructure ran unaffected.

How does this compare to other infrastructure approaches?

There are three common approaches to handling ingress for blockchain API infrastructure:

The custom edge proxy combines the latency advantages of a direct connection with the protection and traffic flexibility of a CDN, without the vendor dependency or cost scaling of either.

Some RPC providers have shipped CDN-less edge solutions, but those rollouts have typically required customers to migrate to new endpoints behind deprecation deadlines. The Alchemy Edge Proxy delivered equivalent or greater performance gains with zero customer action required.

Frequently asked questions

Which RPC provider has the best global edge network?

It depends on where your traffic originates, so the useful comparison is mechanical rather than a ranking. Four things to check on any provider: whether the ingress layer is the provider's own infrastructure or a rented third-party CDN, how many regions it runs and where, whether failover between regions is automatic or something you configure, and what the measured latency is from your region rather than globally.

Alchemy runs a custom edge proxy on dedicated bare-metal servers across US East, US West, EU Central and Southeast Asia, replacing a third-party CDN that previously sat in the serving path. Removing that dependency means no external vendor's incident timeline caps Alchemy's own uptime. For current measured numbers by region, see the live RPC latency benchmarks.

Which providers offer multi-region RPC failover out of the box?

"Out of the box" is the part worth checking — plenty of providers support failover if you configure it, which is a different product than failover that already works.

On Alchemy, failover is automatic and requires no setup: regional health checks run at the Edge Proxy level, and when a region goes unhealthy, DNS fails traffic over to the next-closest region. Each region carries an explicit ordered fallback list, so traffic has a defined path rather than resolving arbitrarily. Because this happens at the DNS and ingress layer, there is nothing to configure in your application, and no migration was required when the layer rolled out across 100+ networks in October 2025.

How does geo-based DNS routing work for RPC?

Alchemy uses geoproximity-based DNS resolution. A request to *.g.alchemy.com resolves to the nearest edge region, and the DNS layer is deliberately chain-agnostic — a request for Ethereum mainnet and a request for Solana mainnet resolve to the same regional edge proxy, which then handles network-aware routing internally.

Two consequences follow. DNS resolution and the TLS handshake happen at the closest edge location regardless of which chain the request ultimately needs, which is where most of the round-trip saving comes from. And adding a new blockchain network requires no DNS changes at all, so network coverage and routing scale independently of each other.

What happens to my traffic when a region fails?

Regional health checks run continuously at the Edge Proxy level. When a region is marked unhealthy, DNS stops resolving to it and sends traffic to the next-closest region, following an ordered fallback list configured per region rather than picking arbitrarily.

The routing configuration is pulled at runtime from an internal configuration platform, so a region can be drained, a network rerouted, or a security rule enforced without redeploying or restarting the proxy. From your application's side nothing changes: the same endpoint keeps working, served from a different region.

Build on the fastest blockchain infrastructure

Alchemy's Edge Proxy is one piece of a platform built for the demands of global financial activity. Up to 7.5x faster RPC at the tail, 100+ supported networks, multi-region presence across multiple continents, and zero-action performance upgrades: it all comes out of the box with Alchemy's RPC endpoints.

Whether you are building a DeFi protocol, a wallet, a payment application, or onchain infrastructure for financial institutions, performance and reliability are table stakes. Explore the full list of supported chains, dive into the Alchemy developer documentation, or create a free account to start building.