💬 Why different TON addresses?
TON addresses can be represented in multiple formats depending on the purpose and the network type (Mainnet vs Testnet). The key reasons for these variations are:
- Bounceable and Non-Bounceable Addresses: Designed to indicate whether or not the recipient address can “bounce” a transaction back if the destination wallet is not initialized.
- Network-Specific Formats: To differentiate between the Mainnet (production) and Testnet (development) networks.
- Raw and Friendly Formats:
- Raw: A technical, low-level format of the address (e.g., 0:fe or -1:fe).
- Friendly: A more user-friendly format, often encoded in Base64, with optional safety flags.
These differences help users and applications handle addresses correctly and avoid mistakes like sending funds to a Testnet wallet or an uninitialized bounceable address.
💎 Types of TON wallets
Bounceable and Non-Bounceable
- Bounceable (with Bounce Flag):
- Default for wallet addresses.
- Allows the funds to “bounce back” if the recipient’s wallet is not yet initialized.
- Commonly used for user wallets.
- Non-Bounceable (without Bounce Flag):
- Prevents “bouncing” of transactions back.
- Typically used for smart contracts or scenarios where transactions must not fail.
Example:
- Bounceable (Friendly):
EQ... - Non-Bounceable:
UQ...
Mainnet and Testnet
- Mainnet: Used for real transactions with actual Toncoin.
- Bounceable starts with
EQ... - Non-Bounceable starts with
UQ...
- Testnet: Used for testing transactions with test Toncoin.
- Bounceable starts with
kQ... - Non-Bounceable starts with
0Q...
This separation ensures users don’t accidentally send real funds to test wallets or vice versa.
Raw Format
- A technical, hexadecimal representation of the address.
- Structure:
workchain:hash.
Example:
0:fe2345a67b...(workchain 0, Mainnet)-1:abcd1234...(workchain -1, used for smart contracts).
Friendly Format
- A Base64-encoded address designed to be human-readable.
- Includes flags for bounceability and test network detection.
Example:
- Bounceable (Mainnet):
EQD... - Non-Bounceable (Mainnet):
UQD... - Bounceable (Testnet):
kQD...
| Type | Purpose | Format | Prefix |
|---|---|---|---|
| Mainnet Bounceable | Real wallets, bounceable | Friendly (Base64) | EQ... |
| Mainnet Non-Bounce | Real wallets, non-bounceable | Friendly (Base64) | UQ... |
| Testnet Bounceable | Test wallets, bounceable | Friendly (Base64) | kQ... |
| Testnet Non-Bounce | Test wallets, non-bounceable | Friendly (Base64) | 0Q... |
| Raw Format | Low-level representation (workchain) | Hexadecimal: workchain:hash | 0: or -1: |
👀 Why do Bounceable and Non-Bounceable exist?
- Bounceable Addresses: Safe for wallets that might not be initialized yet. Funds can “bounce back” if the recipient wallet doesn’t exist.
- Non-Bounceable Addresses: Used for smart contracts where the transaction must not fail or “bounce,” even if the destination is uninitialized.
🧠 How it helps
- Different prefixes (
EQ,UQ,kQ,0Q) clearly indicate the network type and bounceability. - Non-bounceable addresses ensure smart contracts execute without failure.
- Testnet prefixes like
kQprevent accidental use of test funds in production.
Overall, TON Wallet addresses are flexible to improve usability, security, and clarity. The key differences are:
- Mainnet vs Testnet for network isolation.
- Bounceable vs Non-Bounceable for handling uninitialized wallets.
- Raw vs Friendly for technical vs human-readable usage.