Skip to content
0%

How the edge layer powers faster RPC on Alchemy

Author: Uttam Singh

Last updated: May 13, 20265 min read
Alchemy Edge Proxy banner

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.

The result is the fastest blockchain RPC ingress layer in production today.

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:

Alchemy Edge Proxy request lifecycle: client to Geo DNS to Istio Ingress Gateway to EPCP back to Istio to destination cluster
  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.

Geo-based DNS routing diagram: requests resolve to the closest Alchemy Edge Proxy region regardless of target chain

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:

yaml
Copied
regions: us-east: enabled: true routes: "/v2": verbs: ["POST"] destination: archive-cluster fallbackRegions: - us-west - eu-central - apac-southeast security: ipsBanned: ["..."] pathsBanned: ["..."]

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:

Security layerPrevious (CDN)Edge Proxy
OFAC / locality compliance
CDN WAF rules
Maxmind geolocation with application-level enforcement
DNS DDoS
CDN
DNS provider (standard protection)
Volumetric DDoS (UDP / ICMP floods)
CDN
Infrastructure provider with built-in anti-DDoS protection
Protocol DDoS (SYN floods, IP fragmentation)
CDN
Infrastructure provider for IP fragmentation; Envoy for SYN floods (connection limits, timeouts)
L7 DDoS (application-layer attacks)
CDN WAF
Envoy configuration with path allowlisting, IP-based rate limiting, max request time limits

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

MetricBefore (CDN)After (Edge Proxy)Improvement
P99 (APAC)
150ms
20ms
7.5x faster
P50 (median)
~35ms
~5ms
7x faster
P95 (all networks)
~200ms
~100ms
~100ms reduction

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

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:

CDN-proxiedDirect connectionCustom edge proxy (Alchemy)
Latency
100+ms overhead at p95
Lowest possible
Matches direct connection
Traffic types supported
All (HTTP, WSS, frontend, backend)
RPC / WSS backend only
All (HTTP, WSS, frontend, backend)
DDoS protection
Built-in
None
Built-in (infrastructure provider + Envoy)
OFAC compliance
CDN WAF rules
Not compliant
Application-level enforcement
Customer migration required
No
Yes
No
Vendor dependency
CDN vendor
None
Own infrastructure
Cost scaling
Scales with traffic
Minimal
Fixed infrastructure cost

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.

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.

Alchemy Newsletter

Be the first to know about releases

Sign up for our newsletter

Get the latest product updates and resources from Alchemy

A
O
D
+
Over 80,000 subscribers

By entering your email address, you agree to receive our marketing communications and product updates. You acknowledge that Alchemy processes the information we receive in accordance with our Privacy Notice. You can unsubscribe anytime.