What makes them different
Unlike standard wallets (v3, v4, v5) that use sequential processing with aseqno counter, Highload Wallets (v2 and v3) store processed request identifiers in a dictionary, enabling parallel transaction submission without blocking.
seqno (sequence number) is a counter that increments with each transaction. Standard wallets use it for replay protection — each transaction must match the current seqno value.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, 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 simpleseqno 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)
Legacy contracts: Highload Wallet v1 and v2 are deprecated. Use Highload Wallet v3 for all new deployments.
Highload Wallet v2
Improved version with dictionary-based replay protection:- Fund locking risk: Under certain conditions, the contract could enter a state where funds became 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)
Legacy contracts: Highload Wallet v1 and v2 are deprecated. Use Highload Wallet v3 for all new deployments.
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_idis 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)