> ## Documentation Index > Fetch the complete documentation index at: https://docs.cryptocheckout.ai/llms.txt > Use this file to discover all available pages before exploring further. # TRON > Every way TVM differs from EVM in ways that have caused real errors, and the numbers that follow. TVM energy equals EVM gas unit-for-unit. TRON is not computationally more expensive; it is **priced** more expensively. Every EVM optimisation transfers directly, at roughly 2,700× the stakes. | Operation | EVM | TVM | Apart | | ---------------- | ----------- | -------------- | ----- | | Forwarder deploy | 396,963 gas | 397,324 energy | 0.1% | | Sweep | 54,383 gas | 54,319 energy | 0.1% | | Pool deploy | 864,090 gas | 845,419 energy | 2.2% | That similarity is a trap. It makes porting EVM reasoning feel safe, and it has produced at least three published errors. ## Five differences that matter Bandwidth is a separate resource at 1000 sun per byte and is untouched by any rental. A full pool deploy is roughly 5,148 bytes — about \$1.69 of bandwidth that survives any rental strategy. **Any figure derived by scaling a burn price to a rent price is suspect.** One issue was wrong by \$1.67 on the pool deploy this way by applying the forwarder's \~680-byte transaction size to a \~5KB contract deploy. The TVM hardfork matrix gates Constantinople, Istanbul, London, Shanghai, Cancun, and Blob. **There is no Berlin gate**, confirmed against live chain parameters. TIP-1884/2929 remains a proposal. The TVM opcode spec prices `DELEGATECALL` at **40 energy** base, not 2,600. Do not port EVM cold/warm gas reasoning to TVM — a proxy overhead assumed at 2,661 is roughly 18× too high. If one contract burns more than 5×10⁹ energy in a six-hour maintenance period, its energy cost is multiplied. The factor compounds by 20% per period to a maximum of 3.4, giving a **total multiplier up to 4.4×**. It decays at a quarter of the increase rate. Live mainnet parameters: `getAllowDynamicEnergy` 1, threshold 5,000,000,000, increase factor 0.2, max factor 3.4. Consequence: a fresh contract has `energy_factor = 0`, so per-merchant pools and per-invoice forwarders are DEM-immune by construction. Any **shared** contract — an EIP-1167 implementation — concentrates the risk. Model this explicitly whenever a shared contract is proposed. Merchants sign their own pool deploy and their own claim from their own wallet, so they cannot use the platform's rented energy. `DelegateResource` could change that, but then the platform pays — which defeats the purpose of a merchant-paid gate. `keccak256(0x41 ++ address ++ salt ++ keccak256(init_code))[12:]`, not `0xff`. Re-proving this derivation on Nile is a **hard gate** before any address is shown as a QR. A prefix or bytecode mismatch strands funds permanently. It was proven on 2026-06-19 for the current init code and must be re-run for any new one. Other TVM differences worth knowing: accounts have **no nonce** (replay protection is TAPOS, and transactions expire 60 seconds after construction by default); there is an 80 ms wall-clock execution cap per transaction with no EVM equivalent; `CHAINID` returns the last four bytes of the genesis block hash rather than a constant; and a `TransferContract` TRX transfer bypasses the contract's fallback entirely. ## Cost of one full deposit-rail order At TRX \$0.3274, `getEnergyFee` 100 sun, `getTransactionFee` 1000 sun per byte. | | Burn (100 sun) | Rent (40 sun) | | --------------------- | -------------- | ------------- | | Today, deploy + sweep | **\$15.01** | \$6.14 | | Clone forwarder | \$4.25 | **\$1.84** | Rent modelled at 40 sun, the conservative end of the 60–80% discount band. ## Pool deploy, what the merchant pays | | Burn | Rent | | ----------- | ----------- | ------- | | Full deploy | **\$29.37** | \$12.76 | | Cloned pool | \$2.37 | \$1.02 | The merchant pays the **burn** column. The pool is not cloned — see [Clone decisions](/economics/clone-decisions) — so the real number is \*\*$29.37**, dropping to roughly $27.30 once the reward code is stripped. ## Operation costs, individually Measured from real Nile factory transactions rather than EVM approximation, at burn: | Operation | Cost | | ---------------- | ------- | | Forwarder deploy | \$13.56 | | `distribute()` | \$2.74 | | `sweep()` | \$1.86 | | `claim()` | \$1.77 | | `deposit()` | \$1.37 | ## Sanctions screening deviates on TRON There is **no Chainalysis on-chain oracle on TRON** — it is EVM-only — so `T…` addresses cannot use the standard oracle path. The forced alternative is two keyless, identity-blind, fail-open layers: Tether's `isBlackListed` on-chain read via TronGrid, and TRM Labs' free keyless Sanctions API for OFAC parity. This is a documented deviation from the EVM oracle-only stance and gates TRON **mainnet** only. See [Sanctions](/compliance/sanctions). ## Open TRON questions * **DEM attribution.** Does the Dynamic Energy Model attribute delegatecall energy to the implementation or the proxy? Unresolved by the docs and by TIP-491, whose worked example uses `CALL`. Blocks the per-customer forwarder design. * **`consume_user_resource_percent`.** Can the contract carry a share of the customer's energy, making TRON checkout free for the payer? If so, the connect-rail tax moves onto the platform and several decisions shift. * **Energy rental sourcing.** The effective sun-per-energy must be read live — rental quote when active, burn rate on fallback. A floor computed at the burn rate is about 2.5× too conservative and refuses business the platform can serve profitably.