Contracts
TRON's virtual machine (TVM) is EVM-compatible, so smart contract interaction in
tronz looks a lot like alloy. The tronz-contract crate (re-exported as
tronz::contract, behind the contract feature) provides token bindings and
the building blocks for arbitrary contract calls.
use tronz::contract::Trc20Ext;What's included
| Item | Purpose |
|---|---|
Trc20Ext / Trc20Instance | High-level TRC20 token interface |
Trc721Ext / Trc721Instance | High-level TRC721 NFT interface |
tron_sol! | Alpha: generate provider-bound, typed contract bindings |
ContractInstance / ContractExt | Generic provider-bound contract handle |
CallBuilder | Build, simulate, and send a single contract call |
DeployBuilder | Deploy a new contract |
Interface | A runtime ABI loaded from JSON |
decode_log / decode_logs | Decode event logs from a receipt |
ABI compatibility with alloy
Because the TVM uses the same ABI as the EVM, tronz reuses alloy's ABI tooling
directly. The TRC20 bindings are generated by alloy's sol! macro, and these
types are re-exported for working with your own contracts:
use tronz::contract::{SolCall, SolError, SolEvent, SolInterface, SolValue};The one TRON-specific detail is addresses: a TRON Address carries a 0x41
prefix, but ABI encoding uses the 20-byte EVM body. tronz handles this for you —
the Address ↔ alloy_primitives::Address conversion strips and re-attaches the
prefix automatically (see Addresses).
Reads vs. writes
- Reads (constant calls) need only a provider — no signer.
- Writes go through the same transaction lifecycle
as native operations: they're filled, signed, broadcast, and confirmed, and
they consume energy. Set an appropriate
fee_limit(see Fillers).
Start with TRC20 tokens for the most common case.
For custom contracts, use tron_sol! when the ABI is
known at compile time, or the
dynamic ABI example when it is only
known at runtime.