Abuse prevention

How Triton prevents your RPC endpoints from being abused.

We take abuse prevention seriously. The endpoints and tokens that you receive from us should not be easy for others abuse, and if they are then it is crucial for us that this does not cause disruption to legitimate users of your app.

Furthermore, we do not want abusive traffic to cause additional billing for services so that you can rest assured that you are not paying for someones latest iteration of a brute force trading bot.

To achieve this, we work together with our customers to both track usage and restrict or limit abusive traffic. We consider this a core feature of our loadbalancers and we have been developing filters and other approaches over several years of running both high demand public endpoints as well as private and dedicated endpoints for customers.

First of all - we do not require you to deploy proxies, CloudFlare workers or any other tools in front of your RPC endpoints. In fact, these tools bring multiple disavantages: centralization, Man-in-the-Middle security concerns and more see Proxying for more details.

An important step is tuned Rate Limits. Our goal is that our rate limits should be adjusted so that they can service any legitimate user of your apps, but do not encourage or enable abusive traffic from external parties.

We also apply a segregation between endpoints, which are RPC urls such as (https://my-end-point-abcd.mainnet.rpcpool.com) that you integrate into your dApp code versus tokens (abcd-1234-xyze-eeee), which you use for your backend services and bots. Tokens should never be exposed publicly or in your dApp source code. When you login to our customer site (https://customers.triton.one) you will see both tokens and endpoints listed and you pick which one to use based on the specific application you are deploying RPC for.

For endpoints (i.e. without the token added), we request you to provide a list of web origins that we should allow traffic from. This helps us track and identify legitimate traffic. While web origins can (and have been spoofed) they provide a good first line of data gathering for finding legitimate requests.

For certain applications, such as mobile apps or desktop software, we understand that a token may be required to be embedded in your application. Please contact [e-mail] if you have a use case like this and we can help you get setup in the appropriate way.