Track 3: DApp developer

This track is a starting point for building DApps on TRON. It is designed for developers who want to understand progressively how a smart contract and browser frontend work together.

What you will learn

The track uses one application to introduce the main parts and development order of a TRON DApp: testing and deploying a smart contract, requesting user authorization through TronLink, and querying transaction results and contract events.

The throughline is a decentralized library. Book owners list books and set a daily price; other users browse the catalog and pay test TRX through TronLink to rent a book. The application connects contract logic, resource cost, wallet authorization, frontend calls, and onchain state handling in one flow.

Follow the hands-on tasks to build a basic DApp prototype on Shasta. The prototype teaches the development workflow. Production architecture, security review, and release readiness remain separate work for the actual project.

You do not need to understand every concept in advance. Review the stages, complete them in order, and return to the recommended reading when a term or error becomes relevant.

Track overview

Before you begin

You should understand basic accounts, transactions, and testnets. If these are unfamiliar, begin with Track 0: Complete beginner. You also need JavaScript and HTML/CSS skills and the ability to read and modify a simple Solidity contract. Developers coming from Ethereum should focus on TRON vs Ethereum — Core comparison, Fee model: the biggest difference, and Migrating smart contracts.

The track explains the purpose and acceptance criteria of each stage. Build a Web3 app supplies the library contract, automated tests, Shasta deployment checks, direct TronLink frontend, transaction-result handling, and event synchronization. The other links provide the concepts, interface semantics, and security guidance needed at each stage.

Run deterministic contract tests in an isolated local environment. Use Shasta for every public-network account, endpoint, deployment, call, and result query. Supply the deployer key only to a local deployment tool or controlled signer; end-user authorization belongs in TronLink.

Track stages

1. Understand DApp interaction and prepare the environment

A DApp interaction usually starts in the browser. TronLink supplies the current account and network and asks the user for authorization and signatures. TronWeb helps the frontend construct calls and communicate with a node. The smart contract executes onchain logic. Understanding this path separates unsigned reads, user-authorized writes, and deployments performed by a deployment account.

This track uses TronBox for compilation, testing, and deployment and Shasta as the public test environment. The deployer private key is available only to the local deployment tool; TronLink authorizes end-user transactions. These are different responsibilities.

Recommended reading

1. Smart contract introduction — What is a smart contract

   Read through “Limitations” to understand the contract's role in a DApp. Return to TRON-specific capabilities only if the application needs them.

2. DApp wallet integration — Two integration approaches

   Distinguish TronWallet Adapter from direct TronLink integration. The library walkthrough uses direct integration; production projects can choose an adapter when multi-wallet discovery matters.

3. Smart contract interaction — Read vs write at a glance

   Use the table to distinguish reads, writes, signatures, and resources. Leave implementation details until Stage 4.

4. Quickstart — Configure the Shasta network

   Verify TronBox's Shasta configuration and environment-based key injection. Compilation and deployment come later.

Stage task

Follow Build a Web3 app — Prerequisites and Create the project to initialize the project. Prepare a local test network entry and Shasta configuration, but do not deploy yet. Supply the deployer key only through a controlled environment; never place it in source, frontend code, or version control.

Before contract development: Confirm that the TronBox project is initialized and retains separate local-test and Shasta deployment configuration.

2. Develop and test the contract

Contract development starts by translating application requirements into verifiable logic and defining reads, writes, business rules, and tests. The library contract implements only its core behavior: owners list books, users query the catalog and pay a daily price, and the contract records the renter and expiration. Queries do not modify state. Listing and renting do; renting also transfers test TRX to the owner.

Define rules for missing books, invalid rental periods, incorrect payment, and duplicate rental while a book remains unavailable. Events leave onchain records for listing and rental. Automated tests verify the normal workflow and these failure boundaries before a public deployment.

Recommended reading

1. Solidity on TRON — Compiler version support and Writing and compiling — Compile

   Verify the Solidity version, optimizer configuration, and generated artifacts. Skip unused TRC-10, staking, and voting extensions.

2. Smart contract security — Reentrancy and Sending TRX to a contract that rejects it

   Review state ordering around the rental payment and the failure case where the owner is a contract. Select other attacks only when the implemented capabilities make them relevant.

3. Events and logs — Defining and emitting events

   Verify the parameters and emission point for listing and rental events. Off-chain consumption comes in Stage 5.

4. Build a Web3 app — Test the contract locally

   Use the walkthrough's test file to check listing, retrieval, payment delivery, events, and the documented failure paths.

Stage task

Complete three tasks in the library project:

1. Implement listing, querying, and rental from Build a Web3 app — Write the smart contract.
2. Follow Test the contract locally to start TRE and run the supplied tests for listing, querying, payment delivery, events, incorrect payment, a nonexistent book, an out-of-range rental period, and duplicate rental.
3. Add tests for the expiration boundary, an owner contract that rejects TRX, and a reentrancy attempt.

Retain the source, compiler configuration, test code, and result after running the suite against the isolated local network.

Before deployment: Preserve the tested source and compiler configuration. Stage 3 deploys exactly that material to Shasta. Keep the tests and results for pre-deployment review.

3. Deploy and verify on Shasta

Moving from local tests to an onchain deployment means deploying the tested contract to a public testnet and verifying that the deployed result supports later calls. Passing tests proves behavior only for covered inputs; it does not verify the deployment transaction or deployed bytecode.

Continue using the same source and compiler settings to obtain a Shasta contract address and observe public-testnet resources and execution results. Deployments and writes consume Bandwidth and Energy, and available resources plus fee_limit affect completion. Broadcast acceptance alone does not prove successful execution.

Recommended reading

1. Resource model — Bandwidth and Energy and FeeLimit and Energy cost — What fee_limit actually does

   Understand the resources used by deployment and writes and the role of fee_limit as a budget cap. Read the full dynamic-Energy strategy only when cost behavior requires it.

2. Deploying — Preparation and Confirming a successful deployment

   Verify the deployer, network, artifacts, and result. If the page demonstrates TronIDE, reuse its fields and acceptance semantics rather than its tool-specific steps.

3. Smart contract interaction — Read vs write at a glance and Contract verification — Step-by-step verification

   Complete one read and one write independently of the frontend, then verify with the exact source, compiler, and optimizer configuration used for deployment.

Stage task

Follow Build a Web3 app — Deploy to Shasta with the tested source and configuration. Save the deployment txID and contract address.

Continue with Inspect and verify the deployment to check the receipt, perform one read and one write, and verify the source on Shasta TRONSCAN.

Before frontend integration: Record the Shasta contract address, network, deployment txID, solidified receipt, source-verification result, and basic read/write check. Stage 4 uses that address to create the contract instance.

4. Connect users through TronLink

Frontend integration focuses on safe contract reads and write submission: wallet connection, account and network checks, and the distinction between reads and state-changing transactions.

Use the Shasta address from Stage 3 to create a contract instance and display the catalog. When connecting TronLink, read the current account and network. Listing and renting change state and require user confirmation. Handle a missing wallet, rejected authorization, the wrong network, and account or network changes.

Reading the catalog does not require a signature. Listing and renting do. Save the txID returned for every write, but never display business success based only on submission.

Recommended reading

1. DApp wallet integration — Direct TronLink integration

   Continue through the window.tron provider, capability summary, and Chain ID parameters. Evaluate TronWallet Adapter separately when multiple wallets must be supported.

2. Smart contract interaction — Read methods and Write methods

   Use the TronWeb examples needed by the frontend and distinguish .call() from .send(). Raw HTTP examples are not prerequisites for this browser flow.

Stage task

Follow Build a Web3 app — Create the frontend page and Connect TronLink and call the contract. Implement catalog browsing, book listing, and paid rental with the saved Shasta contract address. Cover wallet absence, authorization rejection, network mismatch, and account or network changes.

Persist the original txID and a minimal action summary for every write under a key scoped to network, contract, and account. While a write remains unresolved, do not create another listing or rental payment for the same action.

Before synchronizing chain state: Confirm that the frontend retains every write txID and does not show submission as business success. Stage 5 uses those identifiers to recover and verify results.

5. Synchronize transaction and contract state

After submission, development shifts to determining the result and keeping the UI consistent with onchain state. A txID begins confirmation; it does not finish it. Node acceptance is not block inclusion, and block inclusion is not successful contract execution. Query execution and solidification before displaying success, failure, or unknown.

Use a receipt for the current user's write. Use events to discover listings and rentals triggered by other accounts. After an event appears, reread contract state so the chain remains the source of truth. Event consumption must also handle duplicate results, pagination, cursors, and restarts.

Recommended reading

1. Confirmation semantics — State semantics quick reference

   Continue through “Transaction body is not execution receipt” and “Latest head is not solidified state” to distinguish wallet rejection, node acceptance, execution, solidification, and unknown results.

2. Broadcast and RPC errors — Broadcast succeeded but the transaction never appears on chain and Smart contract errors — REVERT

   Use these for insufficient resources, REVERT, RPC timeout, and unknown results. Keep querying the original txID; do not create another listing or payment while its outcome is unknown.

3. Listen to contract events and Events and logs — Patterns for off-chain consumption

   The library walkthrough already queries BookAdded and BookRented and rereads contract state after a new event. The recipe adds pagination, cursor, and persistent-deduplication guidance.

Stage task

Extend the walkthrough's transaction-result and event handling:

1. Persist the original txID immediately after .send() and restore it after reload for the same Shasta network, contract, and account.
2. Follow Update the page from transaction results to query the Shasta solidified receipt. Treat only an explicit SUCCESS as success; keep empty results, HTTP errors, and timeouts unknown.
3. Follow Synchronize state through contract events for BookAdded and BookRented, then add pagination and durable cursor and deduplication storage.
4. Run the workflow from Run the DApp with an owner and renter account, then reload during an unresolved write to verify recovery.

Verify state handling: The UI updates the current operation only from a solidified execution result. A new listing or rental event triggers a fresh contract read. User rejection, insufficient Energy, contract failure, RPC timeout, and unknown results are represented accurately without creating duplicate listings or payments.

Next steps

After this track, retain the contract tests, compiler and deployment configuration, Shasta deployment evidence, TronLink frontend, transaction-recovery state, event cursor, and manual acceptance results. Event pagination, cursor persistence, and production security and operations still depend on the application's requirements.

If only part of the workflow is complete, preserve the code, configuration, txID values, and test results from the current stage, then resume later. You do not need to implement every production extension during an initial DApp exercise.

After the base application works, add real pagination and search as needed. For larger event and history workloads, see RPC and indexer providers — Indexer and data services. For upgrades, begin with Upgrading smart contracts — Trade-offs of introducing upgradeability.

If you are still blocked, share documentation feedback. Include “Track 3,” the current stage, tool versions, Shasta endpoint, contract address, original txID, completed steps, and the actual error. Never include private keys, mnemonics, API keys, production account information, or undisclosed vulnerabilities.