Wallets comparison
Unlike some other blockchains, wallets in TON are regular smart contracts. Each version defines its message format, replay protection, and optional features. For instance, Wallet V5 supports gasless transfers, while Highload Wallet v3 supports frequent batch transfers.
Comparison table
| Feature | V4 | V5 | WalletTg | Highload v3 | Preprocessed v2 | Multisig |
|---|---|---|---|---|---|---|
| Seqno1 based | ✅ Yes | ✅ Yes | ✅ Yes | ❌ No (query_id based) | ✅ Yes | Contract-specific |
| Messages per request/batch | Up to 4 per request | Up to 255 per request | Up to 255 per request | Up to 254 per batch | Up to 255 per request | Contract-specific |
| Query-ID capacity | — | — | — | 8,380,416 possible values4 | — | Contract-specific |
| Multi-owner | ❌ No | ❌ No | ❌ No | ❌ No | ❌ No | ✅ Yes |
| Message cost | Standard | Standard; optimized for more messages per request | Lower for up to 5 messages per request, then Standard | Lower; depends on batch size | Lowest3 | Contract-specific; signatures add verification work |
| Support plugins | ✅ Yes | ✅ Yes | ❌ No | ❌ No | ❌ No | ❌ No |
| Support gasless2 | ❌ No | ✅ Yes | ✅ Yes; relay is required | ❌ No built-in support | ❌ No built-in support | Contract-specific |
| Subwallet ID | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes | ❌ No | Contract-specific |
| Signing-key rotation | ❌ No | ❌ No | ✅ Yes; address stays the same | ❌ No | ❌ No | Contract-specific |
| Implementation | Per-account code | Per-account code | Trampoline; shared implementation code in validator-governed config | Per-account code | Per-account code | Contract-specific |
1 A sequence number (seqno) is a stored counter used for replay protection. Request-consumption behavior varies by contract.
2 A gasless request lets a relayer submit an owner-authorized request. WalletTg requires enough attached Gram for compute; its existing balance can fund outgoing values and fees. The contract does not provide a relayer service.
3 1,537 gas units per transaction, which forms the lowest compute fee. Network fees also depend on message forwarding, storage, and the actions in a request.
4 Highload v3's 8,380,416 query IDs are possible identifiers, not a throughput guarantee.
Use cases
Retail users
Most wallet apps use Wallet V5R1 by default when creating wallet accounts, while Telegram uses WalletTg. Other wallet apps need to support Telegram's wallet request format and key-management rules to import and operate the account, but they should default to using the wallet V5.
When starting in the TON ecosystem, use either Telegram Money or a modern wallet app that supports both Wallet V5 and WalletTg contracts.
Use for:
- Buying stablecoins: Purchase USDT and other stable assets.
- Trading jettons: Swap tokens on decentralized exchanges and participate in decentralized finance (DeFi).
- Daily payments: Send and receive Gram and jettons.
- NFT collecting: Buy, sell, store, and transfer non-fungible tokens (NFTs).
- Staking: Stake Gram through a staking service and earn rewards.
- dApp interactions: Connect to games, social apps, and other decentralized applications (dApps) through TON Connect.
- Savings: Hold TON-based assets for long-term storage.
Read more:
Shared custody
Multisig contracts distribute transaction approval across key holders. In a threshold design, an order executes after it collects the configured number of signatures.
Multisig contracts are best for managing institutional funds, treasury assets, or any situation requiring shared custody.
Key benefits:
- Shared responsibility: A threshold above one can prevent a single signer from authorizing a transfer if the contract has no alternate authorization path.
- Configurable thresholds: Use a threshold such as 2-of-3 when the implementation supports it.
- Auditability: Pending orders and approvals may be recorded on-chain; visibility depends on the implementation.
- Reduced single-key risk: A threshold can remain usable after key loss if enough signers remain, but does not prevent collusion or every operational mistake.
Use multisig for team treasuries, shared budgets, and other spending that requires approvals from multiple key holders.
Key considerations:
- Additional signatures can increase message size, verification work, and fees.
- Signers must coordinate; a request may expire before it collects enough approvals.
- Setup, key management, signer changes, request limits, and recovery depend on the implementation.
Payment gateways
Highload v3 uses unique query_id values instead of a sequential seqno, which allows clients to track multiple submitted requests without waiting for a single counter to advance. The query-ID format provides 8,380,416 possible values. Reuse follows the contract's timeout and replay-protection rules.
Batch transfers send an internal message to the wallet itself. That message can include up to 254 outgoing messages. These contract limits do not guarantee network throughput.
Use for:
- Cryptocurrency exchanges: Process withdrawals and payouts.
- Payment processors: Send merchant payments at higher volumes.
- Trading platforms: Submit many independent outbound transfers.
Key considerations:
- Budget for fees and balance consumed across the two-transaction pattern.
- Track unique query IDs, expiry, cleanup, and request outcomes.
- Keep request batches within the 254-message limit and test failure handling.
Use Highload v3 for new deployments — previous highload wallet versions are deprecated.
Read more: