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, install a currently supported Node.js LTS release and npm, and use a terminal that can run Bash or Zsh commands. Stage 2 creates two Shasta-only test accounts. Do not reuse a Mainnet account's private key or mnemonic, share a 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 — Application layer

   Begin with how wallets and applications connect to nodes through SDKs or APIs. Stage 3 covers broadcast, block inclusion, and solidification together.

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

Complete Steps 1 through 3 of Send your first transaction: install the specified TronWeb version, generate Shasta-only sender and recipient accounts, and record both Base58Check addresses. Protect both private keys and request test TRX only for the sender. Then run Query TRX balance and resources to confirm the sender balance and record the available Bandwidth.

A newly generated recipient 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 private keys only for local signing; never paste them 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. A broadcast response without a reported error does not prove that the node retained or propagated the transaction, or that the transaction was included or solidified.

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 send the transaction in this stage. After completing the preparation, 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 in the next stage.

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 and sign it locally with the sender's test key. Save the signed transaction's txID before broadcast, then submit that same transaction to Shasta. If the request reports an error or its result is unknown, the original txID remains available for follow-up instead of immediately building another transfer.

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

   Continue with Steps 4 and 5 using the sender and recipient prepared in Stage 2; do not generate new accounts. Read the Trident example only if you use Java, and 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

   The recipe is an alternative implementation of Step 4 in the tutorial. If the accounts and test TRX are ready, you can run its opening code and then review “Verify on TRONSCAN” and “Common errors.” Do not run both sets of sending code for the same exercise.

Stage task

Choose Step 4 of Send your first transaction or the corresponding recipe, and use the two accounts prepared in Stage 2 to make one Shasta TRX transfer. Save the generated txID after signing and before broadcast; do not run both sets of sending code for the same exercise. 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 the broadcast response 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 How should I retry when a transaction cannot be found after broadcast?.

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.