Choosing a TON wallet is mainly a security decision. The important questions are not how polished an interface looks, but who controls the keys, how access can be restored, what a connected application is allowed to request, and how you will respond when something looks wrong. This guide compares the main custody models and gives a repeatable process for using a wallet without relying on outdated product claims.
Start with the custody boundary
A custodial wallet is an account operated by a service. The provider controls the signing system or keeps the keys on your behalf. You authenticate with an account, and the provider decides how deposits, withdrawals, verification, recovery, and freezes work. This model can be convenient, but access depends on the provider, its security, its availability, and its terms.
A self-custodial wallet gives control to a recovery phrase or private key. The application is an interface that derives addresses and signs messages; it cannot restore a lost phrase. Anyone who obtains the phrase can generally control the account. A support employee, moderator, or application should never ask for it.
The distinction can be confusing inside Telegram. Wallet and a self-custodial TON wallet may appear in related menus, while their recovery and transaction models remain different. Do not infer custody from a brand name, an icon, or the fact that a service opens inside Telegram. Read the current terms and inspect where the recovery material is created.
Choose according to the threat model
For a custodial service, consider account takeover, phishing, provider outage, withdrawal restrictions, identity checks, and the consequences of a frozen account. Use a unique password, protect the email or Telegram account used for access, and enable every strong authentication method the provider supports. Treat links in private messages as untrusted.
For self-custody, consider theft or loss of the recovery phrase, malicious wallet software, an infected device, clipboard replacement, fake support, and unsafe contract approvals. A hardware wallet can reduce exposure of keys, but it does not make a wrong recipient or malicious approval safe. The screen you approve still matters.
Keep separate wallets for separate purposes when practical. A wallet used to explore unfamiliar applications should not automatically hold funds needed for important obligations. Separation limits exposure, but it does not replace checking a request.
Backup and recovery drill
Back up a self-custodial wallet before receiving anything important. Write the recovery phrase on a durable offline medium. Do not photograph it, put it in cloud storage, send it in a chat, or type it into a support form. Store the backup where it is protected from casual access and physical damage.
A backup is not proven until you understand recovery. Read the provider's official instructions, confirm the wallet type and network, and practise restoring an empty wallet on a clean device only when the procedure is clear. Never reveal the phrase during a demonstration. Compare the restored public address with the original address, then remove the test wallet and its temporary records.
Recovery phrases can derive several accounts, and different wallet applications may display different address formats or account indexes. If a restored wallet appears empty, do not assume the funds are gone: first verify the network, account path, and address representation using official documentation. Do not keep guessing with a phrase copied into random software.
Address verification and watch-only access
A public address is safe to share for receiving, but it is not proof that a message came from the owner. A watch-only view can display balances and transactions without holding a signing key. It is useful for monitoring, accounting, or checking an address on a device that is not used to sign.
Watch-only access does not authorise spending. Before adding an address, obtain it from a trusted wallet screen or a documented source, then compare the full value or a sufficiently long beginning and ending portion. Clipboard malware can replace an address between copying and pasting. Verify the destination on the final wallet confirmation screen.
An address may be valid while still being the wrong address. A successful network confirmation only proves that the network accepted the instruction; it does not prove that the intended person or service received it.
Network and token identity
TON is a network; a token ticker is not a network identifier. The same symbol can refer to different contracts or representations. A receiving service may support one version and reject another. Select the asset and network from the receiver's deposit instructions, and compare them again in the sending wallet.
For a token, verify the contract address through the issuer's official documentation or the receiving service's verified interface. Do not trust a search result, forwarded post, or a token name that merely resembles a familiar one. A token can imitate a logo and ticker while having no connection to the expected issuer.
Reading a TON Connect request
TON Connect links a wallet to a website or Telegram Mini App. The protocol can expose the connected address and request signatures or transactions; it does not hand the private key to the application. That boundary is valuable, but it is not a trust certificate for the application.
Before connecting, check the domain, application identity, requested network, and purpose. Before signing, read the recipient, amount, payload, operation type, and any expiry or permission shown by the wallet. A connection request, a message signature, a token approval, and a transfer are different requests. If the wallet cannot explain what will happen, cancel it.
A message signature may prove control of an address without moving funds, but it can still be used as authorisation by an application. A token approval can permit later spending by a contract. Disconnecting the application does not necessarily revoke that approval; use the wallet or contract's supported revocation mechanism.
Contract and phishing traps
Scam applications often create urgency, promise a reward, or claim that a wallet must be “verified” by entering its recovery phrase. Real wallet software does not need a phrase to validate a public address. Never approve a transaction solely because a channel administrator or a pop-up calls it official.
Inspect the destination and contract details, not just the visible button label. Be cautious when a request asks for broad token permissions, an unfamiliar contract, or a signature with no readable explanation. If a site changes domain, stops showing its policy, or asks you to disable security controls, leave it and verify the project through its official documentation.
Incident response
If you approved an unexpected request, stop interacting with the application. Record the transaction hash, contract, recipient, network, and time. Disconnect the application and investigate whether an approval can be revoked. Use a clean device for recovery actions and consult only official support channels.
If the recovery phrase may have been exposed, treat the wallet as compromised. Create a new wallet from verified software, secure its recovery material offline, and move remaining assets only after checking the destination. Do not wait for a suspicious transfer if the key is known to be exposed.
If a transfer is missing, do not send another one immediately. Check its status in a TON explorer, verify the network and address, and compare the receiver's deposit rules. Support may request a public address and transaction hash; it must not request the recovery phrase, private key, password, or remote access to your device.
A repeatable selection checklist
- Who controls the signing key?
- What happens if the provider, Telegram, or your device is unavailable?
- Where is recovery material created and how is it backed up?
- Can you restore an empty wallet and verify its public address safely?
- Is the destination address copied from a trusted source?
- Do asset, contract, network, and memo match the receiver's instructions?
- Is the TON Connect request a connection, signature, approval, or transfer?
- Can you read the recipient and payload on the confirmation screen?
- Are experimental applications isolated from important funds?
- Do you know the official incident and support procedure?