Highload Wallet

A Highload Wallet is a TON wallet contract designed for operators that need to send vast numbers of outgoing transfers — exchanges processing withdrawals, payment processors batching payouts, airdrop distributors. The standard v3R2 / v4R2 / W5 wallets cap out at a few hundred messages per signed transaction. Highload Wallets are built to push that into the billions per period.

Why standard wallets aren’t enough

Regular TON wallets use seqno-based replay protection: each external message must reference the current sequence number, and only one message per seqno succeeds. That naturally serialises transactions — to send 10,000 transfers you’d need 10,000 sequential signed messages, each waiting for the previous to land.

For an exchange running tens of thousands of withdrawals in flight, that bottleneck is unworkable. Highload removes it.

How Highload works

Highload Wallet v3 — the current production version — uses a different replay-protection model:

• Each external message carries a query-id (a unique 64-bit identifier chosen by the operator) and a timeout (an expiry timestamp).
• The contract keeps a dictionary of recently seen query-ids and rejects duplicates within the timeout window.
• After the timeout window passes, the contract garbage-collects old entries from the dictionary.

This lets the operator submit many messages in parallel — they don’t depend on each other’s seqno. As long as query-ids are unique and within the timeout, every valid message goes through.

The throughput claim per docs: “up to 2 billion outgoing messages per timeout period.”

Trade-offs

• More complexity for operators. Allocation of query-ids must be careful — a collision is a lost message. Most operators derive query-ids deterministically from a withdrawal ID + batch number.
• No plugin support. Highload Wallet doesn’t carry the v4/W5 plugin system. It’s purpose-built for outgoing payments, not for subscriptions or gasless flows.
• No multi-owner support. Single signer; for shared custody, use a multisig wallet instead.
• State growth. The dictionary of pending query-ids costs storage. Operators must size the timeout sensibly — too long and the contract bloats; too short and a slow message can be replayed.

Who uses it

Almost every TON-listing exchange uses a Highload Wallet to fan out withdrawals: OKX, Bybit, Bitget, MEXC, Gate, KuCoin. The same contract pattern shows up in:

• Notcoin and Hamster Kombat airdrop distribution.
• Telegram Stars-to-TON payouts via Fragment.
• Mass-payout systems (loyalty rewards, affiliate program payouts in TON).

Comparison with W5

Feature	W5	Highload v3
Replay protection	seqno	query-id + timeout
Outgoing msgs per signed request	255	up to ~2 billion / period
Plugin support	yes	no
Multi-owner	no (single key)	no
Gasless transactions	yes	no
Use case	end users	exchanges, payments

Caveats for retail users

If you’re holding TON for personal use, you do not want a Highload Wallet — its lack of seqno tracking and plugin support makes it a worse fit than W5. Highload is operator infrastructure; it shows up in retail conversations only when explaining how an exchange’s hot wallet works.

For a retail multisig (treasury, project funds), use the dedicated multisig wallet contract, not Highload.