# Highload wallets (https://docs-orhepa2tm-ton-core-docs.vercel.app/llms/standard/wallets/highload/overview/content.md)



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 [#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.

<Callout>
  **`seqno`** (sequence number) is a counter that increments with each transaction. Standard wallets use it for [replay protection](/llms/standard/wallets/how-it-works/content.md) — each transaction must match the current `seqno` value.
</Callout>

**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 [#version-history]

### Highload Wallet v1 [#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](#replay-protection-rollback))

<Callout type="danger">
  **Legacy contracts:** Highload Wallet v1 and v2 are deprecated. Use Highload Wallet v3 for all new deployments.
</Callout>

### Highload Wallet v2 [#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](#replay-protection-rollback))

<Callout type="danger">
  **Legacy contracts:** Highload Wallet v1 and v2 are deprecated. Use Highload Wallet v3 for all new deployments.
</Callout>

### Highload Wallet v3 [#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 [#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 [#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](/llms/standard/wallets/how-it-works/content.md) 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](/llms/standard/wallets/highload/v3/specification/content.md) 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 [#see-also]

* [Highload Wallet v3](/llms/standard/wallets/highload/v3/specification/content.md) — complete technical reference and how-to guides
* [Highload Wallet v2](/llms/standard/wallets/highload/v2/specification/content.md) — legacy version (deprecated)
* [Highload Wallet v1](https://github.com/ton-blockchain/ton/blob/4ebd7412c52248360464c2df5f434c8aaa3edfe1/crypto/smartcont/highload-wallet-code.fc) — legacy version (deprecated)