How to get a Tron RPC node: public vs private explained

Need to decide between public and private Tron RPC? In this guide, we will explain the trade-offs. We will show how tenancy (Global vs Dedicated) affects performance. We will also help you quickly set up a private Tron RPC node.

If you’re shipping on Tron, your first fork in the road is simple. You grab a public RPC URL and start reading data. Or, you spin up a private endpoint for steadier writes and predictable latency. If your traffic is light and occasional rate limits don’t bother you, a public node is enough.

But if you need consistent throughput, authenticated access, and fewer surprises under load, private is the obvious choice. So, the decision comes down to how much control you need over performance and access. To understand why that choice matters, we will map the trade-offs and point you to both options so you can make the right call.

What is a Tron node?

A Tron RPC node is just the server that links your app to the Tron network. It keeps a local copy of the chain, verifies new blocks, and relays transactions. On top of that, it exposes RPC methods so your scripts, wallets, or services can pull blockchain data or push signed transactions. Most of the time, you won’t think about the node itself — you’ll just point your app at a Tron RPC URL and start talking to it over HTTP.

Historically, the stack distinguished between:

• Full Node — tracks every block and transaction, serving the core HTTP APIs.
• Solidity Node — served data from finalized blocks.

Today, you’ll still see the namespaces reflected in APIs: /wallet (latest state) and /walletsolidity (confirmed state).

At the protocol layer, Tron runs delegated proof of stake with 27 super representatives (SRs) elected by TRX holders to produce blocks and secure the chain. Running as an SR requires a configuration file, suitable hardware, and a super representative account. Meeting the network’s hardware requirements is essential if you plan on actually starting the node yourself. Most builders don’t go that far; they either connect to a hosted Tron RPC endpoint or run their own non-producing node for development, indexing, or analytics.

When you connect through a Tron RPC node, the jobs usually fall into three buckets:

• Read — pull balances, scan transaction history, or scrape recent blocks and contract events when you’re building analytics.
• Write — deploy a contract or send a transaction that you’ve signed locally with a private key, then broadcast it through the node.
• Observe — watch latency spikes, error codes, or connection drops so your app doesn’t stall in production.

On the surface, it’s just an endpoint. Underneath, the node exposes the APIs you’ll hit every day. Here are some API surfaces you’ll encounter:

• HTTP — /wallet and /walletsolidity endpoints for native Tron operations.
• EVM-compatible JSON-RPC — exposed at /jsonrpc for EVM-style workflows (coverage differs from Ethereum).
• gRPC — high-performance, strongly typed access, including transaction broadcast.

So your RPC choice doesn’t change consensus, but it does affect how consistently you see fresh state and how predictably your writes settle under load.

Public vs private Tron RPC URL

Public Tron RPC

Public Tron RPC endpoints are community- or foundation-hosted URLs available to use for those who do not want to set up their own node. These endpoints come in handy when doing quick experiments, reading balancers, or testing contract calls.

The big trade-off here is that you have to share the same pool with everyone else, which means getting rate limits, variable latency, and the occasional timeout. However, if your workload is light and you don’t mind occasional retries, public RPC will do the job.

Private Tron RPC

A private Tron RPC endpoint gives you isolation and control. You authenticate requests, keep environments separate, and get a steadier latency envelope under load because you’re not competing with a public pool. This matters once you start submitting transactions regularly, streaming events for indexing, or running flows where flakiness impacts users or strategies.

So, when predictable performance, access controls, and clearer observability become requirements, private is the right move.

If you’ve reached the point where private RPC is the right choice, you then decide how much tenancy you need. On Chainstack, that means choosing between Global and Dedicated Nodes.

• Global Nodes are multi-tenant but still give you your own protected endpoint, balanced across regions. They’re quick to start, affordable (from $0/month), and work well if you need elastic capacity without the overhead of running hardware yourself.
• Dedicated Nodes are single-tenant. You’re not sharing performance with anyone else, so they’re better suited for workloads that need guaranteed throughput, reliability, or compliance-grade isolation.

Both options let you skip the work of compiling the Tron source code, setting up a configuration file, or trying to run your own super representative setup. You just create the node in the console, grab the RPC URL, and you’re ready to integrate.

Choosing between public and private Tron RPC

A quick rule of thumb to see which option fits your workload:

How to get a public Tron RPC URL

These are hosted by the Tron Foundation and community and don’t require you to run a node yourself:

• Tron mainnet RPC:
  https://api.trongrid.io
• Tron testnet (Shasta) RPC:
  https://api.shasta.trongrid.io
• Tron Nile testnet RPC:
  https://nile.trongrid.io

How to get a private Tron RPC URL

You can provision a private Tron RPC node directly from the Chainstack console. Setup takes only a few steps:

1. Log in to the Chainstack console.
2. Create a new project (or reuse an existing one).
3. Select Tron, then choose the tenancy model that fits your workload:
   • Global Node — multi-tenant, quick to start.
   • Dedicated Node — single-tenant, isolated performance and throughput you can count on, plus the compliance-grade separation some teams need.
4. Copy your Tron RPC URL and API key from the console.

With that, your private Tron RPC endpoint is live. You hit it the same way you’d hit a public RPC URL — from your app, wallet, or script — but here you’re behind authentication, with access rules in place and latency that holds up when traffic spikes.

Working with Tron tooling

Once you have a Tron RPC node, the next step is plugging it into the tools you use to build, test, and deploy. Tooling bridges your endpoint with familiar developer workflows, so you don’t have to work directly with raw RPC calls.

API surfaces

Chainstack Tron nodes support all three RPC namespaces:

• /jsonrpc — Ethereum-compatible JSON-RPC methods.
• /wallet — latest state queries.
• /walletsolidity — confirmed/finalized state queries.

Note: Tron nodes are full only (non-archive), so some deep-history methods are not available. WebSocket event subscriptions are also not supported at this time.

SDKs and frameworks

You can connect your Tron RPC endpoint to common Web3 libraries:

• TronWeb.js — native JavaScript SDK for sending transactions, reading balances, and contract interaction.
• web3.py — Python interface for DApps; connect via HTTP provider using your endpoint.
• Hardhat, Foundry, Remix — EVM-compatible frameworks can be configured to use a Tron RPC URL for deploying and testing smart contracts.

Wallets and IDEs

For contract testing and deployment, you can also route through:

• TronLink or Trust Wallet — Tron-native wallets with pre-configured RPC endpoints.
• Remix IDE — interact via MetaMask (bridged tokens only) or TronLink for native TRC-20s.

Why tooling matters

Without tooling, you’d be crafting raw HTTP requests against your RPC URL. Toolchains like TronWeb or web3.py abstract that into readable functions and scripts, making it easier to manage accounts, compile contracts, broadcast transactions, or even fork the network for local testing.

For more info, check out our documentation.

How to add Tron RPC URL to MetaMask

As of recent, MetaMask doesn’t support the Tron mainnet or testnets anymore. Tron runs on the TVM, which differs from Ethereum’s EVM in address format, gas model, and RPC design. Because of that, Tron RPC URLs aren’t compatible with MetaMask.

For native TRX or TRC-20 tokens use a Tron-compatible wallet like TronLink and Trust Wallet. These wallets ship with pre-configured endpoints — you don’t need to (and can’t) add a custom RPC URL manually.

Wrapping up

The choice between public and private Tron RPC depends on what you’re building. Public is fine for light reads or early tests. For contract work, indexing, or anything that needs stable performance, go with private.

Once you’ve got your endpoint, everything else — TronWeb, web3.py, Hardhat, Foundry — plugs in on top. That’s where you write, test, and ship.

The easiest way to know is to try it. Create a Tron RPC endpoint and plug it into your stack.

FAQ