Track 0: Complete beginner

This track is a starting point for learning about TRON. It is designed for developers who are new to TRON or to blockchain technology.

What you will learn

The track begins with core objects such as accounts, addresses, tokens (digital assets that represent value or rights onchain), blocks, and transactions. It then introduces testnets, resources, and transaction confirmation, connecting these concepts through one TRX transfer.

The throughline is to complete and verify your first TRX transfer on the Shasta Testnet. You will prepare a test account, obtain test TRX, understand the signature and Bandwidth required for the transfer, submit the transaction, and save its transaction ID (txID) to query its execution result and solidification state.

Follow the hands-on task in each stage to complete the same transfer progressively. The entire exercise uses test accounts and test TRX; it does not involve assets with financial value.

You do not need prior blockchain or TRON knowledge. Review the stage overview first, then work through the track in order. Return to the recommended reading whenever a term or operation is unfamiliar.

Track overview

Before you begin

This track has no blockchain-knowledge prerequisite. To complete the hands-on work, you need to be able to run simple terminal commands and prepare a Shasta-only test account. Do not reuse a Mainnet account's private key or mnemonic, share the test secret with anyone, or store it in public documentation or version control.

The track explains the core knowledge required at each stage and shows how the pieces fit into one TRON transaction. For complete commands, code, and operational steps, follow Send your first transaction.

Track stages

1. Identify the core TRON objects

Before making your first transfer, understand the relationship between accounts, addresses, tokens, transactions, and blocks. An address identifies an account, while the corresponding private key authorizes transactions. TRX is the native token of the TRON network. A transaction is an onchain instruction issued by an account, and a block records transactions that the network has included.

These objects exist on a specific network. Mainnet carries assets with real value; Shasta is the testnet used in this track. Account state and transaction history are separate across networks. All TRX obtained and sent later in this track is Shasta test TRX with no financial value.

Recommended reading

1. What is TRON — Key features and TRX

   Read “Key features” and the following “TRX: the native token” section to understand block production, resources, smart contracts, and the basic role of TRX. You do not need to follow the advanced links at this stage.

2. Architecture overview — The three layers and transaction lifecycle

   Continue through “Transaction lifecycle” to see how the application layer submits a signed transaction and how nodes validate, include, and solidify it. Stop before “Three networks.”

3. Networks — Shasta Testnet

   Check only the Shasta HTTP endpoint, faucet, and block explorer. Mainnet node operations, Nile, and private networks are outside the first-transfer task.

Stage task

Using the transfer you will make later, map the sender account, recipient address, TRX, transaction, block, and Shasta network. Do not send anything yet. The goal is to identify which information comes from an account, which information becomes public onchain, and why the exercise belongs on a testnet.

Before preparing test accounts: Confirm that you can distinguish an account, an address, and a wallet, and that Shasta and Mainnet serve different purposes. In the next stage you will create an account used only on Shasta.

2. Prepare test accounts

A private key controls an account, while an address identifies the account and receives assets. Wallet software can generate and manage keys, display onchain balances, and request transaction signatures, but the assets remain recorded onchain rather than inside the wallet. Anyone who obtains a private key or mnemonic can control the corresponding account, so basic key-safety rules still apply to test accounts.

Your first transfer requires a sender account and a recipient address. The sender needs enough test TRX; the recipient lets you verify the result. Obtain test TRX from a Shasta faucet for learning, development, and debugging only.

Recommended reading

1. Accounts and keys — Address format and key pairs and Wallets and accounts — How wallets relate to accounts

   In the accounts page, read “Address format” and “Key pairs.” In the wallet page, understand that a wallet manages keys rather than holding assets, then review the download, backup, and phishing guidance under Wallet security best practices.

2. Getting testnet tokens — Faucet websites

   Follow the “Faucet websites” instructions for Shasta and read the “Key constraints.” Use alternatives such as TronFAQBot only if the website faucet is unavailable.

Stage task

Follow the account-preparation steps in Send your first transaction. Create an account used only on Shasta, record its Base58Check address, and protect the private key. Obtain test TRX from the Shasta faucet, then run Query TRX balance and resources to confirm the sender balance and record the available Bandwidth.

Prepare a second test-only recipient account and record its address separately. A newly generated address might not have an onchain account state yet. Sending its first TRX also activates the account, so the sender must cover the account-creation fee and the related Bandwidth cost. TRON networks use the same address format, so continue using Shasta endpoints for all queries and broadcasts. Use the private key only for local signing; never paste it into a website, chat, or repository.

Before learning transaction cost: Confirm that the selected network is Shasta, the sender has received test TRX, and the recipient address is ready. The next stage uses these values to check the amount, signature, and resource consumption.

3. Understand resources and transactions

A TRX transfer includes the sender address, recipient address, and amount, and it must be signed by the sender. The protocol represents the amount in sun, where 1 TRX equals 1,000,000 sun. A signature proves that the sender authorized the transfer; the private key itself is never sent with the transaction.

A standard TRX transfer to an activated account primarily consumes Bandwidth, not the Energy used for smart-contract execution. An account can use free Bandwidth, resources obtained through staking, or delegated resources. If Bandwidth is insufficient, the network burns TRX from the account to pay the resource cost. A transfer to an unactivated address also incurs account-activation costs determined by the current chain parameters.

A transaction moves through construction, signing, broadcast, block inclusion, and solidification. Broadcast acceptance only means that a node accepted the transaction for further processing; it does not prove block inclusion or solidification.

Recommended reading

1. Resource model — Bandwidth and Energy

   Focus on why a standard TRX transfer consumes Bandwidth and how free allowance, staking, delegation, and burned TRX can cover the cost. Read the other resource sections when you enter a smart-contract or governance track.

2. Transactions — Transaction lifecycle

   Read the four stages covering creation and signing, broadcast and validation, block inclusion, and solidification. Leave transaction structure, expiration, TAPOS, and APIs until you need to construct or troubleshoot transactions manually.

Stage task

Before sending, record the network, sender, recipient, and transfer amount, then convert the TRX amount to sun. Run Query TRX balance and resources to check the sender's TRX balance and Bandwidth and to verify the sun ↔ TRX conversion. Check whether the recipient is activated, then confirm that the sender can cover the transfer, resource cost, and any account-activation cost. Signing must use the sender's test private key locally.

Do not treat a broadcast response as the completion criterion for this stage. You should be able to explain who authorizes the transfer, which resource it consumes, and why the application must continue querying chain state after broadcast.

Before sending the transaction: Recheck the network, sender, recipient, and amount, and explain the role of the signature and Bandwidth. The next stage constructs, signs, and broadcasts this same transfer.

4. Send and verify the transaction

Follow the tutorial to construct a TRX transfer, sign it locally with the test key, and broadcast the signed transaction to Shasta. Save the returned txID immediately; it identifies the transaction for every later query.

Obtaining a txID is not the end of the workflow. Check whether the transaction entered a block, whether it executed successfully, and whether the block became solidified. Verify that the sender, recipient, amount, result, and resource consumption match what you recorded before sending.

Recommended reading

1. Send your first transaction — Complete Shasta walkthrough

   Complete Steps 1 through 5 in order and save the txID. Read the Trident example only if you use Java; review the lower-level flow after the operation succeeds.

2. TRONSCAN — Web interface

   Learn to search by txID and verify status, amount, block, and resource usage on the detail page. The API, MCP, Skills, and CLI sections are not required at this stage.

3. Send your first transaction recipe

   If the account and test TRX are ready, run the code at the top of the page to construct, sign, and broadcast the transfer. Then review “Verify on TRONSCAN” and “Common errors.” The full tutorial already supplies the conceptual background.

Stage task

Complete a Shasta TRX transfer by following Send your first transaction and save the returned txID. Search for that txID in Shasta TRONSCAN, then verify the sender, recipient, amount, block, and execution result.

If you need to determine execution and final solidification through node APIs, first read Confirmation semantics so that you do not confuse broadcast acceptance with final success. For this beginner track, Shasta TRONSCAN is the primary verification interface. Keep using the same txID throughout the query process.

Record the txID, execution result, block, and resource use, and compare account balances before and after the transfer. If the transaction is temporarily unavailable, continue checking the original txID instead of sending another payment. If it remains absent beyond the expected wait, follow Broadcast succeeded but the transaction never appears on chain.

Verify the result: Confirm that Shasta contains one successfully executed and solidified TRX transfer. Your record should contain the txID, sender, recipient, amount, execution result, and resource consumption.

Next steps

After the first transfer, use TRONSCAN — blockchain explorer and data platform to inspect other accounts, blocks, and transactions, or read the Token standards overview to compare TRX, TRC-10, TRC-20, TRC-721, and TRC-1155.

This track establishes the foundation shared by the other developer roles. Return to Tracks by role and choose the wallet, DApp, smart-contract, node, or other track that matches your goal.

If you completed only part of the workflow, retain the test address, current balance, and any recorded txID, then resume at the relevant stage later. Never put the test private key or mnemonic in your learning record.

If you are still blocked, share documentation feedback. Include “Track 0,” the current stage, the steps already completed, and the actual error message. Never include a private key or mnemonic.