Architecture overview

📘

Prerequisites

• What is TRON

This page explains how TRON's components work together. After reading it, you will understand what layers TRON consists of, how transactions flow into blocks, and which network to choose for your use case.

The three layers

┌─────────────────────────────────────────────────┐
│               Application Layer                 │
│   TronWeb · Trident · TronBox · TronGrid API    │
├─────────────────────────────────────────────────┤
│                  Core Layer                     │
│   TVM · Consensus (DPoS) · Account Management   │
│   Transaction Processing · Resource Model       │
├─────────────────────────────────────────────────┤
│                Storage Layer                    │
│   LevelDB / RocksDB · Block Store · State Trie  │
└─────────────────────────────────────────────────┘

Application layer

The application layer is what developers interact with directly:

• SDKs — TronWeb (JavaScript), Trident (Java).
• Development tools — TronBox for contract deployment, TronIDE for browser-based development
• API infrastructure — TronGrid hosted node service, FullNode HTTP API, JSON-RPC
• Wallet — Tron Eco Wallets browser extension and mobile app

Core layer

The core layer handles consensus, transaction processing, and smart contract execution:

• Consensus — 27 Super Representatives produce blocks every 3 seconds via DPoS
• TVM — the TRON Virtual Machine executes Solidity smart contracts
• Resources — Bandwidth and Energy replace Ethereum's gas model
• Accounts — the account model supports permission management for multi-signature setups

Storage layer

The storage layer persists blockchain state using LevelDB (default) or RocksDB. Node operators choose the backend at startup and can use database snapshots for fast initial sync.

With the three layers in mind, here is how a transaction moves through them — from user signature to final confirmation.

How a transaction flows

1. Create — a user or DApp constructs a transaction (transfer TRX, call a contract, stake, vote, etc.)
2. Sign — the transaction is signed with the sender's private key. The private key should never leave the wallet, backend KMS, or offline signing environment.
3. Broadcast — the signed transaction is sent to a FullNode via HTTP, gRPC, or SDK.
4. Validate — the receiving node checks: signature validity, TAPOS fields (references a recent block hash to prevent cross-chain replay), sender balance, available bandwidth, available energy, and transaction format.
5. Execute — if the transaction calls a smart contract, the TVM runs the contract code and generates state changes; Bandwidth or Energy is deducted from the sender according to the transaction's complexity.
6. Include in block — the current slot SR includes the transaction in the next block — TRON produces blocks approximately every 3 seconds.
7. Confirm — once at least 19 distinct active SRs have each produced a block at the transaction's block height or above, the block is considered solidified (typically ~1 minute on Mainnet). Solidification means the transaction is irreversible. Most DApps can use the first confirmation (~3 s) for UX; exchange deposits and high-value transfers should wait for solidification.

For a hands-on walkthrough, see Send your first transaction.

The flow above works identically on testnets and Mainnet.

Network types

TRON runs three networks for different purposes:

See Networks for endpoints and connection details.

What's next?

Choose your path based on your goal:

• Deep dive into concepts → How TRON works — consensus, resources, and governance
• Start coding → Smart contracts — Solidity development on TRON
• Coming from Ethereum? → TRON vs Ethereum — side-by-side comparison for EVM developers

---

Related resources

• Getting testnet tokens — request free TRX and TRC-20 test tokens
• Connect to the TRON network — set up TronWeb or Trident and pick an endpoint
• Networks — full configuration for Mainnet, Shasta, and Nile