I think these are the 3 relevant charts one should keep in mind when looking at larger txs size and v1 format 👇 The first shows serialized size composition of transactions (v0 and legacy), the second shows their counterfactual v1 serialized size. What I think is super interesting is that, despite the removals of Account Lookup Tables, a 3.3x on txs size is not saturated by format conversion. A counterfactual v1 serialized size has a long right-tail of txs that roughly double in size. Txs with > 1440 bytes are mostly due to txs dense in ALT usage (predominant component is from ALT removals in this range). Tho, this is a small payment in terms of size given what v1 allows. - 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 - 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. The last chart shows remaining v1 account slots, decomposed by top-level instruction headroom. Thus, it's clear that under v1 txs will be limited by accounts limit (which is going to be increased You are not ready for what v1 format + increase in account lock limit is bringing on chain. Read the full article here: