TRON Return Value: 3 Important Fields in a SUCCESS Receipt

A TRON return value is output bytes interpreted under a function’s ABI; it is not the same field as transaction execution status. In one saved token-call receipt, a 32-byte zero word decoded as false under a later provider-supplied bool ABI, while receipt.result was SUCCESS and one log was present. Those observations must remain separate.

This guide helps a developer or record reviewer avoid treating any nonempty output as true, any zero word as a failed transaction, or an unavailable result as false. We checked the saved public record and local readers on November 3, 2026. No wallet, signing, simulation, transaction submission or balance-changing call was used.

Four critical return value checks

1. Identify the output schema. Match the method and its declared outputs before decoding bytes.
2. Preserve the exact return word. Empty, missing and a full zero word are different inputs.
3. Separate receipt status and logs. Do not rename one field as another field’s conclusion.
4. Record the evidence limit. A later ABI read is not a historical bytecode audit or a balance-delta proof.

The TRC20 standard tells callers to handle a false Boolean return rather than assuming it can never occur. That requirement does not turn a function output into the receipt’s execution-status field. Our actual record makes this distinction concrete without claiming why the output bytes had their observed value.

The actual return value, receipt and later ABI

The saved transaction was 318a21c143dc69b1beb0140bbe1222cbe31f5719c1766aa970806b07121d3415 in block 87669202. Its type was TriggerSmartContract and the method data began with a9059cbb. We locally recomputed that selector from transfer(address,uint256). A separate public receipt read returned the fields summarized below.

We obtained the ABI with a read-only wallet/getcontract request for 41a614f803b6fd780986a42c78ec9c7f77e6ded13c. Its transfer entry declared address and uint256 inputs and one bool output. We preserved the full response and its observation time. We did not independently audit deployed source or establish the ABI applicable at every historical block.

Under that supplied ABI, both TronWeb 6.5.1’s decoder and our strict local reader returned false for the saved zero word. This is a conditional decoding result: if the supplied output schema is unsuitable for the historical execution, its semantic interpretation needs further review. The raw bytes and their provenance remain useful even when an ABI question is unresolved.

A return value needs its declared type

The Solidity ABI specification describes typed encoding and Boolean values restricted to zero and one. An encoded return value does not carry a human-readable type label. A zero word interpreted as uint256 is the integer zero; interpreted as bool it is false. Selecting a type by which story seems plausible is not decoding.

Function output also does not include the input method selector as a prefix. Our strict reader expects one complete 32-byte word after an optional 0x marker, not input calldata with a selector attached. Keeping input and output separately labelled prevents a method-hash-stripping option from being applied without checking the artifact’s shape.

A nonempty contractResult array is insufficient on its own. Inspect the selected element, its length, the method declaration and the relevant record. An empty string in an array is not a complete zero word. A missing array is not an empty array, and none of those unavailable shapes should silently become Boolean false.

Our fourteen-case strict return value reader

The following local function implements a deliberately narrow policy: exactly one declared bool output and exactly one canonical output word. It does not authenticate an ABI, validate a receipt, recover a signer or decide whether a transfer moved value.

function readBoolReturn(outputs, word) {
  if (!Array.isArray(outputs) || outputs.length !== 1 || outputs[0].type !== 'bool')
    throw new Error('Need exactly one declared bool output');
  if (typeof word !== 'string') throw new Error('Need a returned byte string');
  const hex = word.replace(/^0x/, '');
  if (!/^[0-9a-fA-F]{64}$/.test(hex)) throw new Error('Need exactly one word');
  const value = BigInt('0x' + hex);
  if (value !== 0n && value !== 1n) throw new Error('Noncanonical bool');
  return value === 1n;
}

Fourteen synthetic cases covered canonical false, canonical true, noncanonical integer two, empty text, null, numeric zero, an optional 0x prefix, 31-byte and 33-byte strings, non-hex text, a Boolean primitive, no output declaration, a uint256 declaration and multiple bool outputs. Every case matched its declared local expectation.

The successful zero-word return value fixture was a complete string under a bool schema. The numeric zero and null fixtures were rejected. These are different runtime types, not different spellings that this reader can safely normalize. This policy helps keep an unavailable return value from becoming a confident negative result in a dashboard.

Return value decoders differ on the synthetic integer two

We also supplied a synthetic word ending in 02 to TronWeb 6.5.1’s ABI decoder. In that local test, the installed decoder returned true. Our strict reader rejected it because its canonical bool policy accepts only integer zero or one. The synthetic word was not another live transaction output.

This comparison describes a named version and a single local fixture. It is not a claim that every decoder behaves the same way or that our reader is a complete ABI implementation. Applications should state their acceptance policy and test the installed version rather than assume a permissive truthy conversion and a canonical Boolean check are identical.

The actual saved return value was zero and both readers agreed on false under the supplied ABI. The noncanonical-two test therefore did not change the actual observation. It provides a separate regression case for the validation policy, with the original output preserved unchanged.

SUCCESS, false and a log do not answer one question

Our receipt had execution status SUCCESS, a zero return word and one returned log. We did not overwrite one observation to make all three look consistent with a single payment label. A return value is an application-level output under a schema; the execution label and event record have their own roles.

We did not reconstruct account balances before and after the block or audit the historical token implementation. Consequently, this article does not conclude that a customer received funds, failed to receive funds or received an exchange credit. The first log’s saved data decoded as raw integer 1256000000, but that isolated integer is not a complete economic audit.

Nor do we infer the reason for the zero word. Possible implementation, ABI and provider questions need evidence beyond these retained reads. A return value review can preserve an apparently surprising combination without inventing a cause. Keep the unresolved question explicit rather than applying a universal “zero means failure” shortcut.

Repeat this return value review without a wallet

1. Save the original public transaction body and matching receipt, including full identifier and network.
2. Record the type, contract address, input selector, receipt status, output bytes and logs in separate columns.
3. Obtain and preserve the target’s ABI source and read time. Match the method’s canonical input signature and declared outputs.
4. Run the appropriate local return value decoder with the unchanged output, keeping missing and malformed inputs as errors.
5. State whether historical ABI correctness, bytecode behavior and balance changes were actually checked. Our review did not establish them.

Our actual receipt endpoint was wallet/gettransactioninfobyid; the later metadata endpoint was wallet/getcontract on api.trongrid.io. These were anonymous public reads, not new calls to transfer. Provider availability and limits can change. A failed request is unavailable evidence for that attempt and must not be replaced with a fabricated false return value.

Success for this worksheet is an exact, reproducible interpretation under a named output schema, with the execution status and remaining questions preserved. It does not require another transfer to test a theory. Retain the source response before creating local malformed-word fixtures, and keep every derivative separate.

Choose the next evidence task

Use the missing-ABI read-only worksheet when metadata is unavailable or ambiguous, the event-log guide for the independent log schema, and the TRON USDT record guide for asset and transfer context. Those tasks remain necessary even after a return value decodes without an exception.

Frequently asked questions

Does receipt SUCCESS mean the return value is true?

No. Our saved receipt reported SUCCESS while its zero word decoded as false under the supplied bool ABI.

Was historical ABI correctness proved?

No. We preserved a later provider-supplied ABI and stated that limit rather than certifying historical bytecode behavior.

Does the false interpretation prove that funds did not move?

No. We did not reconstruct balance changes or a receiving service’s ledger.

Can a zero word be decoded as bool without an ABI?

The bytes need a justified schema. The same zero word can represent other types; do not pick bool by intuition.

Did the fourteen tests broadcast a transaction?

No. They were local output-shape and schema fixtures. The actual record was an existing public transaction.

Independent Tronscan News tutorial with AI assistance, checked November 3, 2026. Original evidence includes a retained token-call record, receipt and later ABI, one actual installed-client decode, fourteen strict-reader fixtures, one separate noncanonical SDK comparison and two diagrams. The Tronscan News homepage links to standards and corrections.