Highload wallets

Highload Wallets are specialized wallet contracts designed for services that need to send hundreds of transactions per second, such as cryptocurrency exchanges, payment processors, and high-volume trading platforms.

What makes them different

Unlike standard wallets (v3, v4, v5) that use sequential processing with a seqno counter, Highload Wallets (v2 and v3) store processed request identifiers in a dictionary, enabling parallel transaction submission without blocking.

Standard wallet limitation:
Each transaction must wait for the previous one to complete. If you send 100 transactions, they must process sequentially: transaction 2 waits for transaction 1, transaction 3 waits for transaction 2, and so on.

Highload Wallet advantage:
You can send 100, 1,000, or 100,000 transactions simultaneously. Each transaction uses a unique query_id instead of a sequential seqno, allowing parallel processing without conflicts.

Version history

Highload Wallet v1

The first highload wallet, using a simple seqno counter:

• Simple seqno-based: Sequential processing like standard wallets
• Batch support: Could send up to 255 messages per transaction
• Replay protection rollback: If the action phase failed, replay protection would roll back (learn about)

Highload Wallet v2

Improved version with dictionary-based replay protection:

• Fund locking risk: Under certain conditions, the contract could enter a state where funds become inaccessible
• High gas costs: Storage updates and cleanup operations consumed excessive gas
• Replay protection rollback: If the action phase failed, replay protection would roll back (learn about)

Highload Wallet v3

The current recommended version, redesigned to solve all previous architectural problems:

• More requests: Up to 8,380,416 unique query IDs with efficient rotation
• Lower gas costs: Optimized cleanup and storage operations
• Maximum safety: Architectural design prevents fund locking; bulletproof
• Guaranteed replay protection: Unlike v1, v2, and standard wallets v1-v4, replay protection never rolls back even if the action phase fails. The two-transaction pattern ensures the query_id is always committed before attempting to send messages.

Highload Wallet version comparison

Feature	v1	v2	v3
Replay rollback on action failure	⚠️ Yes	⚠️ Yes	✅ No (two-transaction pattern)
Fund locking risk	✅ No	⚠️ Yes	✅ No
Gas efficiency	Not optimized	⚠️ High cleanup costs	✅ Optimized
Max batch size	255 messages	255 messages	254 messages
Replay protection	Simple seqno	Query ID dictionary	Dual dictionary + timestamp
Transaction pattern	Single transaction	Single transaction	Two-transaction pattern
Query ID space	Sequential seqno	~32,000	8,380,416 unique IDs
Parallel submissions	❌ Sequential only	✅ Supported	✅ Supported
Status	⚠️ Deprecated	⚠️ Deprecated	✅ Recommended

Replay protection rollback

Standard wallets (v1-v4) and Highload wallets (v1-v2) share a fundamental problem: if the action phase fails (e.g., insufficient funds), the entire transaction rolls back, including replay protection marks. This causes lite-servers to retry the same message repeatedly, burning gas for a long time.

Highload v3’s solution: Uses a two-transaction pattern where replay protection is committed in the first transaction, and actions are performed in a separate internal transaction. This guarantees replay protection never rolls back, even if sending messages fails.

See also

• Highload Wallet v3 — complete technical reference and how-to guides
• Highload Wallet v2 — legacy version (deprecated)
• Highload Wallet v1 — legacy version (deprecated)