TRON blockchain development tools guide. Use TronWeb.js, gRPC, web3.py, Hardhat, and Foundry with Chainstack TRON nodes and endpoints.
Chainstack TRON nodes expose four API surfaces over a single node endpoint. Get started with a reliable TRON RPC endpoint, and see the official TRON API reference for the full method list.
API
Endpoint
Use it for
JSON-RPC
/jsonrpc
Ethereum-compatible read operations
Wallet
/wallet
TRON HTTP API — full node operations, including transactions
TRON nodes run in archive mode, which for TRON means the complete block and transaction history from genesis rather than historical state — see Historical data availability.
TRON’s /jsonrpc endpoint provides limited Ethereum compatibility for read operations only — the methods required for transaction submission (eth_sendRawTransaction, eth_getTransactionCount) are not available. Ethereum-native tools like Foundry, Hardhat, and web3.py can read from a TRON node, but they cannot deploy contracts or send transactions directly. For writes, use TronWeb.js with the /wallet endpoint, or compile and test with Foundry or Hardhat and deploy through the hybrid workflow.TRON nodes don’t support WebSocket connections for event subscriptions. To track that capability, follow the feature request for TRON event plugin support.
TRON nodes on Chainstack run in archive mode. For TRON, archive means the complete block and transaction history — not historical state. Unlike EVM archive nodes, java-tron has no state-at-block queries; this is a protocol limitation (java-tron#6289), not a Chainstack one. Billing is independent of the node mode — every TRON request is billed as full (1 RU); see Request units.Available on your node:
Complete block and transaction history from genesis — block and transaction methods accept any historical block, for example /wallet/getblockbynum and eth_getBlockByNumber
Historical TRX balances — /wallet/getaccountbalance and /wallet/getblockbalance with a block_identifier
Not available on any TRON node:
Historical contract or account state, beyond the TRX balance lookups above — eth_getBalance, eth_call, eth_getCode, and eth_getStorageAt accept only the latest block parameter and return QUANTITY not supported, just support TAG as latest for anything else; triggerconstantcontract always runs against current state. java-tron tracks archive-node support in java-tron#6289.
TRON nodes on Chainstack support gRPC for high-performance access. gRPC uses HTTP/2 and Protocol Buffers for efficient binary serialization, making it ideal for high-throughput applications and data indexing.
The TRON proto files define several gRPC services. Here’s what a Chainstack TRON node currently serves:
Service
Status on Chainstack
protocol.Wallet
Available — the full node API: accounts, blocks, contracts, and transaction operations
protocol.Database
Available — block metadata helpers
protocol.WalletSolidity
Available — the solidity node API: read-only access to solidified (confirmed) data
protocol.WalletExtension
Not available yet
protocol.Monitor
Not available yet
Both protocol.Wallet and protocol.WalletSolidity run on the same endpoint and port. Select the one you need by the service (stub) in your generated client, not by a different URL:
Wallet — the latest state and all write operations
WalletSolidity — solidified (confirmed), read-only data
This differs from self-hosted java-tron, which splits the two across separate gRPC ports (50051 for the full node and 50061 for the solidity node); Chainstack routes both through the single :443 endpoint.Calling a service that isn’t served — protocol.WalletExtension or protocol.Monitor — returns the gRPC UNIMPLEMENTED status (Method not found). The same solidified data is also available over the HTTP /walletsolidity API — see TRON methods.
The endpoint supports gRPC server reflection, but the reflection list includes every service in the TRON protos — including ones that aren’t served, such as protocol.WalletExtension and protocol.Monitor. Don’t infer availability from reflection or the proto definitions; the table above reflects actual behavior.
The endpoint supports server reflection for discovery, but to generate typed clients you need the protocol buffer definitions. Get them from the official TRON protocol repository:
where YOUR_X_TOKEN is your authentication token from the Chainstack console.For the full list of available gRPC methods, see the official TRON gRPC documentation.
web3.py performs read operations on TRON through the /jsonrpc endpoint. For contract deployment and transactions, use TronWeb.js.Build DApps using web3.py and TRON nodes deployed with Chainstack.
Use the HTTPProvider to connect to your node endpoint and get the latest block number.
from web3 import Web3web3 = Web3(Web3.HTTPProvider('YOUR_CHAINSTACK_ENDPOINT'))print(web3.eth.block_number)
from web3 import Web3web3 = Web3(Web3.HTTPProvider('https://%s:%s@%s'% ("USERNAME", "PASSWORD", "HOSTNAME")))print(web3.eth.block_number)
where YOUR_CHAINSTACK_ENDPOINT is your node HTTPS endpoint with the /jsonrpc postfix, protected either with the key or password.See also node access details.
Hardhat performs read operations on TRON through the /jsonrpc endpoint. For contract deployment, use the hybrid workflow or TronWeb.js directly.Configure Hardhat to compile contracts and perform read operations through your TRON nodes.
where YOUR_CHAINSTACK_ENDPOINT is your node HTTPS endpoint with the /jsonrpc postfix, protected either with the key or password. See node access details.
Compile your contracts with npx hardhat compile, then deploy using TronWeb.js.