Skip to main content
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

​
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