Advanced Rate Limits: Manage and Secure Your Solana RPC Endpoints Using Custom Rules

This post is Part 2 of our series introducing Syndica's advanced web3-native API offering on Solana. Stay tuned for upcoming posts exploring features in detail, including ChainStream API, App Deployments, Dynamic Indexing, and more.

Advanced Rate Limit Settings

Building upon our enterprise-grade Solana RPC offering, we have implemented credential-level rate limit settings on the Syndica platform, granting developers precise control over the usage of their API keys. This feature mitigates two problems that arise for developers on Solana:

1. Prevent Unwanted Usage of Your RPC Service: A common issue for applications on Solana is the theft and misuse of RPC API credentials, especially through application front-ends. This problem occurs because once an RPC URL or API key is exposed in the front-end source code, it can be easily copied and exploited for unauthorized activities, such as NFT mints, etc. To address this, additional back-end solutions are often required for rule-based rate limiting.

On Syndica, API keys can be securely exposed to the public by setting appropriate rate limits per IP for the specific methods your users require. This is in addition to our existing header-based rules (IP and Origin).

2. Managing Rate Limits for Separate Projects or Services: Elastic-node RPC services on Solana typically impose global rate limits on each account, leaving the customer responsible for managing individual project-level limits. To prevent a spike in request volume from one project causing rate limitations for another, developers must implement their own project-level rate limits.

On Syndica, API keys can be configured with individualized rate limits, allowing developers to precisely manage and balance usage limits across all projects within their account.

We will illustrate two scenarios demonstrating how our new Advanced Rate Limit Settings effectively address these issues.

Scenario #1 - Protecting a Front-end RPC Endpoint

Consider a simple React application using web3.js to display information about a user's wallet, such as token balances and recent transactions. The required set of RPC methods includes:

• getAccountInfo
• getTokenAccountsByOwner
• getTokenAccountBalance
• getSignaturesForAddress
• getTransaction

On Syndica, we can create an API key for this front-end with a configuration that prevents unwanted usage.

The first step is restricting the API key to only serve requests where the header includes our domain, simple-dapp.xyz. We also have the option to use a wildcard to match our subdomain pattern.

Next, we can disable WebSocket connections for this credential, as they are not necessary for our use case.

Finally, we will restrict the API key to only use the methods our front-end requires. Below, you can see the various scopes where we can set rate limits for our API key:

• RPS Limit: A maximum rate per second applied to the combined traffic of all clients
• RPS Limit per IP: A maximum rate per second applied to the request volume from each unique client IP
• Specific Method Limits: Maximum rate per second for specific RPC methods can be applied to overall combined traffic or per IP

We will set the specific method limits at the IP level in our scenario. We aim to restrict the credential's usage to the few methods our front-end requires and limit each method's RPS to rates typical for a single user (one client IP).

With this configuration, RPC calls from the front-end will operate seamlessly for users adhering to the expected traffic pattern. If the API key is compromised, its utility will significantly diminish as it will be restricted to a limited set of methods and a low RPS.

#2 - Managing Rate Limits Under a Single Account

Let’s say we want to create a separate back-end service using the Syndica API. This back-end service must share our account's global rate limits with the above-mentioned front-end service.

Assume our global account-wide rate limit is 300 RPS, with the back-end service consistently using up to 50 RPS. To avoid risking rate-limiting our critical back-end service, we want to ensure the front-end service never exceeds 250 RPS. We can allocate a portion of our account's total RPS to each service, ensuring that a traffic spike in one doesn't impact the other.

We can modify our initial API key to cap at 250 RPS for the combined traffic from all clients.

Then, we can create a separate API key for the back-end service. Let’s assume our back-end service uses the ChainStream API to stream transactions and call the getAccountInfo RPC method. We will set the following limits:

1. Restrict the credential to serve requests from only a single IP (our back-end server).

2. For solana-mainnet, allow only getAccountInfo RPC calls with a maximum of 50 RPS.

3. For ChainStream, allow only the transactionSubscribe method with a maximum of 1 active subscription.

With this configuration, our front-end and back-end services won’t interfere with each other’s rate limits. As we add more services, we can adjust the limits on existing credentials as needed. This approach can also manage limits across development environments, user groups, or deployments.

We’ve consolidated the Solana development stack into a single, cohesive platform, offering unparalleled custom controls for your RPC experience.

Get started quickly today for free, and check out our documentation here.