TRC-20 Approvals and Allowances

Token Standards on TRON covers how a TRC-20TRON's smart-contract standard for fungible tokens, derived from Ethereum's ERC-20: a compliant contract exposes transfer, approve, allowance, and transferFrom, and emits Transfer and Approval events. USDT on TRON is issued as a TRC-20 token. Because every TRC-20 transfer is a contract call, it consumes Energy (plus Bandwidth) and — unlike a TRX or TRC-10 transfer — cannot activate a not-yet-created account. transfer works — a contract call that moves value and hides its recipient in call data. This article covers the standard’s other half: approve() and the allowance, the mechanism by which a tokenA unit of value recorded inside a smart contract rather than in the chain's native ledger — the contract keeps the balance table, and moving tokens means asking the contract to update it. Not to be confused with a coin, which is the chain's built-in asset (TRX on TRON) used to pay for the network itself. owner hands a third party standing power over tokens the owner still holds. The grant itself moves nothing.

That last property is the investigative crux. An approval answers a different question than a transfer log does — who is able to move these tokens, whether or not anyone has. A wallet’sSoftware or hardware that stores private keys and uses them to sign transactions. A wallet holds keys, not coins — balances live on the ledger itself — so the same funds can be reached from any wallet loaded with the same keys, and losing the wallet loses nothing if the keys are backed up elsewhere. transfer history can be spotless while a counterparty holds live, exercisable authority over its entire balance. That authority is a control fact in its own right — worth reading whether or not the transfer history shows anything at all.

A grant, then a spend

The interface splits authority from movement. approve(spender, value) is the grant: TRON’s developer documentation describes it as one that “authorizes _spender (often a DApp contract) to transfer up to _value tokens from the caller’s account.” The signaturesA cryptographic proof, produced with a private key over a transaction's exact contents, that the key holder authorized that transaction and no other. Nodes verify the signature before accepting the transaction, so a valid signature is definitive evidence the key was used — though not of who was holding it at the time. are identical to Ethereum’s ERC-20Ethereum's fungible-token standard: a contract interface fixing a common set of functions (transfer, approve, transferFrom, balanceOf) and events (Transfer, Approval) so that every conforming token behaves identically for wallets, exchanges, and tooling. TRON's TRC-20 standard is a deliberate copy, which is why token mechanics on the two chains — allowances, transfer events, decimal scaling — read the same and why analysis concepts carry over directly. The name comes from Ethereum Request for Comments 20, the 2015 proposal by Fabian Vogelsteller and Vitalik Buterin., and the behavioral fine print comes from that origin standard, EIP-20: the spender may withdraw “multiple times, up to the _value amount,” and calling approve again overwrites the current allowance — the amounts do not add. One signature authorizes many possible spends.

allowance(owner, spender) is the read side — a constant query returning what the spender may still move. EIP-20 phrases it as “the amount which _spender is still allowed to withdraw.” It behaves like a budget the spender draws down, and any observer can query it.

transferFrom(from, to, value) is the exercise. The spender calls it — a separate transactionA signed instruction ("tx" for short) that changes on-chain state — transferring value, calling a contract, or updating an account's settings. Once it is included in a block and that block reaches finality the record is permanent: later transactions can supersede its effects, but the entry itself can never be edited or deleted. Before finality, a freshly included transaction can still be reversed if its block is reorganized out., signed by a different party, possibly long after the grant — and it moves tokens out of the owner’s balance against the standing allowance. Every successful approve also emits an Approval(owner, spender, value) event with the owner and spender as indexed topics, which is what makes a target’s grants enumerable: filter the token’s event log on the owner addressA public identifier, derived from a key pair, at which an account receives funds and is looked up on-chain. Anyone can view an address's history, but only the matching private key can spend from it. TRON addresses are 34-character Base58Check strings beginning with "T". and the wallet’s approval history falls out.

EIP-20’s own rationale flags the maintenance burden this design creates: re-approving is not additive-safe, so the standard advises clients to set an allowance to zero before setting it to a new value. Nothing in the protocol expires a grant on the owner’s behalf. Allowances need active hygiene, and stale non-zero grants accumulate in wallets whose owners have long forgotten signing them.

Unlimited and bounded allowances

The convention for “unlimited” is a single approve that sets the allowance to the largest value a 256-bit integer can hold — type(uint256).max in Solidity, 2^256 − 1. The OpenZeppelin ERC-20 reference implementation treats that sentinel specially: when the current allowance equals the maximum, transferFrom skips the decrement entirely. The implementation’s own comment states that it “does not update the allowance value in case of infinite allowance.”

A bounded allowance runs the other branch. Each transferFrom checks the requested amount against what remains, reverts if it exceeds the remainder, and writes back the decremented value.

Those two branches produce two different objects. A bounded grant is a finite budget that extinguishes itself — every spend shrinks it, and it ends at zero. An unlimited grant never shrinks. It stands, undiminished across any number of spends, over the owner’s entire balance — including tokens the wallet hasn’t received yet.

How an approval reads on-chain

On TRON, approve() arrives as a TriggerSmartContract transaction — the same envelope as any TVM contract call, covered in Smart Contracts and the TVM. TRON’s documentation on TRC-20 interaction notes that these state-changing calls consume BandwidthA TRON network resource that covers the byte-size cost of putting a transaction on chain — one byte consumes one Bandwidth point. Every account receives a small free daily allowance (also called free bandwidth); heavier usage requires staking TRX, receiving a delegation, or burning TRX to cover the bytes. and EnergyA TRON network resource that meters the computational cost of smart-contract execution, consumed whenever a transaction calls contract code — including TRC-20 token transfers such as USDT. An account obtains Energy by staking TRX or receiving a delegation from another account; if it holds too little, the shortfall is paid by burning TRX from its balance., and that they carry a fee_limit — “Maximum TRXThe native coin of the TRON network. TRX settles value directly (no contract call needed), is staked to obtain Energy, Bandwidth, and voting power, and is burned to pay fees when staked resources fall short. Its smallest unit is the sun: 1 TRX = 1,000,000 sun. consumption allowed in this call, in sun.” The full cost mechanics belong to What a Transaction Actually Costs; what matters here is the mismatch. The owner pays Energy to execute code that transfers nothing. The transaction’s entire output is a write: a control action, not a value action.

What that write produces is the allowance itself, stored in the token contract as a nested mapping — owner address to spender address to amount, in OpenZeppelin’s layout mapping(owner => mapping(spender => uint256)). Anyone can read it at the current block. And it stays: a bounded allowance ends when it is spent down, any allowance ends when the owner re-approves it to zero, and nothing else touches it. The approval is stored state, and nothing in the protocol expires it. A grant signed years ago is still a live, queryable fact about who controls a balance today.

The lingering approval as evidence

A non-zero allowance held by a counterparty means that counterparty can move the owner’s tokens right now, by signing a transferFrom of its own. The owner does nothing further. That is a control relationship in the plainest sense, and it is exploited in the wild: security researchers at CYFIRMA documented a QR-code phishing campaign targeting USDTA US-dollar stablecoin issued by Tether, first launched in 2014 on Bitcoin's Omni Layer and circulating on TRON as a TRC-20 token since April 2019. Tether retains privileged functions in the token contract — it can blacklist addresses and destroy blacklisted balances — so every USDT balance is ultimately conditional on the issuer's authority. Not to be confused with counterfeit tokens that copy the USDT name and symbol without any issuer or backing. on BNB Smart Chain via Trust Wallet that “covertly triggers an ERC-20 approve() transaction, granting unlimited token allowance to an attacker-controlled contract” — the advisory describes the result as “persistent access, allowing attackers to drain funds from victim wallets without further interaction,” exposing “both current and future USDT balances.” The mechanism is identical wherever a chain runs an ERC-20-style approveA standing grant recorded in a token contract: the holder calls approve to let a designated spender later move up to a set amount of their tokens via transferFrom, and allowance reports how much of the grant remains. An approval is a live control relationship — it persists until changed, and an "unlimited allowance" (a common dApp convenience) lets the spender drain the full balance at any time, which is exactly the mechanism wallet-drainer phishing abuses./transferFrom pair, TRON’s TRC-20 included, even though this particular documented campaign ran on BNB Smart Chain, not TRON. The same report stresses that the attack requires no wallet vulnerability at all. The victim authorizes the grant; the protocol does exactly what it was asked.

None of this registers at the transfer level. Until the spender acts, no tokens have moved, and an explorer’s transfer tab for the wallet shows an ordinary history. The evidence is the standing grant — the Approval event in the token’s log and the non-zero entry in its allowance mapping. Reading it is a control determination: it identifies who holds signing power over the balance.

This is why the unlimited-versus-bounded distinction is worth reading closely. An unlimited grant is a categorically stronger control fact than a bounded one: it is unmetered, it survives every spend, and it covers balance the wallet has yet to receive. A bounded grant caps the spender’s reach and destroys itself as it is used. A careful reading of a wallet’s outstanding approvals weighs that standing authority accordingly.

For an investigator, the working habit is to treat approvals as a first-class query alongside the transfer history. Enumerate the target’s Approval events, resolve each spender’s current allowance, and read what remains: every non-zero entry is a party that can move the wallet’s tokens today, and every unlimited entry is a party that can move all of them, indefinitely. The transfer graph tells you where value went; the allowance table tells you whose signature can still send it.

Sources

• TRON Developer Hub — TRC-20 Protocol Interface — the approve/allowance/transferFrom signatures, the authorize-a-third-party definition, and the Approval event.
• EIP-20 — Token Standard — the identical-signature origin standard: standing multi-spend authorization, overwrite-on-reapprove, and the set-to-zero-first rationale.
• OpenZeppelin ERC-20 reference implementation — the infinite-allowance (type(uint256).max) non-decrement behavior in _spendAllowance and the nested allowance storage mapping.
• TRON Developer Hub — TRC-20 Contract Interaction — approve() as a triggersmartcontract call that consumes Bandwidth and Energy and carries a fee_limit.
• CYFIRMA — Silent Crypto Wallet Takeover: Unlimited USDT Approval Exploitation — security-research advisory documenting the real-world approval-drain attack pattern; the campaign it documents targeted USDT on BNB Smart Chain via Trust Wallet, not TRON, cited here for the generic approve()-drain mechanism, which is identical across any ERC-20-style chain including TRC-20. A user-facing threat report rather than official protocol documentation.
• smart_contract.proto — tronprotocol/protocol — the protocol definition of TriggerSmartContract (owner_address, contract_address, call_value, data, call_token_value, token_id) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.