Tron

Skill based on TRON documentation (tronprotocol/documentation-en), generated 2026-02-25.

Core References

Features

Best practices

Generation Info

• Source: sources/tron (https://github.com/tronprotocol/documentation-en)
• Git SHA: af72fb27e0ff2b8121c01bf37a7f8142a045f20f
• Generated: 2026-02-25

Upgrade and Signature Verification

Upgrade (releases/upgrade-instruction)

• Mandatory vs optional: For mandatory upgrades, follow the upgrade guide strictly. For optional, decide based on need.
• Standard steps: Prepare new package (download or compile) -> Verify signature (see below) -> Stop node -> Back up critical data -> Replace JAR (and config if needed) -> Start node. Primary/backup setups: follow primary/backup upgrade guide for failover.
• Backup: Include database and config. Restore procedure documented in backup_restore.md.

Signature verification (releases/signature_verification)

• Purpose: Ensure FullNode.jar (or other artifacts) has not been tampered with. Verify before every upgrade or first use.
• Process: Download the JAR and the published signature/checksum file from official java-tron releases. Use the verification method described in the signature_verification doc (e.g. GPG verify or hash comparison). Do not skip this step for production nodes.

Usage for agents

When scripting upgrades or CI: (1) Download JAR and signature from official GitHub releases. (2) Run the documented verification command (GPG or hash). (3) Proceed with replace and start only after verification succeeds. Log verification result for audit.

<!-- Source: sources/tron/docs/releases/upgrade-instruction.md, sources/tron/docs/releases/signature_verification.md -->

TRON Account Permission Management

TRON accounts have a permission model (owner, witness, active) with configurable keys, weights, and thresholds. Used for multi-signature and role separation.

Permission types

Structure

Permission: type, id (owner=0, witness=1, active=2+), permission_name, threshold, operations (active only), keys (address + weight). Execution: sum of signing keys weights must be >= threshold. Default Permission_id = 0 (owner). operations = 32-byte hex bitmap of allowed contract types (see Tron.proto ContractType).

Update

AccountPermissionUpdateContract updates owner, witness, and full list of actives in one tx. HTTP: wallet/accountpermissionupdate. Fees: 100 TRX to modify permissions; extra 1 TRX per tx when 2+ signatures (configurable by proposal).

Auxiliary

wallet/getaccount for current permissions; wallet/getsignweight to check if tx has enough signatures; wallet/getapprovedlist for approved list.

Usage for agents

For multi-sig set owner or active with multiple keys and threshold > 1. Build tx, set Permission_id, collect signatures; last signer broadcasts. When calling accountpermissionupdate always send full permission payload.

<!-- Source: sources/tron/docs/mechanism-algorithm/multi-signatures.md -->

TRON Account Model

TRON uses an account-based ledger. All operations (transfers, voting, contract deployment) are tied to accounts.

Key concepts

• Address: Unique identifier, typically starts with T. Base58Check-encoded; default API format is HexString (prefix 0x41).
• EOA vs contract: Externally owned accounts (key pair) vs contract accounts (code).
• Activation: New addresses must be activated by receiving TRX or a TRC-10 token (or via CreateAccount system contract). Cost: 1 TRX creation fee; Bandwidth from staking or 0.1 TRX burn.

Address generation

1. ECDSA key pair (SECP256K1): private key 32 bytes, public key point P. 2. Hash: H = Keccak256(public_key); take last 20 bytes, prepend 0x41. 3. Base58Check on address (SHA256 twice, first 4 bytes as checksum; Base58 alphabet without 0, O, I, l). 4. Result: 34 characters, first character T.

Transaction signing

• Input: Transaction rawdata serialized to bytes.
• Hash: sha256(rawdata_bytes).
• Signature: ECDSA (SECP256K1); output r || s || recoveryId (or r || s || v with v = 27 + recoveryId). wallet-cli and java-tron use recoveryId.
• Verification: Recover public key from signature and hash (ecrecover); derive address; compare with transaction owner.

Usage for agents

• Validate addresses before sending: wallet/validateaddress (supports HexString, Base58Check, base64).
• Use visible parameter: false (default) = HexString in requests/responses; true = Base58Check.
• Account creation: wallet/createaccount (owner_address, account_address) or offline key generation + first incoming transfer.

<!-- Source references:

• sources/tron/docs/mechanism-algorithm/account.md
• sources/tron/docs/getting_started/getting_started_with_javatron.md

-->

TRON Decentralized Exchange (DEX)

TRON provides a native DEX of trading pairs between TRC-10 tokens (including TRX). Pairs follow the Bancor protocol; price is the ratio of token balances in the pair.

Concepts

• Trading pair (Exchange): Two TRC-10 tokens (or one TRC-10 + TRX). TRX represented as _ in params; amounts in sun.
• Creation cost: 1024 TRX (burned). Any account can create any pair; duplicate pairs allowed.
• Trading: No order book; instant swap. Minimum received is expected; tx reverts if received less than expected.

Contracts and HTTP APIs

Queries

ListExchanges, GetPaginatedExchangeList, GetExchangeById. After trade use gettransactioninfobyid and exchange_received_amount.

Usage for agents

Build create/trade/inject/withdraw via HTTP wallet APIs or gRPC; sign and broadcast. Set expected to a safe minimum for trade. Use GetExchangeById and balance fields to compute current price before building a trade.

<!-- Source: sources/tron/docs/mechanism-algorithm/dex.md -->

TRON DPoS Consensus

TRON uses Delegated Proof of Stake (DPoS). Block producers are Super Representatives (SRs) elected by vote.

Concepts

• SR (27): Produce blocks; elected by vote count. SRP (28th–127th): No block production; receive voting rewards.
• Slot: 3 seconds; one block per slot under normal conditions.
• Epoch: 6 hours. Last 2 slots of each epoch = maintenance period (no blocks); votes tallied, block order for next epoch set.
• TRON Power (TP): 1 TP per 1 TRX staked. Required to vote. Unstaking removes TP and invalidates current votes. Only latest vote per account counts per tally.

Block production

1. Collect and validate transactions; package into block. 2. Sign block; set parent hash; broadcast. 3. Other nodes verify and append. Order of production determined by vote ranking (highest first).

Voting

• Voting is a transaction type (VoteWitnessContract). Use wallet/votewitnessaccount (HTTP) or gRPC.
• Parameters: owner_address, list of (vote_address, vote_count). vote_count is in TP units.

Usage for agents

• Query SR list: wallet/listwitnesses. Query brokerage/rewards: wallet/getbrokerage, wallet/getreward.
• Build vote tx: wallet/votewitnessaccount with owner_address and votes array. Sign and broadcast like any transaction.
• Time-sensitive logic: slot ≈ 3s; epoch 6h; maintenance at end of each epoch.

<!-- Source references:

• sources/tron/docs/mechanism-algorithm/dpos.md
• sources/tron/docs/mechanism-algorithm/sr.md

-->

TRON Resource Model

Three system resources: TRON Power (TP), Bandwidth, and Energy.

TRON Power (TP)

• Use: Voting for Super Representatives (SRs) and SR Partners only.
• How to get: Stake TRX for Bandwidth or Energy → 1 TRX staked = 1 TP. Query: wallet/getaccountresource.

Bandwidth

• What it is: Byte size of a transaction (rate = 1). Every non-query transaction consumes Bandwidth.
• Ways to get: (1) Stake TRX for Bandwidth (share of network pool); (2) Delegation from another account; (3) Daily free allowance (e.g. 600; committee parameter).
• Consumption order (typical): Staked Bandwidth → free allowance → burn TRX (size × 1000 sun). New-account creation: staked first, then burn 0.1 TRX (no free allowance). TRC-10: issuer Bandwidth can pay under conditions, else initiator.
• Recovery: Free and staked Bandwidth recover over 24 hours.
• Query: wallet/getaccountresource; remaining free = freeNetLimit - freeNetUsed, staked = NetLimit - NetUsed.

Energy

• What it is: TVM computation for smart contract deployment and execution.
• When used: Deploy or trigger contracts only; not for plain TRX/TRC-10 transfers.
• Ways to get: Stake TRX for Energy (share of pool) or delegation.
• Consumption: Contract execution consumes Energy; if user doesn’t have enough, TRX is burned (sun per unit). Set fee_limit on trigger/deploy to cap burn.
• fee_limit: Mandatory for contract calls; maximum TRX (sun) the caller is willing to burn. Estimate or use a safe upper bound to avoid failed txs.

Usage for agents

• For transfers: ensure account has Bandwidth (or allow TRX burn). For contract calls: set fee_limit and consider Energy/TRX balance.
• Query resources: wallet/getaccountresource, wallet/getaccountnet (per-token Bandwidth for TRC-10).
• Staking: wallet/freezebalancev2 (ResourceCode 0 = Bandwidth, 1 = Energy); delegation: wallet/delegateresource.

<!-- Source references:

• sources/tron/docs/mechanism-algorithm/resource.md

-->

Super Representatives and Committee

SR and SR Partner

• SRs: Top 27 by vote; produce blocks; receive block and vote rewards. SR Partners: 28th-127th; no block production; share vote rewards. Apply: 9999 TRX fee (WitnessCreateContract).
• Voting: TRON Power (TP) = 1 per 1 TRX staked. Last vote overwrites all previous. Unstaking reclaims TP (unused first, then proportional from votes).
• APIs: CreateWitness (apply), UpdateWitness (e.g. URL), VoteWitnessAccount (vote), GetBrokerageInfo, GetRewardInfo, UpdateBrokerage (commission rate 0-100%). ListWitnesses, GetPaginatedNowWitnessList.

Brokerage and rewards

• Brokerage (commission): Default 20%. SR/SRP sets via UpdateBrokerage; 100% = all to SR; 0% = all to voters.
• Block production rewards: Per block (on-chain parameter, e.g. 8 TRX). SR gets brokerage share; voters get rest (when they trigger VoteWitness/Unfreeze/WithdrawBalance).
• Vote rewards: Pool (e.g. 128 TRX) distributed to SRs/SR Partners and voters by vote share; withdrawn on WithdrawBalanceContract.
• WithdrawBalanceContract: Withdraws accumulated rewards to account balance.

Committee

• Composition: 27 active SRs. Powers: Create proposal to modify network parameters; vote on proposals. Proposal passes with >= 18 approvals; takes effect next maintenance period.
• Create proposal: Any SR/SRP/candidate. createproposal id0 value0 ... idN valueN (parameter ids and values). Parameters: see TRONSCAN committee page.
• Vote: approveProposal id is_or_not_add_approval. Approval only; not voting = disapprove. Proposal valid 3 days.
• Cancel: Creator can deleteProposal proposalId before effect.
• Query: ListProposals, GetPaginatedProposalList, GetProposalById (HTTP/gRPC).

Usage for agents

Use wallet/updatebrokerage (or gRPC UpdateBrokerage) to set commission. Query brokerage and rewards with getbrokerage, getreward. Build proposal/vote/cancel txs via corresponding APIs; sign and broadcast. Check parameter ids and current values from chain/committee docs.

<!-- Source: sources/tron/docs/mechanism-algorithm/sr.md -->

TRON System Contracts

Different transaction types are implemented as system contracts. Each type has a specific HTTP/gRPC API to create the unsigned transaction.

Common system contracts and APIs

Workflow

1. Call the appropriate API with required parameters (addresses in HexString unless visible: true). 2. Node returns an unsigned transaction (Transaction protobuf / JSON). 3. Client signs with owner’s private key (permission may require multi-sig). 4. Broadcast via wallet/broadcasttransaction (or gRPC BroadcastTransaction).

Usage for agents

• Choose API by operation: transfer → createtransaction; account create → createaccount; contract → deploycontract / triggersmartcontract; vote → votewitnessaccount; resources → freezebalancev2 / delegateresource.
• All addresses in request/response follow visible (HexString vs Base58Check). Include Permission_id when using non-owner permissions.

<!-- Source references:

• sources/tron/docs/mechanism-algorithm/system-contracts.md
• sources/tron/docs/api/http.md

-->

TRON Tokens: TRC-10 and TRC-20

TRC-10: Native/system token. Issued via AssetIssueContract. HTTP: wallet/createassetissue, wallet/participateassetissue, wallet/transferasset. Params: owner_address, to_address, asset_name (token id hex), amount (smallest unit). Bandwidth consumed; issuer sets free limits. Queries: GetAssetIssueList, GetAssetIssueByAccount, GetAssetIssueByName, GetPaginatedAssetIssueList.

TRC-20: Smart contract, ERC-20 compatible. totalSupply(), balanceOf(address), transfer(to, value), transferFrom(from, to, value), approve(spender, value), allowance(owner, spender); events Transfer, Approval. Deploy Solidity contract; interact via wallet/triggersmartcontract or triggerconstantcontract. Decimals commonly 6 or 18.

Choosing and querying

TRC-10: lower cost, native DEX pairs. TRC-20: full programmability, DeFi. Balance: TRC-10 via getaccount assets; TRC-20 via contract balanceOf(address). Transfer: TRC-10 = wallet/transferasset; TRC-20 = triggersmartcontract with transfer selector + broadcast.

Usage for agents

Issue/participate/transfer TRC-10 with wallet HTTP/gRPC; asset_name as HexString (token id). TRC-20: encode call data, set fee_limit, trigger and broadcast. Use triggerconstantcontract for balanceOf/totalSupply/allowance. Distinguish token_id (TRC-10) vs contract address (TRC-20) in DEX/payment flows.

<!-- Source: sources/tron/docs/mechanism-algorithm/trc10.md, sources/tron/docs/contracts/trc20.md -->

TRON Virtual Machine (TVM)

TVM is TRON's execution environment for smart contracts. EVM-compatible: Solidity contracts compiled for Ethereum can run on TVM.

Resource model (vs Ethereum gas)

• Bandwidth: Consumed by transaction size; all tx types. Not computation.
• Energy: Consumed only by contract deployment and execution. Staked or delegated; insufficient Energy paid in TRX (sun) up to fee_limit. No per-op gas; execution metered in Energy.
• Contract execution does not consume TRX except when Energy insufficient (then TRX burn up to fee_limit).

Development flow

1. Compile Solidity (e.g. Remix); ABI and bytecode. 2. Deploy: wallet/deploycontract - owner_address, bytecode, ABI, name, fee_limit, origin_energy_limit, consume_user_resource_percent. 3. Trigger: wallet/triggersmartcontract - contract_address, function_selector (4-byte), parameter (ABI-encoded), call_value, fee_limit. View/pure: wallet/triggerconstantcontract (no broadcast). 4. Inspect: getcontract, gettransactioninfobyid (receipt, energy_usage).

Usage for agents

Estimate Energy via triggerconstantcontract or eth_estimateGas; set fee_limit to cap TRX burn. Deploy with origin_energy_limit and fee_limit. Set consume_user_resource_percent if contract should consume caller Energy first. For debugging use TronIDE or Remix; check transaction info for revert reason and energy used.

<!-- Source: sources/tron/docs/contracts/tvm.md, sources/tron/docs/contracts/contract.md -->

TRON API Interfaces

TRON nodes expose three main API surfaces: HTTP wallet API, gRPC, and JSON-RPC. Choose by client stack and use case.

HTTP Wallet API

• Base: http://host:port/wallet/<method> (e.g. wallet/getaccount, wallet/triggersmartcontract).
• Format: JSON request/response; addresses as HexString by default (visible: false), or Base58Check with visible: true.
• Use when: Building and broadcasting transactions from scripts or backends; same semantics as gRPC.
• Reference: features-http-wallet.

gRPC API

• Definition: api.proto. FullNode and (legacy) SolidityNode RPCs; SolidityNode is deprecated — use FullNode for all RPCs.
• Typical calls: GetAccount, CreateTransaction, BroadcastTransaction, DeployContract, TriggerContract, FreezeBalanceV2, UnfreezeBalanceV2, DelegateResource, GetNowBlock, GetBlockByNum, GetTransactionInfoById, GetBandwidthPrices, GetEnergyPrices, GetTransactionFromPending, etc.
• Use when: High-throughput or binary clients; wallet-cli and Java backends (e.g. Trident) use gRPC.
• Flow: Build request (protobuf) → get unsigned Transaction or TransactionExtention → sign locally → BroadcastTransaction.

JSON-RPC API

• Compatibility: Ethereum-style JSON-RPC; many eth_* and net_*, web3_* methods. Chain-specific differences (e.g. no gas; energy used instead; address encoding).
• Enable: In node config, e.g. node.jsonrpc { httpFullNodeEnable = true; httpFullNodePort = 50545 }.
• Encoding: QUANTITIES — hex with 0x, compact (no leading zeros). UNFORMATTED DATA (addresses, hashes, bytecode) — hex with 0x, two hex digits per byte.
• Key methods: eth_blockNumber, eth_getBalance, eth_call, eth_estimateGas (energy), eth_gasPrice (energy price in sun), eth_getBlockByNumber/ByHash, eth_getTransactionByHash, eth_getTransactionReceipt, eth_getCode, eth_getStorageAt, eth_getLogs / eth_newFilter + eth_getFilterChanges, eth_chainId, net_version, web3_sha3.
• TRON-specific: buildTransaction with params for TransferContract, TransferAssetContract, CreateSmartContract, TriggerSmartContract — returns unsigned transaction for signing and broadcast elsewhere.
• Use when: Reusing Ethereum tooling (e.g. ethers.js, web3.js) or existing JSON-RPC pipelines; event logs via eth_getLogs / filters.

Usage for agents

• Send TRX / call contract / deploy: Prefer HTTP wallet/* or gRPC for clear TRON types; use JSON-RPC buildTransaction + external sign + broadcast if the stack is already JSON-RPC.
• Read-only (balance, block, receipt, logs): Any of the three; JSON-RPC suits eth-compatible clients.
• Address format: HTTP/gRPC use HexString (e.g. 41...) or Base58Check per visible; JSON-RPC often uses 20-byte or 21-byte hex; confirm per method.
• Energy/fee: Use eth_estimateGas for contract energy; set fee_limit (or equivalent) when building contract txs to cap TRX burn.

<!-- Source references:

• sources/tron/docs/api/rpc.md
• sources/tron/docs/api/json-rpc.md

-->

TRON Event Subscription

TRON supports real-time and historical event streaming from nodes via event plugins (Kafka, MongoDB) or the built-in ZeroMQ queue.

Two subscription methods

Event plugin (recommended for production)

• Framework: V1.0 = real-time only; V2.0 = historical replay from a given block (event.subscribe.startSyncBlockNum). Set event.subscribe.version = 1 for V2.0.
• Flow: Node extracts events, buffer queue, plugin consumes, pushes to Kafka or MongoDB. Enable with java -jar FullNode.jar -c config.conf --es.
• Config: event.subscribe.path = path to plugin zip; event.subscribe.server = Kafka or MongoDB host:port; for MongoDB, dbconfig = database|user|password. Set native.useNativeQueue = false when using plugins.
• Event types (subscribe only 1-2 to avoid overload): block, transaction, contractevent, contractlog, solidity, solidityevent, soliditylog. solidity = solidified block notification.
• Filtering: filter.fromblock, filter.toblock, filter.contractAddress[], filter.contractTopic[] for contract events/logs.
• Topics: Each trigger has triggerName, enable, topic (Kafka topic or MongoDB collection). Create Kafka topic to match.

Built-in ZeroMQ

• Config: event.subscribe.native.useNativeQueue = true, native.bindport (e.g. 5555), native.sendqueuelength. Subscriber connects to tcp://127.0.0.1:5555.
• Start: java -jar FullNode.jar -c config.conf --es. No plugin path required.
• Subscribe: ZeroMQ SUB socket; subscribe by topic name (e.g. block). Messages are JSON.
• Limitation: No persistence; no historical replay; messages can be dropped if consumer is slow.

Usage for agents

• dApps / indexers: Prefer event plugin (Kafka or MongoDB) with V2.0 and startSyncBlockNum for backfill; use contractevent/contractlog or solidityevent/soliditylog with filter.contractAddress for specific contracts.
• Quick testing: ZeroMQ with --es; subscribe to block or transaction.
• Querying stored events: With MongoDB plugin, use TronGrid or Event Query Service HTTP API to query by block, contract, or transaction.

<!-- Source: sources/tron/docs/architecture/event.md -->

TRON HTTP Wallet APIs

High-value HTTP endpoints for building and sending transactions and querying accounts.

Account

• wallet/validateaddress: Validate address (HexString, Base58Check, or base64). Use before sending.
• wallet/createaccount: Create (activate) account; returns unsigned tx. Params: owner_address, account_address; optional permission_id, visible.
• wallet/getaccount: Full account (balance, resources, permissions, assets). Params: address, optional visible.
• wallet/updateaccount: Set account name; returns unsigned tx.
• wallet/accountpermissionupdate: Change permission structure; returns unsigned tx.

Transfer and broadcast

• wallet/createtransaction: TRX transfer. Params: owner_address, to_address, amount (sun); optional visible. Returns unsigned Transaction.
• wallet/broadcasttransaction: Submit signed transaction (hex or JSON). Returns result and txid.

Contract

• wallet/deploycontract: Deploy contract. Params: owner_address, abi, bytecode, name, fee_limit, origin_energy_limit, etc.
• wallet/triggersmartcontract: Call contract. Params: owner_address, contract_address, function_selector (4-byte), parameter (hex), call_value, fee_limit.
• wallet/triggerconstantcontract: Call view/pure without broadcasting; returns return value.

Resources and voting

• wallet/getaccountresource: Bandwidth, Energy, TP usage/limits.
• wallet/freezebalancev2, wallet/unfreezebalancev2: Stake/unstake for Bandwidth or Energy.
• wallet/votewitnessaccount: Vote for SRs; params: owner_address, votes [{vote_address, vote_count}].

Usage for agents

• Always set visible consistently (false = HexString, true = Base58Check). Use HexString for server/server flows.
• Flow: create (e.g. createtransaction/createaccount/triggersmartcontract) → sign locally → broadcasttransaction. Never send private keys to the node.
• For contract reads use triggerconstantcontract; for writes use triggersmartcontract + broadcast.

<!-- Source references:

• sources/tron/docs/api/http.md

-->

java-tron Node Deployment and Operations

Deployment (installing_javatron)

• Platform: Linux or macOS. x86_64: Oracle JDK 8. arm64 (from 4.8.1): JDK 17.
• Hardware: Min 8 CPU, 16 GB RAM, 3 TB SSD, 100 Mbps. Recommended 16 CPU, 32 GB, 3.5 TB SSD. SR block-producing node: 32 CPU, 64 GB, 3.5 TB SSD.
• Obtain client: Download FullNode.jar from java-tron releases or compile from source (git clone, checkout branch, ./gradlew clean build -x test). Output: build/libs/FullNode.jar.
• Config: config.conf (genesis block, RPC ports, storage, etc.). Customize for mainnet/testnet/private.
• Start: java -jar FullNode.jar -c config.conf. Event subscription: add --es. Lite FullNode: use lite config and corresponding JAR if available.

Upgrade (releases/upgrade-instruction)

• Standard process: (1) Prepare new version (download JAR or compile); verify signature per signature_verification guide. (2) Stop node (kill -15 PID). (3) Back up data (database, config). (4) Replace JAR and optional config. (5) Start new version. For primary/backup HA, follow primary/backup upgrade guide to switch over without downtime.

Other operational docs

• Private network: Configure genesis and peer list for isolated network.
• Lite FullNode: Lighter sync/storage option; see litefullnode.md.
• Backup and restore: Snapshot/backup procedures and data restore; FullNode data snapshots.
• Metrics: Node monitoring (using_javatron/metrics).
• Toolkit: Node maintenance tool (using_javatron/toolkit).
• Connecting: Network connection and peer configuration (connecting_to_tron).

Usage for agents

When automating node deployment or upgrade: use correct JDK for architecture; always verify JAR signature before replace; back up before upgrade; for event subscription include --es and event plugin config. Refer to official docs for exact config keys and snapshot URLs.

<!-- Source: sources/tron/docs/using_javatron/installing_javatron.md, releases/upgrade-instruction.md, architecture/database.md -->

TRON Smart Contracts

TRON supports Solidity-like smart contracts on the TVM (TRON Virtual Machine). Contracts are defined by bytecode, ABI, and metadata (origin_address, contract_address, call_value, consume_user_resource_percent, origin_energy_limit, etc.).

Contract creation and triggering

• Deploy: CreateSmartContract → HTTP wallet/deploycontract. Parameters include owner_address, bytecode, ABI, name, fee_limit, origin_energy_limit, etc.
• Call: TriggerSmartContract → HTTP wallet/triggersmartcontract. Parameters: owner_address, contract_address, function_selector, parameter (ABI-encoded), call_value (TRX), fee_limit.

Constant vs inconstant

• Constant (view/pure): Decorated with view/pure/constant. Executed on the node; result returned; no transaction broadcast. Use for read-only queries.
• Inconstant: State-changing; must be broadcast as a transaction. Exception: dynamic CREATE inside a contract is always treated as inconstant.

Message calls and delegate call

• Message calls: Contract can call other contracts or send TRX; each call has initiator, recipient, data, value, fees. Remaining energy can be distributed in internal calls. OutOfEnergy in internal call returns false without reverting outer state; only energy for that call is consumed.
• Delegate call / call code: Target code runs in caller’s context (storage, address, balance); only code loaded from target. Used for libraries and reusable logic.

CREATE and address

• CREATE: New contract with new address. TRON address = f(creation_tx_id, nonce). Nonce = contract creation sequence number of root call. Contracts created via CREATE do not store ABI on-chain.

Usage for agents

• Read-only: use triggersmartcontract with view/pure function and do not broadcast; parse return value from response.
• State-changing: build trigger tx, set fee_limit, sign, broadcast. Estimate fee_limit from similar calls or use a safe cap.
• Deploy: deploycontract with bytecode + ABI; set origin_energy_limit and fee_limit.

<!-- Source references:

• sources/tron/docs/contracts/contract.md
• sources/tron/docs/mechanism-algorithm/system-contracts.md

-->

TRON Developer Tools

Usage for agents

• Frontend/dApp (browser): TronWeb (wallet integration, contract calls, TRX/TRC-20).
• Backend (Node): TronWeb or HTTP APIs to a FullNode/TronGrid.
• Contract deployment/migrations: TronBox or custom scripts with TronWeb/Trident.
• Event/log queries: TronGrid or node HTTP/API.
• Java backends: Trident for type-safe integration with java-tron APIs.

<!-- Source references:

• sources/tron/docs/contracts/tools.md

-->

TronGrid

TronGrid is a hosted TRON API. Base URL: https://api.trongrid.io/ (mainnet); testnets use different hostnames (e.g. Shasta).

API types

1. FullNode/SolidityNode proxy: Same as self-hosted. e.g. https://api.trongrid.io/wallet/getnowblock, wallet/getaccount. 2. TronGrid v1 REST: Resources under https://api.trongrid.io/v1/. Addresses in base58 or hex; responses in snake_case.

TronGrid v1 endpoints (summary)

• Accounts: GET /v1/accounts/:address (only_confirmed); GET /v1/accounts/:address/transactions (only_to, only_from, limit, fingerprint, order_by, min/max_block_timestamp); GET /v1/accounts/:address/resources.
• Assets: GET /v1/assets; GET /v1/assets/:identifier; GET /v1/assets/:name/list (TRC-10; pagination, order_by).
• Blocks: GET /v1/blocks/:identifier/events (identifier = latest, block number, or block id).
• Contracts: GET /v1/contracts/:address/events (only_confirmed, event_name, block_number, min/max_block_timestamp, limit, fingerprint, order_by); GET /v1/contracts/:address/transactions.
• Transactions: GET /v1/transactions/:id/events; GET /v1/transactions/:id.

Usage for agents

Read-only: Use TronGrid wallet proxy or v1 to avoid running a node. Event indexing: GET /v1/contracts/:address/events with filters; paginate with limit/fingerprint. Broadcast: POST /wallet/broadcasttransaction; build and sign tx locally (never send private keys).

<!-- Source: sources/tron/docs/clients/tron-grid.md -->

TRON wallet-cli

wallet-cli is an interactive CLI that talks to a java-tron node via gRPC. It signs and broadcasts transactions locally and queries on-chain data.

Flow

1. Start: java -jar wallet-cli.jar (or ./gradlew run from repo). 2. Register/import: RegisterWallet <password> or ImportWallet; then Login <password>. 3. Network: switchnetwork (1=MAIN, 2=NILE, 3=SHASTA); currentnetwork to confirm. 4. Build and sign locally; call node’s BroadcastTransaction gRPC to send.

Key management: keys in local Keystore (encrypted); no keys sent to node.

Command groups

• Key management: Logout, LoginAll, BackupWallet, getAddress.
• Accounts: getaccount, getbalance, createaccount (via commands that create txs).
• Resources: freezeBalanceV2, unfreezeBalanceV2, delegateResource.
• Transactions: SendCoin (TRX), TransferAsset (TRC-10); then broadcast.
• Contracts: deploy and trigger via CLI commands that map to gRPC.
• Governance: vote, listwitnesses, etc.
• DEX: ExchangeCreate, ExchangeTransaction, etc.

Usage for agents

• Use wallet-cli when the agent drives a local node and must sign with a local keystore (e.g. testing, scripts). For dApps or backend services, use HTTP/JSON-RPC + external signer (TronWeb, Trident, etc.).
• getaccount &lt;address&gt;, getbalance for balances; createaccount and transfer flows require building tx, signing, then broadcasting.
• Build and run from wallet-cli repo; detailed command list in its docs.

<!-- Source references:

• sources/tron/docs/clients/wallet-cli.md
• sources/tron/docs/getting_started/getting_started_with_javatron.md

-->