Transaction v1 and the ALT Trade-off

Why This Matters, by Stakeholder

Validators and client teams: v1 exposes fee and resource requests directly in transaction metadata, enabling earlier prioritization and more efficient block construction, with the potential for better fee capture; it also removes state-dependent ALT resolution from ingestion
Application developers: the 4,096-byte envelope enables richer atomic transactions, but the unchanged 64-account limit can still constrain account-heavy applications
Traders, routers, and searchers: larger transactions can support more complex atomic routes, although dense ALT users consume more of the new byte budget when addresses are inlined
Wallets, SDKs, and RPC providers: v1 requires new serialization, decoding, and transaction-building support, including removal of ALT-specific assumptions
Privacy, multisig, and cryptographic applications: larger payloads create substantially more room for proofs, signatures, and other data-heavy constructions without increasing compute or account limits.

TL;DR

Account Lookup Table removal is the main source of potential serialized-size expansion under v1
ALT usage is both widespread and operationally concentrated. Around 62% of observed v0 transactions reference at least one ALT
Dense ALT transactions (i.e. transactions using multiple ALTs) can add more than 1,500 bytes when converted to v1
- 50% of current transactions show an excess that is less than 420 bytes when converted to v1
- 90% of current transactions show an excess that is less than 1,400 bytes when converted to v1
The current workload appears broadly compatible with the 4,096-byte envelope, but not every dimension gains the same headroom
- top-level instruction capacity is generally abundant
- account headroom is more heterogeneous, and the unchanged 64-account limit may remain the binding constraint

Relevant Charts

Empirical probability density function of the serialized size of transactions. The distribution is computed from a 1/16 transaction-level sample (30 days). Each bin is decomposed into component density contributions, whose vertical sum reconstructs the aggregate PDF. Source: Dune.

Counterfactual v1 serialized-size PDF for the sampled legacy and v0 workload. Static addresses and addresses originally loaded through ALT are shown separately. The distribution is computed from the same 1/16 transaction sample as Figs. 1 and 2. Source: Dune.

Remaining v1 account slots, decomposed by top-level instruction headroom. Bar height reports the share of current v0 ALT transactions in each account-headroom bin; colors identify the corresponding range of remaining instruction slots. Source: Dune.

Introduction

Solana is moving through a broad set of protocol and client-side optimizations. In this context, the current legacy and v0 transaction formats introduce avoidable complexity along the validator’s ingestion path. Before a transaction can enter the scheduler, a validator must:

receive and decode it
verify its signatures and sanitize its message
extract its fee and resource requests
estimate its execution cost and compute its priority
place it in the appropriate scheduler queue.

For v0 transactions, this process includes an additional state-dependent step. Before the complete account set is known, the validator must:

load every referenced Address Lookup Table from the Bank and AccountsDB
verify the lookup-table account owner and deserialize its state
validate the writable and read-only indices
resolve those indices into full account addresses
combine the resolved addresses with the static account keys
validate the final account set used by the subsequent processing stages.

The current instruction layout introduces a separate source of parsing complexity. Legacy and v0 instructions are serialized sequentially as variable-length CompiledInstruction objects. Each instruction contains a program index, a compact-length-prefixed account vector, and a compact-length-prefixed data vector. As a result, the boundary of instruction $i$ is not directly available from a fixed metadata section: the parser must first read or skip the preceding instructions.

The proposed v1 format addresses both transaction capacity and this ingestion complexity. The larger envelope introduced by SIMD-0296 creates room for applications that cannot fit within the current 1,232-byte limit, while SIMD-0385 changes the transaction layout itself. Under v1:

fees and resource requests become first-class transaction metadata
Address Lookup Tables are removed and all referenced accounts are included in a single inline address array
fixed-width instruction headers are separated from their variable-length payloads.

These changes allow validators to recover fee and resource information, determine instruction boundaries, and identify the complete account set earlier and with less state-dependent processing.

Their effect on serialized size, however, is asymmetric.

Moving resource requests into transaction metadata and separating instruction headers from payloads changes the transaction size only by a bounded amount. Removing ALT compression can have a much larger effect. An account that v0 can represent through an approximately one-byte lookup index must be included in v1 as a complete 32-byte public key. This increase is partially offset by removing the lookup-table address and its associated prefixes, but the net cost can still grow rapidly with the number of accounts loaded through ALT.

ALT removal is therefore the only structural change in v1 whose positive byte impact can scale materially with the account footprint of the transaction.

This leads to the central question of the analysis:

How much of the new 4,096-byte envelope represents genuinely new application capacity, and how much is consumed by making explicit the account sets that v0 currently compresses through Address Lookup Tables?

To answer it, we study how ALT are used by current transactions: how many tables they reference, how many writable and read-only addresses they load, and which accounts most frequently appear in multi-table transaction contexts. We then reconstruct how this current ALT snapshot would be represented under the proposed v1 format.

Increasing transaction size, with relative transaction V1 format, has been discussed in

Serialized Size Composition Walkthrough

The serialized size of a transaction is uniquely determined by its binary structure. We can therefore reconstruct the bytes occupied by each component of a legacy or v0 transaction and study not only the total size, but also what is generating it. The exact computation is described in Appendix A.

The current distribution is clearly multimodal (Fig. 1). Its most visible modes occur around 360, 680, and 1,040 bytes, with additional mass close to the current 1,232-byte limit.

This is not the shape expected from a single transaction class whose size varies continuously. It is more consistent with a mixture of recurring transaction templates, each characterized by a relatively stable combination of signatures, account addresses, instructions, and lookup-table usage.

Static account keys are the dominant serialized component across much of the distribution. Every account included directly in the message costs 32 bytes, so even a moderate increase in the number of static accounts has a visible effect on transaction size.

Compiled instructions represent the second major variable component. They include the program index, the account references passed to the program, and the instruction data for every top-level instruction. Their serialized footprint should not be interpreted as compute consumption: a small top-level instruction can generate many inner instructions, while a large data payload does not necessarily consume compute in direct proportion to its size.

The isolated lookup_entries contribution has a different profile (Fig. 2). Most of its density contribution is concentrated between approximately 540 and 940 bytes, although secondary mass remains visible closer to the transaction-size limit.

**Fig. 2:** Lookup-entry contribution to transaction serialized-size density. At each transaction-size bin, the series combines the aggregate transaction density with the average fraction of bytes attributable to serialized lookup entries. It is computed from the same 1/16 sample as Fig. 1. Source: Dune.

ALT usage is therefore not uniformly distributed across the transaction population. It is associated with particular medium-to-large transaction templates.

The isolated curve is not a standalone normalized PDF: it is the lookup_entries contribution to the global serialized-size density. Its shape tells us where lookup bytes are concentrated in the transaction population, while its area measures their average contribution to serialized size.

However, lookup bytes do not tell us directly how many accounts are being compressed. A compact lookup section may represent a large account set, while a large lookup section may simply be paying the fixed overhead of many sparsely used tables.

To address this point, in the remaining part of the analysis, we will explore the structure of the lookup section itself.

What a Lookup Byte Is Actually Buying

Address Lookup Tables do not reduce the number of accounts used by a transaction. They reduce the number of bytes required to identify those accounts in the message.

In the common encoding regime, every lookup table introduces approximately 34 bytes of fixed overhead. Once the table is present, every selected writable or read-only account adds approximately one byte.

This creates two very different configurations.

A dense lookup configuration loads many accounts through relatively few tables. The fixed cost is amortized over a large account set and v0 obtains strong compression.

A fragmented configuration loads only a few accounts from each table. The transaction repeatedly pays the fixed table overhead and obtains a smaller compression benefit.

The Current Lookup-Entry Footprint

The transaction-level distribution of serialized lookup-entry bytes contains a large mass at zero (Fig. 3). This includes legacy transactions, which cannot use ALT, together with v0 transactions that do not serialize any lookup entries.

The positive support starts with a shoulder below approximately 50 bytes and develops a long, irregular right tail.

**Fig. 3:** Empirical PDF of serialized lookup-entry bytes per transaction. The zero bin contains transactions with no serialized lookup entries, while the positive support measures the current on-wire cost of ALT references. Source: Dune.

The first positive region is consistent with compact ALT usage: one table is referenced and a limited number of addresses are selected from it.

The right tail has a less direct interpretation. A large lookup section can be generated by a large loaded-account set, but it can also be generated by a smaller account set fragmented across many tables.

A closer view reveals a sequence of recurring modes rather than a smooth decay (Fig. 4).

**Fig. 4:** Zoom of Fig. 3 over the 60-1232 byte range. Recurring modes reflect the fixed cost of referencing additional lookup tables together with the one-byte cost of each selected account index. Source: Dune.

These peaks follow directly from the encoding.

Adding another account to a table that is already used moves the lookup size by approximately one byte. Introducing another lookup table shifts the transaction by approximately another 34 bytes. Recurring transaction templates then concentrate observations around specific combinations of table count and loaded-account count.

The same lookup-entry size can consequently describe very different account structures:

many accounts concentrated in a few tables
fewer accounts distributed across more tables.

This distinction becomes central once the tables are removed.

Why the Distribution Forms Diagonal Bands

The relation between lookup-entry size and the number of writable and read-only accounts makes this structure visible (Fig. 5).

**Fig. 5:** Writable and read-only addresses loaded through ALT versus serialized lookup-entry size. Bubble size is proportional to transaction count. The diagonal bands primarily reflect different numbers of referenced lookup tables.. Source: Dune.

The repeated diagonal bands are not an unexplained empirical pattern. Each band corresponds approximately to a fixed number of lookup tables.

Moving upward along one band means loading more accounts while keeping the number of tables unchanged. Moving to the next band on the right generally means introducing an additional table and paying its fixed overhead.

The width of each band comes from variation in the other account category. Two transactions with the same number of writable accounts can have different lookup sizes because they load different numbers of read-only accounts, and vice versa.

This explains why a transaction with a moderate number of writable accounts can still have a large lookup section. It may also load many read-only accounts, reference many lookup tables, or combine both behaviors.

For example, a transaction using 14 lookup tables, 11 writable accounts, and 16 read-only accounts requires approximately 503 lookup-entry bytes. It loads 27 accounts through ALT, but most of the serialized footprint comes from repeatedly identifying the 14 tables.

The reverse configuration is more important for v1.

A transaction can load many accounts while keeping the lookup section compact if those accounts are concentrated in one or two densely used tables. One table loading 40 accounts requires approximately 74 lookup-entry bytes. The same 40 accounts spread across ten tables require approximately 380 bytes.

The account footprint is identical. The current byte cost is not.

Writable and read-only accounts have the same serialized cost. Their separation remains useful because they have different execution implications. Writable accounts enlarge the write-lock footprint, while read-only accounts do not generate the same class of conflicts.

Which Workloads Depend on ALT?

Frequently ALT-loaded accounts are strongly connected to token and trading infrastructure. These accounts tend to appear in transactions that reference several lookup tables, and common three- and four-table transaction classes load large account sets.

In Fig. 6 we show the number of transactions in which an account is loaded through ALT.

**Fig. 6:** Most frequently ALT-loaded accounts. For each account, the table reports the number of transactions in which it is loaded through ALT and the mean number of lookup tables referenced by those transactions. Source: Dune.

For every account loaded through ALT, the table reports:

how many transactions loaded that account
the mean number of lookup tables referenced by those transactions.

The second statistic requires a careful interpretation.

A value of three does not mean that the account is stored in three different lookup tables. It means that transactions loading that account reference three tables in total. Only one table may provide the account itself, while the others provide different addresses required by the same transaction.

The highest-frequency rows are strongly associated with token and trading infrastructure. They include general token primitives together with several Pump-related accounts.

This is consistent with ALT usage being particularly relevant for transactions that combine several programs, token accounts, fee accounts, markets, and pool-specific state. Pump-related trading activity is a visible part of this workload.

Does the Pattern Persist Beyond the Top Accounts?

To study the persistency of the pattern, accounts are divided into equal-population buckets according to the number of transactions in which they are loaded through ALT. For each bucket, Figures 7 and 8 report the distribution of the per-account mean number of referenced lookup tables.

**Fig. 7:** ALT usage by account-frequency quantile. Accounts are grouped into equal-population buckets according to the number of transactions in which they are loaded through ALT. Lines report the p05, p50, mean and p95 of the per-account mean lookup-table count. Source: Dune.

Among low-frequency accounts, the median transaction context starts near two lookup tables.

As account frequency increases, both the median and the mean move toward approximately three to four tables and then remain relatively stable. The upper tail is higher, with the p95 generally corresponding to transactions referencing approximately five lookup tables.

The same relationship becomes easier to read when each frequency bucket is positioned by its median absolute transaction count on a logarithmic scale (Fig. 8).

Fig. 8: ALT usage by absolute account frequency. The same account-level statistics as Figure 7, with each bucket positioned by its median number of transactions per account on a logarithmic scale. Source: Dune.

The three-to-four-table range persists over several orders of magnitude in account frequency. Multi-table usage is therefore not limited to rare accounts or isolated transaction templates. It also characterizes accounts that are loaded through ALT across large numbers of transactions.

The Transaction-Level Picture

When transactions are grouped directly by the number of lookup tables they reference, activity is concentrated in the low-single-digit range (Fig. 9).

**Fig. 9:** ALT-loaded addresses by number of referenced lookup tables. The vertical axis reports the average number of addresses loaded through ALT; bubble size is proportional to transaction count. Source: Dune.

Transactions using three or four lookup tables are among the largest observed groups. More importantly, these groups load approximately 40 addresses through ALT on average.

These transactions are not paying table overhead for a small account set. They are simultaneously:

table-heavy, because they reference several lookup tables
account-heavy, because those tables collectively provide a large number of addresses.

This is exactly the regime in which ALT compression is useful. Several tables allow a transaction to represent a large account set through short indices rather than complete public keys. The vertical axis includes only the accounts loaded through ALT.

A Closer Look to ALT

The transaction-level picture leaves one important question open. We have seen that some of the largest transaction groups reference three or four lookup tables while loading a substantial number of accounts. But are those transactions repeatedly using the same shared tables, or are they drawing from a much larger and continuously changing table set?

To answer this, we rank every distinct ALT by the number of transactions that reference it (Fig. 10).

Across the observation window, approximately 62.19% of v0 transactions reference at least one ALT. However, this usage is far from evenly distributed across tables. The first 25 ALTs already account for approximately 30% of all transaction-to-table references, while 95% coverage is reached after 26,144 tables.

This is a remarkably concentrated distribution. The queried workload references more than 350,000 distinct ALTs, yet fewer than 7.5% of them account for 95% of all observed references. The remaining tables form a very long tail that collectively contributes only the final 5%.

**Fig. 10:** Concentration of ALT usage. Lookup tables are ranked by the number of distinct transactions referencing them. The left axis reports transaction count on a logarithmic scale, while the right axis reports the cumulative share of all transaction-to-ALT references. Source: Dune.

If we measure the fraction of ALT-using transactions that reference a given table, we see that this quantity falls below 0.1% after the 212th table. By measures the table’s share of all transaction-to-ALT references, this quantity falls below 0.1% after only 117 tables.

For every ALT, we can also measure how many writable and read-only addresses are selected on an average reference (Fig. 11). This is not the total number of addresses stored in the table. It is the number of addresses that transactions actually extract from the table each time they use it.

**Fig. 11:** Average addresses loaded per ALT use. Lookup tables are ordered by transaction-reference rank. The vertical axis reports the average number of writable and read-only addresses selected from each table whenever it is referenced. Source: Dune.

The plot shows that many tables provide fewer than ten addresses on an average use. This remains true across a broad portion of the rank distribution, including tables that are referenced by a large number of transactions.

A table can therefore be operationally important without providing a particularly large number of addresses to each individual transaction. It may contain commonly reused infrastructure, while each transaction selects only the subset relevant to its own route or application.

The far-right tail of Fig. 11 is more dispersed, with some rarely referenced tables providing much larger account sets when used. This region should be interpreted cautiously: for tables observed only once or a few times, the reported average is based on very few transactions and is therefore inherently noisy.

Figure 12 shows the daily lifecycle data of ALTs.

**Fig. 12:** Daily ALT usage and lifecycle activity. n_alts_used is the number of distinct ALTs referenced by successful v0 transactions on each date. The remaining series report the number of distinct tables successfully created, extended, or closed during the same date. Source: Dune.

Approximately 60,000-75,000 distinct ALTs are used by successful v0 transactions on a typical complete day in the sample. At the same time, tables are continuously created, extended, and closed, with each lifecycle category generally involving thousands or tens of thousands of distinct tables per day.

This is consistent with an ALT layer that is actively maintained and experiences substantial turnover. Tables are not merely created once and then reused indefinitely: a large number is being added, expanded, and retired throughout the observation window.

Taken together, the three figures reveal two very different sides of current ALT usage.

On one side, a small core of tables dominates transaction references. Removing those tables affects recurring, high-volume workloads.

On the other, a large and actively changing tail introduces fragmentation and operational complexity. Many of these tables contribute only a limited number of addresses per use, even though transactions may combine several of them.

Impact of Account Lookup Table Removal

V1 does not translate a lookup table into a new serialized object: the table disappears.

What remains are the accounts it previously resolved, and every one of those accounts must now occupy 32 bytes inside the transaction.

The Isolated ALT-to-v1 Delta

For every v0 transaction using at least one lookup table, we compare:

the complete serialized v0 ALT section;
the bytes required to include the same loaded accounts inline in v1.

**Fig. 13:** Empirical CDF of the ALT-to-v1 account-encoding delta. The delta compares the complete v0 ALT section with the cost of including the same loaded addresses inline in v1. The distribution is conditional on v0 transactions using at least one ALT. Source: Dune.

A positive value means that the v1 inline representation is larger. A negative value means that the current lookup configuration is sufficiently sparse or fragmented that its table overhead already exceeds the cost of placing the selected addresses inline.

The small negative region therefore represents inefficient ALT usage: several tables are referenced, but only a few accounts are extracted from each one.

The long positive tail represents the opposite regime.

These transactions load many accounts from relatively few tables. Their current lookup sections remain compact because the fixed table cost is amortized over many one-byte indices. Once those indices become complete addresses, the account representation expands sharply.

From the v1 conversion, 50% of current transactions show an excess that is less than 420 bytes, while 90% of them show an excess that is less than 1,400 bytes.

What the Full Transaction Looks Like in v1

Once the ALT mechanism has been isolated, we can reconstruct the complete transaction under the proposed v1 layout (Fig. 14).

Recognized Compute Budget instructions are moved into transaction-level configuration fields. The remaining application instructions are represented through fixed-width headers and concatenated payloads. Every resolved account is placed inline.

For analytical purposes, the address component is split into:

static_addresses, which were already included inline in the source transaction
alt_loaded_addresses, which were previously compressed through lookup tables.

The actual v1 format contains one address array. The split is used only to show the origin of the bytes.

The distribution moves substantially to the right but remains multimodal. The recurring templates visible under the current format do not disappear; they move according to their account and instruction requirements.

Static addresses remain important across the left and middle parts of the distribution. Some modes, especially around 1,000 bytes, remain relatively instruction-payload-heavy.

The right tail looks different. Addresses previously loaded through ALT become increasingly important and eventually dominate it.

This is the aggregate effect of removing lookup compression. Static accounts were already transmitted as complete public keys. ALT-loaded accounts were not.

The counterfactual distribution becomes very thin above approximately 2,300–2,400 bytes, leaving a substantial gap below the proposed 4,096-byte limit.

This does not mean that the remaining region has no potential demand. The observed population contains only workloads that can already be expressed as individual legacy or v0 transactions. It excludes transactions that are currently split across several transactions, submitted through bundles, or never constructed because they cannot fit within the existing 1,232-byte envelope.

How Much Room Is Really Left?

Serialized bytes are only one dimension of transaction capacity.

A converted transaction can remain far below 4,096 bytes while already sitting close to the account limit. It can also have many unused instruction slots but insufficient account capacity to add another pool or market.

The headroom analysis therefore considers both remaining account slots and remaining top-level instruction slots (Fig. 15).

The instruction dimension appears largely unconstrained for the current workload. Most transactions retain between 56 and 63 top-level instruction slots after conversion, meaning that their v1 representation uses only one to eight such instructions.

Account headroom is much more heterogeneous.

Some transaction classes retain several dozen account slots. Other large groups remain within only a few slots of the current account limit.

This difference determines what kind of complexity v1 can support.

A transaction with byte and instruction headroom can add:

more instruction data
additional checks and conditions
more instructions operating on accounts already present
operations that introduce only a limited number of new addresses
larger proofs or other data-heavy payloads.

This is meaningful room for structurally richer transactions.

The conclusion is weaker for extensions that require a new account set. Adding another pool, market, or venue may require pool state, vaults, tick arrays, oracles, and other protocol-specific accounts. A transaction with only a few remaining account slots may reach the address limit even while retaining hundreds of bytes and dozens of instruction slots.

V1 appears to leave substantial room for richer transactions that reuse or moderately extend their existing account set, while the account limit is more likely to remain binding for broad multi-pool or multi-venue strategies.

Appendix A - Serialized Size Computation

We can reconstruct the serialized size of a transaction starting from its composition. Let’s define

$S_t$ as the number of signatures
$A_t$ as the number of static accounts
$I_t$ as the number of top-level instructions
$a_{t_i}$ as the number of accounts index in the instruction
$i$
$d_{t_i}$ as the number of instruction-data byte of instruction
$i$
$L_t$ as the number of Address Lookup Table referenced
$w_{t_j}$ and $r_{t_j}$ as the number of writable e read-only index loaded in the lookup table $j$
$v_t=1$ for a v0 transaction and $V_t = 0$ for a legacy transaction
$c(n)$ as the number of bytes used by the compact-u16 representation of $n$ .

The function $c(n)$ is defined as (see here)

c(n) = \left\{\begin{align*} & 1\qquad n<128\\ & 2\qquad 128\le n < 16384\\ & 3\qquad n\ge 16384\,. \end{align*}\right.

With this nomenclature, we can compute the serialized size of a transaction as

\begin{align*} B_t = &\,\, c(S_t) + 64S_t\\ &+v_t\\ &+3\\ &+c(A_t)+32A_t\\ &+32\\ &+c(I_t)\\ &+\sum_{i=1}^{I_t}\left[1+c(a_{t_i})+a_{t_i}+c(d_{t_i})+d_{t_i}\right]\\ &+v_t\left[c(L_t)+\sum_{j=1}^{L_t}\left(32+c(w_{t_j})+w_{t_j}+c(r_{t_j})+r_{t_j}\right)\right]\,. \end{align*}

In a more compact form

B_t=B_t^\text{authorization}+B_t^\text{accounts}+B_t^\text{instructions}+B_t^\text{ALT}+B_t^\text{format overhead}\,.

Appendix B - Transition to V1 Format

Unlike legacy and v0, v1 is not based on variable-length compact-u16 vectors and does not contain Address Lookup Tables. It uses fixed-width transaction and instruction headers, includes every referenced account directly as a 32-byte address, and moves fee and resource requests from Compute Budget instructions into the transaction header.

Let us define:

$S_t$ as the number of required signatures
$A_t$ as the number of unique account addresses referenced by the transaction
$I_t$ as the number of top-level instructions
$a_{t_i}$ as the number of account indices passed to instruction
$i$
$d_{t_i}$ as the number of instruction-data bytes of instruction
$i$
$M_t$ as the 32-bit TransactionConfigMask
$K_t=\operatorname{popcount}(M_t)$ as the number of four-byte configuration slots contained in ConfigValues

Under the currently specified configuration fields, the priority-fee request uses two bits, while the compute-unit limit, loaded-account-data-size limit, and heap-size request use one slot each. More generally, the size computation depends only on $K_t$ , independently of the meaning assigned to each bit.

The corresponding instruction payload contains $a_{t_i}$ one-byte account indices followed by $d_{t_i}$ instruction-data bytes. Unlike legacy and v0, these lengths are not represented through separate compact-u16 prefixes: they are already contained in the fixed-width instruction header. The number of signatures is similarly obtained from the three-byte LegacyHeader, so v1 does not require a separate signature-count prefix.

Collecting the fixed fields gives:

B_t^{v1} = 42 + 32A_t+4K_t+4I_t+\sum_{i=1}^{I_t}\left(a_{t_i}+d_{t_i}\right)+64S_t\,.

The larger size limit therefore does not, by itself, increase the maximum number of referenced accounts or top-level instructions relative to the limits specified for the current formats.

Appendix C - Why ALT Removal Has the Largest Expansion Potential

This appendix compares the v0 and v1 components and shows why ALT removal is structurally different from the remaining changes.

C.1 Account Encoding

The main structural difference between v0 and v1 can be isolated by comparing their account-related components.

Let:

$A^s_t$ be the number of static accounts
$W_t$ be the number of writable accounts loaded through ALT
$R_t$ be the number of read-only accounts loaded through ALT
$L_t$ be the number of referenced lookup tables
$w_{t_j}$ and $r_{t_j}$ be the writable and read-only indices selected from table $j$ .

Under v0, the combined static-account and ALT representation is:

\begin{align*} B_t^\text{tot account, v0} &= B_t^\text{accounts, v0} + B_t^\text{ALT, v0}\\ &=c(A^s_t)+32A^s_t+c(L_t)+\sum_{j=1}^{L_t}\left(32+c(w_{t_j})+w_{t_j}+c(r_{t_j})+r_{t_j}\right)\,. \end{align*}

Under v1, the same resolved account set requires:

B_t^\text{accounts, v1} = 1 + 32\left(A_t^s+W_t+R_t\right)\,,

where the additional byte is NumAddresses.

Taking the difference and using the fact that all accounts and LT are < 128, and therefore $c(n<128)=1$ , follows

\begin{align*} \Delta B_t^\text{accounts} &= -1 +32(W_t+R_t)-32L_t-2L_t-W_t-R_t\\ &=-1+31(W_t+R_t)-34L_t\\ &=31A_t^\text{loaded}-34L_t-1\,. \end{align*}

Static addresses cancel because they occupy 32 bytes in both formats.

The expression shows that:

every ALT-loaded address adds approximately 31 net bytes
every removed lookup table offsets approximately 34 bytes
the global lookup-count prefix offsets one additional byte.

The delta can be negative for sparse lookup configurations. It grows rapidly when many addresses are concentrated in relatively few tables.

C.2 Retained Application Instructions

For a retained v0 application instruction $i$ ,

1+c(a_{t_i})+a_{t_i}+c(d_{t_i})+d_{t_i}\,.

The same instruction under v1 requires

4+a_{t_i}+d_{t_i}\,.

The difference is

3-c(a_{t_i})-c(d_{t_i})\,.

Since both compact prefixes occupy at least one byte,

\Delta B_{t_i}^{\mathrm{instruction}}\leq1\,.

When both the account count and the instruction-data length are below 128, the instruction grows by exactly one byte. If either prefix occupies more than one byte under v0, the difference becomes zero or negative.

With at most 64 retained top-level instructions, the gross positive contribution from the new instruction metadata is bounded by 64 bytes.

Compute Budget instructions are not retained in the migrated instruction set and therefore lower the actual instruction delta.

C.3 Resource Configuration

V1 always includes a four-byte TransactionConfigMask.

Under the currently specified fields, the configuration can contain at most five four-byte slots:

two slots for the priority-fee value
one slot for the compute-unit limit
one slot for the loaded-account-data-size limit
one slot for the heap-size request.

The gross v1 configuration cost is therefore bounded by

4+5\cdot4=24\text{ bytes}\,.

This is an upper bound on the positive contribution. These fields replace Compute Budget instructions already serialized in v0, and the migration may also remove the 32-byte Compute Budget Program address.

C.4 Signatures and Fixed Fields

The remaining components do not create a large positive expansion:

every signature remains 64 bytes
v1 removes the signature-count prefix
the three-byte message header remains unchanged
the 32-byte recent blockhash becomes a 32-byte lifetime specifier
the v0 and v1 version fields are both one byte
under the current limits, the global account and instruction counts occupy one byte in both formats
static addresses remain 32 bytes each.

These components are unchanged, bounded, or smaller under v1.