Securing your Triton RPC tokens and endpoints

How to protect yourself - and your RPC bill - from bad traffic and leaked credentials

TL;DR

• With metered pricing, bad traffic has a direct cost – leaked RPC tokens mean someone else’s traffic shows up on your bill
• Triton endpoints support two authentication methods: secret tokens for backend use, and allowed origins for frontend use
• Never expose your RPC token in frontend code or commit it in plain text to a git repo, public or private
• Use allowed origins for frontends; keep tokens server-side only
• Treat your RPC token with the same care as you would a database password or private key
• Contact Support in the Customer Dashboard immediately if you suspect a token leak; we will work with you to rotate it

Why it matters more now: usage-based pricing

This year, we moved from flat-fee billing to metered pricing. This is genuinely better for the vast majority of builders, as it rewards good engineering. Teams that optimise their request patterns and keep their endpoints secure pay less as a result. 

But if your token leaks and an external actor starts hammering your endpoint, that traffic appears on your bill. It’s not hypothetical; we’ve already seen cases where teams discovered leaked tokens through unusual billing activity. 

The good news:

1. If you’re on a subscription plan, you’ll never be cut off because of overages, and we’ll always work with you on a reasonable outcome for your invoice
2. If you’re on a pay-as-you-go plan, your credits will act as a natural cut-off point for abuse
3. Protecting yourself is straightforward

Tokens vs allowed origins: understanding the difference

Triton endpoints support two authentication methods, each designed for a different context. Using the wrong one for your use case is one of the most common mistakes we see. 

Secret tokens: for backend use only

Your RPC token is appended directly to your endpoint URL:

https://<your-endpoint>.rpcpool.com/<your-secret-token>

This format is designed for server-side use only: Rust backends, Node.js servers, scripts, trading bots, and gRPC clients. When you authenticate via a token, origin validation is intentionally disabled, because there’s no meaningful “origin” in a server-side context. 

Do not put your token in frontend code. If your token is embedded in a browser-facing app, anyone who opens DevTools can copy it. Once it’s out in the wild, it can be used by anyone to make requests that land on your bill.

Allowed origins: for frontend and dApp use

For browser-based applications, use the bare endpoint URL (without a token) and configure allowed origins in your Triton Customer Dashboard. We’ll then only serve requests from the domains you’ve explicitly whitelisted.

https://<your-endpoint>.rpcpool.com/

This is the right path for dApps, wallets, and any frontend talking directly to the RPC. Traffic from these endpoints is rate-limited by IP address and origin domain. Our load balancers also filter out malformed requests at the edge – anything that doesn’t conform to valid JSON-RPC specifications is denied before it reaches your nodes. For more persistent abuse patterns, advanced fingerprinting identifies and blocks actors attempting to spoof credentials or origins.

One thing worth noting while you’re in your dashboard: when you open an endpoint’s allowed origins list, you may see __blocked.rpcpool.com listed there. Don’t remove it. This is a system origin that signals your endpoint is closed to unauthenticated requests; it will only accept calls made with a valid token. If you remove it and leave the allowed origins list empty, your endpoint becomes fully open: anyone can query it without a token and any traffic they generate lands on your bill.

A quick note on Cloudflare and similar proxies: using them creates a man-in-the-middle. By design, your proxy decrypts all traffic between your users and our servers. They also break our GeoDNS and Anycast routing and disable our abuse prevention systems, forcing us to partially disable protections on your endpoint. When you place a proxy in front of our service, you assume full responsibility for any security incidents or data leaks that may result. We strongly advise against proxying (Learn more). 

Always use https

No matter which method you’re using, always use https. Even though our endpoints technically work using unencrypted connections (http port 80), if you use them, your authentication data is vulnerable to network snooping on the open internet.

What to do if your token leaks

If you suspect your token has been exposed – maybe it ended up in a public GitHub repo, a frontend bundle, a config file committed to version control, or a shared message – act quickly!

1. Contact support immediately via the chat in your Customer Dashboard. We’ll rotate your token and issue a new one. The old token becomes invalid as soon as the new one is issued.
2. Check your billing dashboard for any unusual traffic spikes since the suspected leak. The RPC Metrics tab shows request volume and method breakdown; look for unfamiliar methods or request patterns. 
3. Audit your codebase. Search for the token string across all repos, config files, CI/CD pipelines, and environment files. GitHub’s secret scanning and similar tools can help automate this. 
4. Review your allowed origins. If you were relying on origin validation, ensure the list is tight and doesn’t include wildcard or overly broad entries. 
5. Rotate any related credentials. If the same token was reused across environments or stored alongside other secrets, treat those as potentially compromised too. 

Endpoint hygiene: a few things worth checking today

Beyond token management, there are configuration habits that will meaningfully reduce your exposure:

• Disable endpoints you’re not using. If you provisioned an endpoint for a one-off backfill job and it’s still active, it’s an open door. Clean up unused endpoints in your dashboard. You can disable endpoints in the same way you added them.
• Use prepaid credit as a natural spend cap. If you’re on a pay-as-you-go plan, you can treat your deposits as a built-in check and balance on your system. Don’t forget to set up alerts when your balance gets low. You can do this in the Billing tab of your account.
• Monitor your RPC metrics regularly. Your metrics dashboard shows request volume, method breakdown, and traffic patterns. Spikes in methods you don’t use, traffic at unusual hours, or a sudden jump in bandwidth are all worth investigating. 
• Don’t log your tokens. Tokens frequently end up in application logs, error traces, and observability pipelines. If a log aggregator is storing your full endpoint URL with the token appended, that’s a credential exposure just waiting to be discovered. Treat your RPC token with the same care as you would a database password or a private key. 
• Separate tokens per environment. Use distinct tokens for production, staging, and development. Your Triton account is set up with both mainnet and devnet tokens. This limits the blast radius if one is leaked - you can rotate a single environment without touching prod. 

Upcoming changes to how we handle abusive traffic

We’re rolling out two improvements to our abuse mitigation stack that are worth noting, in case you see anything unexpected in your error logs. 

Earlier connection drops for repeat offenders

We’re deploying new mitigations that act earlier in the stack against sources generating large volumes of 403 or 429 errors. Previously, those sources would continue to receive HTTP error responses for every request. But under the new behaviour, once a source crosses a threshold, connections from that source IP will be dropped silently rather than receiving a response. 

In your logs, this will show up as either:

• a simpler static HTTP error code message coming straight from our network edge device
• a network-level failure (“network connection failed” or similar) instead of an HTTP error code.

If you see this pattern and your traffic is legitimate, the fix is almost always the same: ensure your token is correctly configured and that your allowed origins are set up properly for frontend traffic. It will also help to back off for at least 1 min after fixing your client, so the block can resolve itself.

Stricter filters on tokenless backend traffic

We’re also adding additional traffic filters that will return 403 errors to requests that appear to originate from a backend environment but arrive without a token. 

This should have no impact on legitimate traffic – backend services should always be using a token. However, if you do see a rise in 403s, check whether any backend services have been misconfigured to use the origin-based / frontend auth instead. This has a high probability of being blocked by our filters.

Security on Solana moves at the speed of the chain

Be sceptical of direct messages, “recovery” links, and unofficial announcements, especially in the days following a major exploit – including impersonators claiming to be Triton support.

Focus on what you can control:

These steps aren’t complex, but they’re worth doing now rather than after something goes wrong. 

If you have questions about your setup or want help locking down your configuration, open a support chat from your Customer Dashboard, and we’ll take a look with you.

Want to understand how Triton's metered pricing works? Read The end of the black box: Triton's new RPC pricing.

Hitting errors or unexpected behaviour? See our RPC error codes & troubleshooting guide.

For Triton's full security and abuse prevention documentation, visit docs.triton.one.