Contenu source (brut)
<p>Today, we announce the release of <strong>Gatekeeper</strong>, our new edge gateway. Customers accessing Helius through Gatekeeper on top-tier providers can achieve sub-millisecond responses.</p><p>Eliminating our edge latency unlocks the true speed of our core APIs and services. Response time improvements range anywhere from tens to <em>hundreds</em> of milliseconds. </p><img src="/_next/image?url=/api/media/file/gatekeeper-getBlock-latency-eu-central.jpg&w=3840&q=90" alt="Comparing getBlock RPC request latency of Helius using the Gatekeeper edge gateway vs. competitors" /><h2>Building Solana Infrastructure for Speed and Scale</h2><p>When Helius launched, Solana developers had urgent needs: reliable RPC access, human-readable APIs, real-time data streaming, and infrastructure that just worked. </p><p>We made the deliberate choice to build on Cloudflare to get to market quickly and start serving these needs immediately.</p><p>This initial architecture serves us incredibly well:</p><ul class="list-bullet"><li value=1><strong>Cloudflare Workers</strong> handles routing, auth, and request processing</li><li value=2><strong>Durable Objects </strong>manages per-project metering and state</li><li value=3><strong>Cloudflare Load Balancers</strong> distribute traffic across our network</li></ul><p>TL;DR: We could iterate rapidly and ship features that developers needed <em>now.</em></p><h3>The Challenge: Growing Beyond Our Initial Design</h3><p>Fast forward to today: Helius is the preferred infrastructure provider for thousands of Solana developers and serves billions of requests per day. </p><p>As Solana’s ecosystem has grown, so has a class of workloads—high-frequency trading, real-time liquidity engines, latency-sensitive MEV strategies—where every millisecond matters.</p><p>For these workloads, the limiting factor isn’t any single piece of infrastructure. It’s physics. </p><p>When a request has to travel from a user to a cloud edge network and then back to our backend nodes before it can be processed, that extra hop can be detrimental. No amount of software optimization can eliminate that added latency. </p><p>Even at the speed of light, the round trip to and from a general-purpose edge adds measurable milliseconds.</p><p>Our customers asked us a simple question: “Can you give us a shorter path?” The answer, resoundingly, is <em>yes</em>. </p><p>The answer to that question is a purpose-built edge gateway that gives latency-critical workloads the most direct route possible to our infrastructure. The answer is a solution designed to handle Solana’s speed at Helius’s scale.</p><h2>What is Gatekeeper?</h2><p><a href="https://www.helius.dev/docs/gatekeeper/overview"><span style="text-decoration: underline">Gatekeeper</span></a> is our in-house edge gateway built in Rust using the <strong>Hyper HTTP framework</strong>. </p><p>Gatekeeper acts as a single, unified entry-point for all requests: it terminates connections at geographically distributed edge locations, and intelligently routes requests to our backend infrastructure. </p><p>For latency-critical workloads, Gatekeeper provides the shortest network path, reducing hops and shaving off milliseconds. This enables us to optimize every service that matters for high-frequency, low-latency workloads. </p><p>Gatekeeper is a step-function improvement in latency and reliability for Solana developers.</p><h3>Benefits of Using Gatekeeper</h3><p>Gatekeeper’s advantage comes from its global, low-latency, zero-downtime deployments, and unified entry-point design.</p><h4>Reduced Latency</h4><p>Gatekeeper’s performance improvements are a result of:</p><ul class="list-bullet"><li value=1>Being written in Rust using Hyper with async I/O for max throughput and minimal latency</li><li value=2>Having fine-grained control over connection pooling, TLS, and socket options</li><li value=3>Requests being processed geographically closer to users</li></ul><p>This represents a significant change to our platform, with users experiencing a drastic reduction in latency. </p><p>For example, a user making a <code>getSlot</code><strong> </strong>request with Helius may currently see response times of ~122 ms with a new connection and ~35 ms with a reused connection. </p><p>However, with Gatekeeper, a user making a <code>getSlot</code><strong> </strong>request with Helius may see response times of ~26 ms with a new connection and ~0.5 ms with a reused connection. </p><p>Here's a full breakdown:</p><h4>Cold Connections</h4><span>unknown node</span><h4>Warm Connections:</h4><span>unknown node</span><p>Source: <a href="https://gist.github.com/0xIchigo/4cabc8b01802a9a3767a72c92e13eeae" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">A full breakdown of </span><code><span style="text-decoration: underline">getSlot</span></code><span style="text-decoration: underline"><strong> </strong></span><span style="text-decoration: underline">timing details</span></a> comparing our current infrastructure with Gatekeeper</p><h4>Global Presence</h4><p>An edge gateway’s performance is a function of its global availability and routing. Because Solana is a massively distributed network handling 1,000s of transactions per second, Gatekeeper needs to be globally accessible and always available.</p><ul class="list-bullet"><li value=1>Deployed globally across Europe, America, and Asia, with more locations on the way</li><li value=2>Uses intelligent routing to automatically direct requests based on node proximity, health, and load</li><li value=3>Ensures optimal routing with continuous health monitoring</li></ul><h4>Zero-Downtime Deployments</h4><p>Upgrades across any service, platform-wide, running on Gatekeeper can now occur without any interruptions. No maintenance windows. No scheduled downtime. No coordination needed. </p><p>Gatekeeper’s architecture gives us the ability to ship performance optimizations and fix bugs while offering uninterrupted, 24/7 service via zero-downtime deployments.</p><ul class="list-bullet"><li value=1>Graceful connection draining during upgrades</li><li value=2>No dropped requests during infrastructure upgrades</li><li value=3>Continuous operation, even as we improve the system</li></ul><h4>Unified Design</h4><p>Gatekeeper’s design includes:</p><ul class="list-bullet"><li value=1>A single entry point for all RPC methods, webhooks, and APIs</li><li value=2>Native support for both JSON-RPC 2.0 and REST endpoints</li><li value=3>Integrated rate limiting and metering at the edge </li></ul><h3>What Gatekeeper Supports Today</h3><p>Today, Gatekeeper supports:</p><ul class="list-bullet"><li value=1>All standard Solana RPC endpoints</li><li value=2>All Helius-specific RPC endpoints (e.g., gTFA<strong>)</strong> </li><li value=3>All Standard and Enhanced WebSockets endpoints</li><li value=4>All DAS API endpoints</li><li value=5>All Photon API endpoints (i.e., ZK Compression)</li><li value=6>The Helius Priority Fee API</li><li value=7>The Enhanced Transactions API</li></ul><p>Gatekeeper does not yet currently support LaserStream.</p><h2>Try Gatekeeper</h2><p>Gatekeeper is now available in public beta to all Helius customers. It is currently opt-in while we continue to optimize and migrate more of our internal services. Over the next few months, Gatekeeper will become the default for all Helius RPC and WebSocket traffic. </p><p>To try Gatekeeper, use:</p><p><code>https://beta.helius-rpc.com/?api-key=<YOUR_API_KEY></code></p><p>Your existing API key will work with the Gatekeeper beta endpoint. All you need to do is change URLs—everything works out of the box. The endpoint is also available in your <a href="https://dashboard.helius.dev/rpcs"><span style="text-decoration: underline">dashboard</span></a>. </p><p>Currently, Gatekeeper is only available on Mainnet. Devnet support is not currently available, but will be in the near future.</p><p>For more details, read the <a href="https://www.helius.dev
