RPC providers – do I need a paid endpoint for burns?

The XXX Tales Burn Bot needs access to a Solana RPC endpoint to read data and send burn transactions. This page explains when the default shared RPC is enough and when it makes sense to plug in your own paid RPC provider.

Short answer

You do not need a paid RPC to test the bot or to run small burns occasionally. The default shared RPC (configured on the backend) is usually fine for:

low to medium volume burns,
test runs and simulations,
projects that are not spamming transactions 24/7.

A dedicated paid RPC endpoint becomes relevant when your project:

handles a lot of traffic or many users in parallel,
needs very reliable and fast confirmations,
wants guaranteed rate limits and SLAs.

What does the “RPC provider” dropdown in the form do?

RPC mode	What happens?	Who should choose this?
Use default shared RPC	The burn bot uses a backend-managed RPC endpoint (e.g. a shared provider or cluster). You don’t have to configure anything. The project shares capacity with other projects on the same infrastructure.	Recommended starting point Ideal for early-stage projects, pilots, and occasional burns.
Use my own paid RPC endpoint	You provide a full RPC URL (and optionally an API key) from a provider such as Helius, QuickNode, Triton, or similar. The burn bot will use your endpoint for read and write calls related to your project.	For serious / high-volume projects Choose this if you need strong reliability, throughput, and your own quota.

The dropdown does not change how the burn logic works – only which RPC endpoint the bot uses to talk to the Solana network.

What do I have to enter for a paid RPC provider?

1. RPC URL (required)

This is the HTTPS endpoint from your provider, for example:
https://example-solana-mainnet.rpcprovider.com/your-project-id
Paste the full URL exactly as given in your provider dashboard.

2. API key / token (optional, but common)

Some providers include the API key directly in the URL, others give you a separate key. If the form has a separate API key field, paste it there. The burn bot will attach it as required by your provider.

3. Rate limits and costs

You are responsible for any costs associated with your paid RPC plan. Very high burn volumes can generate many calls – make sure your plan and rate limits are sufficient.

Risks of using only public or underpowered RPCs

Requests might be throttled or blocked during high load.
Transactions can be slower to confirm or occasionally fail.
Your users may experience inconsistent behaviour at peak times.

For small projects this is usually acceptable. For larger projects it’s better to invest in a dedicated RPC setup.

How to decide quickly

Choose “default shared RPC” if…

you are in pilot or test phase,
your community is still small,
you only run burns from time to time.

Choose “own paid RPC” if…

you expect heavy traffic or automated bots,
burns are part of a bigger trading / utility loop,
you need predictable performance and uptime.