Solana’s Outbound Transaction Size Depends on Its Format

Solana’s outbound transaction limit is 1,232 bytes for legacy and v0 transactions, and 4,096 bytes for v1. The limit counts the serialized transaction sent over the network: its message and signatures, not just the instruction data or the amount of SOL being transferred. A larger transfer does not make a transaction larger; adding instructions, account addresses or signers can.

What counts toward a Solana transaction’s size?

A sender assembles a message from a recent blockhash, account references and instructions. Each instruction names a program, specifies which accounts it uses and carries its own data. The sender then adds a signature for each required signer. Those signatures take 64 bytes apiece, so transactions with several signers use more of the size budget before instruction data is counted.

The validator receives the serialized transaction and checks it before execution. Legacy and v0 transactions must fit within 1,232 bytes, a limit derived from the minimum IPv6 packet size after network headers. Think of that as a fixed envelope: every address and signature takes up room inside it. If a swap or other operation touches many accounts, its references can consume more space than its instruction data.

Cross-chain swaps add a separate question: what happens when one chain is slower than another. The thor swap explainer follows that timing across chains; here, the concern is how much one Solana transaction can carry.

How do v0 and v1 change the limit?

V0 keeps the 1,232-byte ceiling but can shrink account references with Address Lookup Tables, or ALTs. An ALT is an onchain list of public keys. Instead of writing each eligible account’s full 32-byte address into the transaction, a v0 message can refer to it by a one-byte index. The validator looks up the full address before execution.

That saves space when a transaction uses many accounts, but it does not remove the size limit. Signers still need to appear directly in the message, and the lookup-table reference itself also takes bytes. V0 is useful when account addresses are the main source of bloat; it does less for a transaction whose instruction data or signatures use most of the available room.

V1 raises the maximum serialized size to 4,096 bytes. It does not use ALTs: account addresses are included inline. A larger v1 transaction may be sent in multiple QUIC frames rather than one MTU-sized packet. The format also moves resource settings into the message. Sending v1 therefore depends on compatible wallet, RPC and transaction-building software, and the sender must set its compute and loaded-account limits explicitly.

What should you do when a transaction is too large?

First identify which format the sender is building and inspect the signed, serialized transaction. A draft message can grow when signatures are added, so checking instruction data alone gives an incomplete answer. Then look at what is using the space:

• Use v0 with an ALT when many non-signer account addresses dominate the message.
• Use v1 when the sender and the services handling the transaction support it, and the transaction needs more than 1,232 bytes.
• Remove redundant instructions or data when they can be omitted without changing the intended result.
• Split the operation only when separate transactions are acceptable.

Splitting can solve a size problem, but it changes the execution guarantee. Solana runs the instructions inside one transaction atomically: they all succeed or their state changes are reverted. Separate transactions do not share that guarantee. If the first succeeds and the next fails, the first transaction’s effects remain.

For most users, the practical check is simple: let the wallet or app build the transaction, confirm that it supports the needed format, and treat a size error as a message-construction issue rather than a limit on how much value can move. V0 compresses account references within the older envelope; v1 provides a larger envelope with different compatibility and setup requirements.