Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Reads or writes Tron contract state outside of a deploy — the TronWeb/`troncast` analog of using `cast` on EVM chains. Use whenever the target network is `tron`/`tronshasta` and the user wants to call a view function, send a transaction (transfer, approve, admin call), check/convert an address, or fetch bytecode — e.g. "check the balance on tron", "send TRX to X", "call owner() on the tron diamond", "what's the base58 for this address". Also the routing target when `manage-wallet-funds` or anoth
.claude/skills/lifinance-interact-tron/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-04 | ✗→✓ | ▲ Improved | 16% | 0% |
| case-05 | ✗→✓ | ▲ Improved | -1% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 43% | 0% |
| case-07 | ✗→✓ | ▲ Improved | -13% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 18% | 0% |
Tron has its own address format, RPC surface, and resource model, so cast does not work against it (eth_getTransactionCount and debug_traceTransaction aren't supported on TronGrid public endpoints). All read/write contract interaction on Tron goes through troncast (script/troncast/), a Cast-like TronWeb wrapper — never hand-roll a TronWeb script for something troncast already covers.
Repo: stay in contracts. Unlike /deploy-contract-tron, this skill needs no contracts-tron fork checkout — troncast and the deployed contract's on-chain state are both reachable from the normal contracts session. See docs/TronFork.md for why the fork exists at all and when it does matter (deploys and any change to LibAsset/WithdrawablePeriphery).
| Situation | Skill | |---|---| | Deploying a new contract to Tron | /deploy-contract-tron | | Read a Tron contract's state, or send a simple write (transfer, approve, single admin call) | this skill | | Move gas (TRX) from our own deployer wallet | this skill (troncast send ... --value) | | Production governance change (whitelist sync, ownership transfer, anything needing the Timelock) | route to propose-to-safe-tron.ts conventions — this needs Safe-quorum + scheduleBatch/executeBatch sequencing, not a one-off troncast send. Flag it and get explicit direction rather than improvising. | | Analyzing a past Tron transaction/trace | /analyze-tx (already has a Tron-specific section) |
202-tron-scripts.md)Tron addresses are base58 (T...) at the RPC/display layer, 21-byte hex (0x41 prefix + 20-byte EVM address) internally. Convert explicitly at the point of use — never assume a hex address the user pastes is already in the right form for a given call:
bashbun troncast address to-hex TLPh66vQ2QMb64rG3WEBV5qnAhefh2kcdw # -> 0x7252af... bun troncast address to-base58 0x7252afce04856eaac8f8a8beb5ae29621a1ca49b # -> TLPh66...
troncast itself accepts either format for call/send/code target addresses, so conversion is only needed when the user needs the other format back, or when composing calldata by hand.
RPC env var required even for offline conversions. troncast address to-hex/to-base58 always requires ETH_NODE_URI_TRON in .env — the codec hardcodes the mainnet TronWeb instance, so ETH_NODE_URI_TRONSHASTA does not satisfy it and address takes no --env flag — even though the conversion itself is a pure offline codec operation; the CLI aborts without it. If it's not set, prefix a dummy value for that one invocation rather than editing .env.
troncast callbashbun troncast call <address> "<functionSignature> returns (<type>)" [params...] --env <mainnet|testnet> # examples bun troncast call <DIAMOND> "owner() returns (address)" --env mainnet bun troncast call <TOKEN> "balanceOf(address) returns (uint256)" <WALLET> --env mainnet bun troncast call <TOKEN> "decimals() returns (uint8)" --env mainnet --json
--env defaults to mainnet; use testnet for tronshasta. Function signatures follow the same Solidity/Foundry format as cast (transfer(address,uint256) returns (bool)).
troncast codebashbun troncast code <address> --env mainnet # analog of `cast code`
troncast sendbashbun troncast send <address> "<functionSignature>" [params...] --private-key <KEY> --env <mainnet|testnet> # transfer tokens bun troncast send <TOKEN> "transfer(address,uint256)" <RECEIVER>,1000000 --private-key "$KEY" # send TRX (native) bun troncast send <address> "deposit()" --value 0.1tron --private-key "$KEY" # dry run first for anything non-trivial bun troncast send <TOKEN> "approve(address,uint256)" <SPENDER>,1000000 --dry-run
Key flags: --value (0.1tron / 100000sun / raw sun), --fee-limit (TRX cap, default 1000), --energy-limit, --dry-run (simulate, no broadcast), --no-confirm, --json.
One broadcast per tool call. Same rule as manage-wallet-funds: never loop troncast send inside a single tool call — one signed transaction per invocation, confirm the result before sending the next.
Derive the sender from the private key, not config/global.json. global.json → tronWallets lists known-role addresses (deployerWallet, devWallet, refundWallet, ...) for identification and delegation bookkeeping — it is not a source of truth for which key you're about to sign with. Confirm you're using the intended wallet's key before broadcasting.
Dry-run before any non-trivial write. --dry-run simulates without broadcasting and costs nothing — use it whenever the call isn't a simple, previously-verified pattern (a fresh function signature, a new target contract, or anything moving more than trivial value).
Tron pays for execution in Energy (≈ gas), not just bandwidth. --fee-limit is a TRX ceiling on what the transaction may consume if it must buy Energy — set it deliberately for anything beyond a cheap call rather than trusting the 1000 TRX default. If a write repeatedly fails with an out-of-energy-style error, that's a fee-limit or energy-limit problem, not a revert — raise --fee-limit/--energy-limit and retry rather than assuming the call itself is wrong.
Ongoing higher-volume Tron operations (the Timelock's scheduleBatch/executeBatch) run off delegated Energy from staked TRX on deployerWallet/devWallet rather than burning TRX per call — that delegation is a separate, human-arranged concern (ping Max) and out of scope for a one-off troncast interaction.
troncast gapsNo ABI auto-fetch, no contract verification, no wallet management, limited gas estimation, no chain forking, no event-log filtering. For anything needing these, say so explicitly rather than working around them with ad hoc TronWeb code outside script/troncast/.
cast used against a Tron network → will fail on RPC methods Tron doesn't support; switch to troncast.--dry-run), then check the target address is in the form troncast expects (base58 or 0x-hex, not a malformed hybrid).--fee-limit/--energy-limit, don't assume the calldata was wrong.proto is not defined → known TronWeb/Bun compatibility hiccup; retry the same command once before investigating further.| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 11,972 | 7,025 | -41% | 1 | 1 | 0% | 2,187 | 2,416 | +10% | 0 | 0 | — |
case-02 | fail→fail | 11,579 | 5,456 | -53% | 1 | 1 | 0% | 2,396 | 2,177 | -9% | 0 | 0 | — |
case-03 | fail→fail | 11,200 | 7,388 | -34% | 1 | 1 | 0% | 1,920 | 2,237 | +17% | 0 | 0 | — |
case-04 | fail→pass | 12,806 | 4,384 | -66% | 1 | 1 | 0% | 2,199 | 2,543 | +16% | 0 | 0 | — |
case-05 | fail→pass | 16,660 | 3,159 | -81% | 1 | 1 | 0% | 2,377 | 2,344 | -1% | 0 | 0 | — |
case-06 | fail→pass | 11,181 | 3,619 | -68% | 1 | 1 | 0% | 1,667 | 2,386 | +43% | 0 | 0 | — |
case-07 | fail→pass | 18,069 | 4,551 | -75% | 1 | 1 | 0% | 3,032 | 2,624 | -13% | 0 | 0 | — |
case-08 | fail→pass | 11,936 | 4,867 | -59% | 1 | 1 | 0% | 2,182 | 2,571 | +18% | 0 | 0 | — |
case-09 | fail→pass | 14,655 | 3,457 | -76% | 1 | 1 | 0% | 2,861 | 2,491 | -13% | 0 | 0 | — |
case-10 | fail→pass | 11,593 | 3,349 | -71% | 1 | 1 | 0% | 1,657 | 2,402 | +45% | 0 | 0 | — |
case-11 | fail→pass | 11,569 | 6,082 | -47% | 1 | 1 | 0% | 2,189 | 2,339 | +7% | 0 | 0 | — |
case-12 | fail→pass | 10,653 | 4,053 | -62% | 1 | 1 | 0% | 1,743 | 2,527 | +45% | 0 | 0 | — |
case-13 | fail→pass | 14,355 | 5,451 | -62% | 1 | 1 | 0% | 2,259 | 2,631 | +16% | 0 | 0 | — |
case-14 | pass→pass | 13,179 | 2,645 | -80% | 1 | 1 | 0% | 2,038 | 2,264 | +11% | 0 | 0 | — |
case-15 | pass→pass | 13,343 | 5,462 | -59% | 1 | 1 | 0% | 2,133 | 2,672 | +25% | 0 | 0 | — |
case-16 | fail→pass | 13,806 | 2,793 | -80% | 1 | 1 | 0% | 2,353 | 2,322 | -1% | 0 | 0 | — |
case-17 | fail→pass | 12,713 | 2,850 | -78% | 1 | 1 | 0% | 1,934 | 2,225 | +15% | 0 | 0 | — |
case-18 | fail→pass | 14,605 | 4,019 | -72% | 1 | 1 | 0% | 2,368 | 2,441 | +3% | 0 | 0 | — |
case-19 | pass→pass | 11,343 | 3,435 | -70% | 1 | 1 | 0% | 1,823 | 2,401 | +32% | 0 | 0 | — |
case-20 | fail→pass | 12,246 | 4,645 | -62% | 1 | 1 | 0% | 1,691 | 2,629 | +55% | 0 | 0 | — |
case-21 | fail→pass | 16,323 | 5,859 | -64% | 1 | 1 | 0% | 2,525 | 2,711 | +7% | 0 | 0 | — |
case-22 | pass→pass | 16,320 | 3,384 | -79% | 1 | 1 | 0% | 2,237 | 2,297 | +3% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 19 counted toward the lift figure. The other 3 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +68 percentage points is the difference between those two pass rates over the 19 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.