Why Tron wallet/getaccount returns an empty object

Last updated: September 22, 2026

At a glance

What you see

You call Tron's native wallet/getaccount for an address you can see holding a balance on a block explorer or in a wallet app, and the response comes back HTTP 200 with a body of {} — no error field, no non-2xx status, just an empty JSON object. By every visible signal the request succeeded: the endpoint accepted it and answered with a schema-valid body.

Why this happens

Tron's wallet/getaccount reference documents that addresses default to the native 21-byte hex form beginning with 41, and that a Base58 address is accepted only when visible is set to true; a mismatched pair — a Base58 address sent with visible omitted or false, or a hex-41 address sent with visible: true — can produce an empty object rather than an explicit error. Tron's own wallet-error notes generalize this beyond getaccount alone: an empty response from any native wallet/* method can indicate the same hex-41/Base58 mismatch with visible, rather than the address being absent from the chain. The two situations that produce this — an address that genuinely holds no account state, and an address sent in the wrong encoding for the visible flag paired with it — return the identical {} body; nothing in the response distinguishes them. This is specific to Tron's native wallet HTTP surface: the EVM-compatible eth_* layer on the same network (eth_getBalance and the rest) takes only a single 0x-prefixed 20-byte address form, so this particular mismatch does not exist there — a malformed address on that layer is an explicit JSON-RPC error, not a silent empty result.

What to do

1. Check which form the address you sent is actually in: a hex-41 address starts with 41 followed by 40 hexadecimal characters; a Base58 address — the form shown by a block explorer or a wallet app — starts with T and has no 41 prefix.
2. If the address is Base58, set visible: true explicitly on the same request. If the address is hex-41, leave visible unset or false — do not send true together with a hex-41 address.
3. Confirm the JSON field name matches the method you're calling before touching visible: wallet/getaccount takes the address in address, while a neighboring method like wallet/getcontractinfo takes it in value. Sending the right encoding under the wrong field name reproduces the same empty object.
4. Re-run the call with the corrected address/visible pair before concluding anything about the account. Only treat {} as a genuinely empty account once the encoding and visible are confirmed to match.
5. If you only need a balance and want to avoid the native address format entirely, eth_getBalance on the same network's EVM-compatible layer takes a single 0x-prefixed address and answers a malformed one with an explicit error instead of a silent empty result.

When this is not our problem

An empty object for a mismatched address/visible pair is not a Triport-side bug to report: it's how Tron's native wallet/* HTTP API is documented to behave — the encoding rule and the empty-object outcome belong to the wallet-layer address format itself, not to anything Triport's routing does with the request. Sending the corrected pair is the fix, not filing a report.