TON Address

Overview

A TON internal address combines a workchain identifier with account-address bits. It can be displayed as a raw workchain-and-hex value or a user-friendly base64-style string carrying checksum and flags. User-friendly forms may indicate bounceable or non-bounceable behavior and test-only status, yet different strings can refer to the same underlying account. Address behavior also depends on whether the destination account is uninitialized, active, frozen, or deleted.

Wallets must validate checksum, workchain, flags, network, and destination status before sending. Non-bounceable forms are often used when initializing accounts, while bounceable transfers can return value after certain failures. Applications should store the canonical underlying address and treat formatting flags as transaction guidance, not separate account identities. Higher-value transfers benefit from an independent destination check rather than reliance on shortened display text. Testing for TON Address should include valid and invalid examples, wrong-network values, boundary encodings, contract destinations, and any memo or tag requirements.

TON Address must be interpreted with its network, address or account type, encoding rules, and any required routing fields. A string that passes a format check can still belong to the wrong chain, unsupported asset, contract type, or destination that requires a memo or tag.

Authorization depends on keys, scripts, contracts, or protocol rules, while custodial systems may expose an identifier without giving the user direct control of the underlying account. TON Address is an identifier or spendable object, not proof of legal ownership and not a secret credential. Settlement consideration: TON address strings can encode the same account with different flags, so workchain, checksum, bounceability, and status all matter.