Developer guide

Tron

5 min read

Roadmap Tron is an explicit target blockchain family for ChatterPay B2B and uses a native adapter. It shares its signature curve with the EVM family, and everything else — addresses, cost accounting, the token standard — follows its own model.

Accounts and addresses

Tron is account-based and signs with secp256k1, the same curve as Ethereum, so a key can derive both. The address, however, is encoded in base58check with a T prefix rather than as a 0x hex string, and the same key therefore has two different textual addresses.

The adapter converts between the two representations at the boundary and stores the Tron form in the chain account, so a Partner never has to guess which encoding an identifier is in.

Bandwidth, energy and fee limit

Tron charges in resources. A transaction consumes bandwidth, and a smart-contract call — which is what a TRC-20 transfer is — also consumes energy. An account can obtain both by staking TRX, or pay for them by burning TRX at the moment of the transaction.

This is why a Tron quote is priced from the state of the sending account: the cost of the same transfer depends on what that account has staked. The quote states the resulting cost before the transfer is confirmed, in the same way as every other family.

TRC-20 and stablecoins

Most stablecoin volume on Tron moves as TRC-20 tokens, which is the standard the adapter targets first. A TRC-20 transfer is a contract call, so it is subject to the energy accounting described above and to the contract's own behaviour.

Transfer flow

sequenceDiagram
    autonumber
    participant P as Partner backend
    participant API as B2B API
    participant OP as Operation worker
    participant A as Tron adapter
    participant N as Tron node
    participant SG as Partner Signer Gateway
    participant R as Observer/Reconciler
    P->>API: Transfer TRX/TRC-20
    API->>OP: Operation + reserve
    OP->>A: Prepare transaction
    A->>N: Account resources + parameters
    N-->>A: Bandwidth, energy, fee limit
    A->>A: Build transaction, set fee limit
    A->>SG: Sign transaction hash
    SG-->>A: secp256k1 signature
    A->>N: Broadcast transaction
    N-->>A: tx id
    R->>N: Observe confirmation
    R->>OP: Reconcile amount and resource cost
    OP-->>P: Webhook / state

What each step does

  1. Partner backend → API. The Partner asks to send TRX or a TRC-20 token, which is where most stablecoin volume on Tron moves.
  2. API → operation worker. The Operation is persisted and the balance reserved.
  3. Worker → Tron adapter. The adapter converts between the two textual forms of the same address — base58check with a T prefix, and hex — so the Partner works with one representation.
  4. Adapter → node: account resources and parameters. The cost of a Tron transfer depends on what the sending account has staked, so the adapter reads that state before pricing anything.
  5. Node → adapter: bandwidth, energy and fee limit. A transaction consumes bandwidth, and a contract call — which is what a TRC-20 transfer is — also consumes energy. An account covers both by staking TRX or by burning TRX at the moment of the transaction.
  6. The adapter builds the transaction and sets the fee limit. The fee limit bounds what a contract call may consume, and the quote states the resulting cost before the transfer is confirmed.
  7. Adapter → Partner Signer Gateway. The transaction hash travels with the Tron key reference. Tron signs with secp256k1, the same curve as EVM, and the account keeps its own address.
  8. Gateway → adapter: secp256k1 signature.
  9. Adapter → node: broadcast.
  10. Node → adapter: tx id.
  11. Observer → node: confirmation. The observer waits for the number of blocks agreed for the operation.
  12. Reconciler → worker. The amount settled and the resources actually consumed are contrasted against what was quoted and recorded.
  13. Worker → Partner. The final state travels as a signed webhook, and the same result can be read from the Operation.

References

Capabilities in this area

This area covers the capabilities below. The Roadmap states the current availability of each one.

  • Native adapter and account model — Tron uses the same signature curve as the EVM family, so one key serves both, but its addresses are written in base58 and start with a T. The adapter converts between the two forms and stores the Tron address in the user's chain account.

  • TRX and TRC-20 token transfers — Sending the native coin and TRC-20 tokens, the standard most stablecoins on Tron use. A TRC-20 transfer is a call to a contract, so the adapter sets the spending limit that call needs.

  • Bandwidth and energy resource management — A Tron transaction spends bandwidth, and a contract call also spends energy. An account gets both by freezing TRX, or pays for them by burning TRX at the time of the transaction. The quote calculates the cost from what the sending account has frozen.

  • Tron observation and reconciliation — A component watches for incoming transfers and checks the settled amounts against the ledger, recording how much bandwidth and energy each transaction actually consumed.

  • Testnet — Tron available on its public test network from the API, the SDK and the Sandbox. A Partner can send and receive TRX and TRC-20 tokens with no funds at risk, and check every transaction in a public explorer.

  • Mainnet — Tron on the network where the funds are real. It depends on the custody, security and operational capabilities listed in the other areas being finished first.