Goal: Construct efficient transactions that land reliably.

Cover: v0 tx format, Address Lookup Tables, compute units, priority fees, local fee markets.

Activity: Build a TS client that simulates, sets CU budget, and uses an ALT.

Takeaway: “I can pack/price txs for throughput and reliability.”

1) Module overview

You’ll learn versioned transactions (v0) and Address Lookup Tables (ALTs) to fit more accounts; how to set compute budgets and priority fees with the Compute Budget program; and why Solana uses local fee markets so unrelated traffic doesn’t spike your costs. Then you’ll build a small TypeScript client that simulates, sets CU limit/price, and uses an ALT.

2) Plain‑English explainer

Versioned tx (v0) + ALTs

• Solana has two tx formats: legacy and v0; v0 adds ALT support so you can reference many addresses compactly.
• ALTs “compress” 32‑byte addresses into tiny indices you store in a table, letting a single transaction handle many more accounts (guide targets up to ~64 accounts per tx). You create/extend tables, then reference them in a v0 message.

Compute units (CU) + priority fees

• Every tx has a compute limit and may include a price per CU (“tip”) via Compute Budget instructions: setComputeUnitLimit and setComputeUnitPrice. Default price is 0 unless you set it.
• Defaults today: ~200k CU per instruction and ~1.4M CU per transaction; adjust with setComputeUnitLimit after simulating.

Local fee markets (why your fee isn’t global)

• Fees are localized per hot account/region. If a single mint is congested, unrelated transfers don’t need to outbid it—so your app can stay cheap while others surge.

Where to get a live fee hint

• Use getRecentPrioritizationFees to fetch recent tips (optionally scoped to the accounts you will lock).