Instant delivery

Lifetime updates

1 domain license

Blockchainv6.1.3

Tron Blockchain Addon

Name: Tron Blockchain Addon
Brand: MashDiv
SKU: tron
Price: 109.00 USD
Availability: InStock

Take TRC-20 and TRX deposits on your own keys, and pay them out on a gas budget you control.

4.7028 sales

$109$129Save 16%

You'll also need Bicrypto and Ecosystem for Bicrypto

On its own, Tron Blockchain Addon won't work — it only runs if you already own these products. Open the Requirements tab to see exactly what you need and add them to your order.

See it working Live demo Documentation View on CodeCanyon

Per-user Tron addresses for native TRX and every TRC-20 token you import
Each address is its own BIP-39 seed — nothing derives from the master wallet
Deposit detection on two TronGrid endpoints, polled every 30 seconds
Dust airdrops under 0.001 filtered out before they reach a customer's history
TRC-20 amounts matched on recipient and contract, so batches credit correctly
Deposits credit inline on detection, with no confirmation-depth wait
Energy and bandwidth sized per transfer from a live contract simulation
The signing address is topped up in TRX to a target, with 20% headroom
An empty master wallet requeues the payout instead of failing and refunding
Only an on-chain SUCCESS receipt becomes COMPLETED — a broadcast is not enough
TIMEOUT rows go to manual review, never a refund that would mint funds
Mainnet, Shasta and Nile, with a five-check diagnostics probe before launch

Inside the Tron addon

Tron custody, and the resource budget behind every payout

Per-user Tron addresses for native TRX and any TRC-20 token you import, deposit detection on both, and a withdrawal path that funds its own signer. It plugs into Ecosystem's wallets, vault and withdrawal queue — so it needs Bicrypto core and Ecosystem underneath it, and an activated licence plus a database toggle before the service will start.

In detail

Tron custody for your Ecosystem install. Every customer gets their own Tron address for native TRX and each TRC-20 token you import; deposits are detected and credited, and withdrawals are signed and broadcast by your own server. The keys sit in your database rather than at a custodian.

How it works

The addon registers one chain service with Ecosystem. The first time a customer opens the deposit page for a Tron-backed currency, a fresh BIP-39 mnemonic is generated for that wallet, derived at the standard Tron path and encrypted with the Ecosystem vault key before anything is stored. Deposits are found on two TronGrid endpoints — one for native TRX, one for TRC-20 — and credited the moment they are found, with a 60-second watchdog behind that for anything the inline credit could not finish. Withdrawals diverge sharply, because Tron charges no gas price out of the amount being sent. Every transaction consumes two metered resources instead — energy and bandwidth — and whichever account signs must own them or burn TRX. So the platform simulates the transfer, reads the signer's live resources and the node's current burn prices, and tops that address up in TRX from your master wallet before it signs.

The real configurable surface

Setting	What it decides
`TRON_NETWORK`	mainnet, Shasta or Nile — any other value kills every Tron flow
RPC full host	the TronGrid-compatible endpoint every call goes through
`TRON_API_KEY`	whether deposit polling survives its own rate limit
Imported tokens	which TRC-20 contracts exist, with their decimals and precision
Each token's fee	the only thing a customer is charged, and how you recover TRX
Master wallet TRX	the gas budget every TRC-20 payout is funded from

What operators control

Enable or disable the chain from Admin, Ecosystem, Blockchains. Import any TRC-20 contract — tokens on Tron are imported, never deployed. Set each token's fee, denominated in the token: that is where the TRX your master wallet burns comes back. Run the requirements probe before launch — five live checks plus a per-flow readiness that fails withdrawals while the vault is locked or the master wallet is missing, even when every RPC answers. Disable the master wallet to stop signing on Tron entirely.

Requires Bicrypto core and the Ecosystem addon, and it is gated twice — an activated licence and a database toggle. Then watch one number: the master wallet's TRX balance. When it empties, TRC-20 payouts sit in PENDING and are quietly retried while native TRX withdrawals keep completing. Nobody is refunded, but the symptom looks like a token problem and is not.

An empty gas tank stalls TRC-20 payouts and nothing else

Tron has no fee-payer primitive: whichever account signs is the account whose energy and bandwidth are spent, so the platform physically sends TRX to the signing address before it signs. That TRX comes out of one master wallet you fund. When it runs dry the withdrawal is requeued rather than failed — the row stays PENDING, a watchdog retries it, and nobody is refunded because nothing was attempted on-chain. Native TRX payouts keep completing throughout, which is why the symptom reads like a token misconfiguration and is not one.

The master wallet's TRX balance is the one number to alert on. Fund it and the backlog drains by itself; nothing in the admin panel will stake TRX for you, because the product has no freeze, unfreeze or delegation path at all.

Every Tron address is its own key, not an index under a master seed

Each ECO wallet generates a fresh BIP-39 mnemonic and derives one key at m/44'/195'/0'/0/0, encrypted with the Ecosystem vault key before anything is stored. There is no HD parent, so losing the master wallet strands gas capacity and no customer address — and equally, there is no seed to fall back on if a row goes missing. A usable backup is three things kept apart: the database, the encryption key in .env, and the passphrase that unwraps it.

Regenerating the encryption key makes every Tron mnemonic on the install permanently unreadable. Nothing recovers from that — not you, not us. The vault must also be unlocked in the process serving the request, or withdrawals fail and refund instead of holding.

The inbound side costs you nothing and credits without a wait

Deposits consume no resources of yours — somebody else signed them. Native TRX and TRC-20 transfers are found on two different TronGrid endpoints, dust airdrops are filtered before they reach a customer's history, and a TRC-20 amount is matched on both recipient and emitting contract so a batch payout can never credit somebody else's figure. Tron is treated as already confirmed, so a detected deposit is credited inline rather than waiting out a confirmation depth — the 60-second watchdog only picks up the ones that could not be credited on the spot.

That is faster and it is a weaker guarantee than a depth rule — if your risk model needs one, add a manual hold. And set a TronGrid API key on mainnet: after ten consecutive polling errors the deposit monitor deletes its own loop.

Every check can pass and the console will still refuse to call it ready

Ecosystem's chain requirements screen carries a card for Tron: the environment variables in force, listed set or not, five probes you run on demand, and a separate verdict for deposits and for withdrawals. The five are network resolution, node liveness, the TronGrid REST path, whether the chain service is installed, and whether the licence file and the database toggle are both on. A pass needs all five green and no platform flow reported broken, so a locked vault or a missing master wallet fails the withdrawals verdict while the node is answering perfectly. Deposits stay green in exactly that state — an existing address keeps crediting while payouts sit still. The card names the cause in the one line at the top of it.

Nothing runs these probes on a schedule. The result is cached for seven days and stamped 'Last run …', so a chain that broke this morning reads green until somebody presses the button.

metered resources per transfer: 2
terminal states a payout reaches: 4
diagnostic checks before you launch: 5
networks: mainnet, Shasta, Nile: 3

Everything included

73 capabilities, in 6 areas

Every item below exists in the source you receive. Nothing here is a roadmap.

Addresses and key custody

Where every Tron key on the install comes from and where it lives.

A Tron address per customer wallet — native TRX and each TRC-20 token you import
A fresh BIP-39 mnemonic per address, derived at m/44'/195'/0'/0/0
Base58 T… addresses derived from the private key, refused rather than half-recorded
Mnemonic, public key, private key and path encrypted with the Ecosystem vault key
One key row per wallet, currency and chain — no HD parent, nothing under a master seed
Key row written before the address, so a failed write leaves neither
Address self-repair on read: a missing, empty or non-T entry is regenerated
Tron master wallet generated by the same code, one per chain, a second refused
Master wallet disable switch, to stop signing on Tron without touching keys
The encrypted database blob is the only persisted copy of any key

Deposits

Two endpoints, three detection paths, and the credit at the end of them.

Native TRX detection on the TronGrid account-transactions endpoint
TRC-20 detection on the TronGrid transfer endpoint, filtered to the token's contract
Per-session polling every 30 seconds while a customer has the deposit page open
Randomised start delay, so ten pages opening at once are not ten simultaneous calls
Rate-limit backoff: doubling on a 429, tripling on a 403, capped at five minutes
A loop that shuts itself down after ten consecutive polling errors
Shared background scanner for addresses whose owner closed the tab, 72-hour working set
Per-chain scan rate for Tron, tunable — and the scanner switchable off entirely
Dust filter at 0.001 TRX and 1/10^(decimals−3) per token, counted and logged
Duplicate suppression: a 30-minute in-memory hash set plus a per-wallet database check
TRC-20 amounts matched on both recipient and emitting contract, so batches credit correctly
Big-integer amount formatting, exact above the 2^53 point a plain division loses
Credited on detection, with a 60-second watchdog behind it for anything that could not
Deposit page with the address, a QR code, a copy button and a Tronscan link
In-app deposit notification and a live push to the open deposit page
Unresolved deposits parked in a dead-letter set rather than dropped

Withdrawals

How a payout is sourced, signed, confirmed and — when it must be — held.

Native TRX payouts, signed from the customer's own address
TRC-20 payouts through transfer(address,uint256) under a 100 TRX fee ceiling
Destination validated as a Tron T… address before anything is debited
Pooled sourcing: any custodial wallet holding the token can fund the transfer
Source picked by highest available balance, net of what the private ledger claims
The draw recorded in the private ledger under a row lock, so concurrent payouts serialise
Token balance read from the contract itself rather than trusted from an indexer
A missing key rejected upfront on native TRX, before the balance is touched
New-recipient activation detected, with a 1 TRX figure recorded as metadata only
Informational cost estimate per payout — energy-based for TRC-20, bandwidth for TRX
The signed hash persisted before broadcast, so a crash leaves a recoverable row
On-chain receipt polled for up to 60 seconds; only SUCCESS becomes COMPLETED
Four terminal states: COMPLETED, FAILED, TIMEOUT and requeued PENDING
A row that already carries a hash is never relabelled FAILED, so no refund mints funds
Orphaned PENDING rows re-enqueued by a five-minute withdrawal watchdog

Energy, bandwidth and the gas budget

The accounting that decides whether a TRC-20 payout goes out at all.

Per-transfer energy simulated against live contract state before signing
A conservative 65,000-energy fallback when the simulation cannot run
The signer's live energy and bandwidth read from the node before any funding
Free daily bandwidth and staked or delegated allowance both counted
Burn prices read from the node's own chain parameters, refreshed every ten minutes
Sanity clamps on a malformed chain-parameter response, with last-resort defaults
Only the shortfall funded, with 20% headroom, topped up to a target not by a fixed amount
Idempotent top-ups — a retried payout re-reads the balance and sends nothing
The funding transaction confirmed before the transfer is built, for up to 90 seconds
An empty master wallet requeues the payout instead of failing and refunding it
Delegated resources honoured automatically: a covered signer is never topped up
The customer charged the amount plus the token's own fee, and never the TRX cost

Tokens and networks

Import any TRC-20 contract with its currency, decimals, precision and fee
Native TRX registered as a NATIVE token with no contract address
USDT, BUSD and TRX seeded on mainnet out of the box
A per-token fee denominated in the token — the only thing a customer is charged
Enable or disable a token without deleting it
Mainnet, Shasta and Nile
A per-network RPC full host, so a private endpoint can replace the public one
A TronGrid API key sent as a header on every RPC and REST call

Operations and diagnostics

What tells you the chain is ready before a customer finds out it is not.

Chain enable and disable from the Ecosystem blockchains screen
A licence file and a database toggle, checked together and read fresh, never from a cache
Recovery without a restart once an inactive chain is enabled
A requirements report naming the environment variables in force, set or not, with what each is needed for
Five live checks: network, node liveness, TronGrid REST and key, service installed, licence and toggle
Per-flow readiness for deposits and withdrawals, separate from the raw probes
Readiness downgraded by a locked vault or a missing or disabled master wallet
Master wallet live balance in the admin list, cached one minute
A private ledger browser covering every pooled draw
Verbose service-initialisation logging behind a single switch
Everything tagged TRON and TRON_DEPOSIT in the backend log
A safe-imported chain service: an install without the addon reports it absent, not a crash

Licence: Addon licence activated in the extension manager. Writes an encrypted, machine-bound lic/54577641.lic — re-activate after a server move.
Requires: Bicrypto core and the Ecosystem addon. Every path this uses — wallets, the vault, deposit monitoring, the withdrawal queue — lives in Ecosystem.
Runs on: Your own server, inside the existing Bicrypto backend. No extra process and no hosted tier.
Stack: One chain-service module added to the Node backend, using TronWeb and the TronGrid REST API.
External services: A TronGrid-compatible node endpoint, and a TronGrid API key on mainnet. No node of your own to run.
Extra database: None. No ScyllaDB on its own account; MySQL and the platform's existing Redis, which holds pending deposits between detection and credit.
Networks: mainnet, Shasta and Nile — one active at a time
Assets: Native TRX plus any TRC-20 contract you import. USDT, BUSD and TRX are seeded.
Derivation: m/44'/195'/0'/0/0, base58 T… addresses, one independent BIP-39 mnemonic per wallet
Admin surface: No screens of its own — driven from Ecosystem's Blockchains, Requirements, Tokens, Master Wallets and Ledgers screens.
Access control: No permission keys of its own. It uses Ecosystem's blockchain, token, master-wallet and vault keys.
Configuration: Six environment variables, all added by hand — none of them appear in .env.example.
Scheduled jobs: Three shared Ecosystem jobs act on Tron: the 60-second deposit watchdog, the five-minute withdrawal watchdog and the background address scanner.
Diagnostics: Five live checks and two readiness rows on the requirements console
No token deployment: Tron tokens are imported, never deployed. The deployment path covers EVM chains and Solana only, so USDT on Tron is a contract address you paste in.
No custodial deposit contracts: Every Tron deposit lands at the customer's own address. The shared custodial contract other chains use does not exist here and is not requested.
No staking, freezing or delegation: There is no freeze, unfreeze or resource-delegation path in the product. Staking TRX is an operator action taken outside the platform — the payout logic reads the result and stands down, but nothing in the admin panel will do it for you.
No confirmation-depth hold: A Tron deposit is credited when it is detected rather than after N blocks. That is faster and it is a weaker guarantee; if your risk model needs a depth rule, add a manual hold.
TRC-20 payouts stop when the gas tank is empty: Tron has no fee-payer primitive, so the platform must send TRX to whichever address signs. With the master wallet dry, TRC-20 payouts queue and retry — nobody is refunded — while native TRX payouts keep completing. Alert on that one balance.
The network variable is an outage, not a warning: TRON_NETWORK accepts mainnet, shasta and nile. Any other value throws while the service is being built and every Tron flow on the install is dead until it is corrected.
No key recovery and no reveal-seed screen: Each address is its own seed, so there is no master mnemonic to fall back on. Lose the vault key or its passphrase and every Tron key on the install is permanently unreadable — by you, by us, by anybody. Exporting one customer's mnemonic is a documented shell procedure, not a button.
Custody, not trading: This adds one chain. Markets, order matching, the withdrawal queue and the admin panel around them are Ecosystem's.