Can Dynamic Accounts Be Registered in an ALT?

The Address Lookup Table is solving the byte problem. Accounts that consumed 32 bytes each now compress to single-byte indices. Transactions that overflowed the 1,232-byte limit now fit comfortably. The compression ratio is real, the savings are measurable, and the arbitrage bot is executing multi-hop cycles that were physically impossible before.

Then I hit a wall that is not about bytes. It is about accounts that move.

Some of the addresses the bot needs in its transactions are not fixed. They are not like a pool address, which is created once and lives at the same location forever. They are not like a token vault, which holds liquidity at a permanent public key. These addresses are derived from the current price of a trading pair, and when the price changes, the addresses change with it. The account the bot needs right now is not the account the bot will need five minutes from now.

The question is immediate and practical: can these moving targets be registered in an Address Lookup Table? If the whole point of the table is to pre-register addresses for compression, and the addresses keep changing, does the entire ALT strategy collapse for these protocols?

The intuition says yes. Dynamic means unpredictable. Unpredictable means you cannot pre-register. Cannot pre-register means no compression. No compression means back to the 32-byte-per-account reality, back to bloated transactions, back to cycles that do not fit.

The intuition is wrong. But proving it requires data, not assumptions.

The Parking Pass Problem

Everyone who drives in a city understands the difference between hourly parking and a monthly pass. Hourly parking is precise. You pay for exactly the time you use, at exactly the location you need, starting at exactly the moment you arrive. It is perfectly matched to your actual behavior. It is also expensive per unit, unpredictable in availability, and requires a new decision every single time you park.

A monthly pass is imprecise. You pay for a garage, and the garage covers a zone. Maybe the zone is four square blocks. Maybe it is eight. You do not park at a specific spot — you park somewhere in the zone. The pass does not guarantee you the exact space closest to your destination. It guarantees you a space somewhere nearby. And for most days, most trips, most errands, "somewhere nearby" is perfectly adequate.

The question about dynamic accounts and ALTs is the same question. Can you buy a monthly pass when your destination changes every day? The answer depends on whether your destinations cluster within a zone or scatter across the entire city. If you work downtown, eat downtown, shop downtown, and meet friends downtown, the monthly pass for the downtown garage covers nearly everything. Your specific spot changes. Your zone does not.

Dynamic accounts on concentrated liquidity DEXes behave like downtown destinations. They move. But they do not move far.

Why Accounts Move

To understand why certain accounts are dynamic, you need to understand how concentrated liquidity protocols organize their price space.

A traditional constant-product AMM — the kind that uses the x * y = k formula — stores all its state in a single pool account. One account holds the reserves, the fee configuration, the accumulated protocol fees. Every swap at every price touches the same account. The account is static. It does not care what the current price is. It exists at one address, period.

Concentrated liquidity protocols work differently. They divide the entire possible price range into segments. Each segment covers a specific portion of the price spectrum — say, from $1.00 to $1.10, or from $1.10 to $1.21, or from $1.21 to $1.33. The boundaries are determined by a mathematical formula, and each segment is stored in its own on-chain account. These accounts go by different names depending on the protocol — tick arrays, bin arrays — but the concept is the same. The price space is partitioned, and each partition lives at a different address.

When a swap executes, the protocol needs to know which segment the current price falls in. The swap instruction must include the account for that segment. If the price is at $1.05, the instruction needs the account for the $1.00–$1.10 segment. If the price moves to $1.15, the next swap needs the account for the $1.10–$1.21 segment. Different price, different account.

This is what makes them dynamic. The account address is not a property of the pool — it is a property of the pool at a specific price. The pool does not change. The price does. And the price changes constantly, because that is what prices do in a live trading environment.

The Intuitive Fear

The moment you realize that transaction accounts depend on price, the natural conclusion is that ALT registration is pointless. Why register an account that might be irrelevant by the time you use it? The price could move in any direction. The segment you registered could be the wrong segment by the next block. You would need to register every possible segment to guarantee coverage, and some pools have hundreds of segments spanning their full price range. Registering all of them would be wasteful — most would never be used — and would consume table slots that could be allocated to static accounts that provide guaranteed value.

This reasoning feels airtight. It follows a clean logical chain: dynamic inputs require dynamic references, dynamic references cannot be pre-registered, therefore pre-registration is impossible. It is the kind of conclusion that sounds rigorous and requires no data to support, which is exactly why it should be questioned.

The logic contains a hidden assumption. It assumes that "dynamic" means "wildly unpredictable" — that the price could be anywhere, and therefore the needed account could be anything. This is technically true over a long enough time horizon. Over a year, the price of a token pair can move orders of magnitude. The segment needed at today's price might be completely unrelated to the segment needed six months from now.

But the bot does not operate on a six-month horizon. It operates on a block-by-block horizon. And block to block, prices do not teleport. They move incrementally, constrained by liquidity depth, order flow, and the mechanical realities of how AMMs process swaps.

The question is not "can the price be anywhere?" It is "how far does the price typically move, and how many segments does that movement span?"

Looking at the Data

Instead of theorizing, I look at actual price behavior.

Concentrated liquidity protocols divide their price range into segments, and each segment covers a meaningful range. The exact coverage depends on the pool's configuration — some pools use wider segments, some use narrower ones — but in all cases, a single segment does not correspond to a single price point. A segment covers a band. And adjacent segments cover adjacent bands.

The structure looks like a bookshelf. Each shelf holds a range of page numbers. Shelf one holds pages 1 through 50. Shelf two holds pages 51 through 100. Shelf three holds pages 101 through 150. If you are currently reading page 73, you need shelf two. If you flip forward ten pages to page 83, you still need shelf two. You only need shelf three if you jump past page 100.

How often does the price jump past the boundary of its current segment? How often does it jump past the next segment? How often does it jump so far that it lands three or four segments away from where it started?

The data tells a clear story. For the major trading pairs — the ones with deep liquidity, the ones that generate the most arbitrage volume — the price almost always stays within the current segment or moves into an immediately adjacent one. The reason is mechanical. Deep liquidity acts as a buffer. A large swap that pushes the price through an entire segment requires enormous volume, and that volume itself creates the arbitrage opportunity that pulls the price back. The deeper the liquidity, the more force is required to move the price, and the more restoring force exists to bring it back.

Extreme price movements happen. A liquidity crisis, a sudden large trade, a protocol event — any of these can push a price through multiple segments in a single block. But these events are, by definition, unusual. The vast majority of blocks see the price either staying in its current segment or drifting to a neighbor.

This changes the calculus entirely.

The Monthly Subway Pass

Consider the monthly subway pass. In most transit systems, a monthly pass covers a zone — maybe three or four contiguous stations on either side of your primary station. You live at Station A, and the pass covers Stations B, C, D, E, and F. If your daily commute takes you to Station C, the pass works. If you need to run an errand at Station D, the pass works. If you visit a friend at Station E on the weekend, the pass works. The only time the pass fails is when you need to go to Station Q, fifteen stops away, in a completely different part of the city.

How often do you go to Station Q? If you are a typical commuter, almost never. Your life happens in the zone. Your work, your groceries, your gym, your friends — they cluster. The monthly pass covers the cluster. The rare trip to Station Q costs you a single-ride fare, which is a minor expense compared to the savings the monthly pass provides on every other trip.

Registering the center segment plus its neighbors in an ALT is the monthly pass for dynamic accounts. The center is where the price is now. The neighbors are where the price is most likely to go. Together, they form a zone. The zone covers the cluster of likely price movements. The rare price jump to a distant segment — Station Q — falls outside the zone and requires the full 32-byte address inline. But the savings from compressing every other transaction more than compensate for the occasional inline fallback.

The key insight is that "dynamic" does not mean "uniformly distributed across all possibilities." It means "changes within a pattern." And if the pattern has locality — if changes tend to be small and tend to cluster near the current state — then pre-registration of the neighborhood is effective.

How Wide Is the Zone?

The natural follow-up question is how many segments to register. One on each side of the center? Two? Five? The answer depends on the pool's segment width and the pair's typical volatility, but the general principle is that a small number of adjacent segments provides coverage for the overwhelming majority of price movements.

Think about a GPS navigation app with favorited routes. Most people have three or four routes they drive regularly — home to work, home to the grocery store, home to the gym, home to the kids' school. The GPS lets you favorite these routes so they load instantly. You do not need to favorite every possible route in the city. You favorite the ones you actually drive. And because your driving patterns have structure — you go to the same places, on the same roads, in the same part of town — a handful of favorites covers most of your navigation needs. The occasional trip to the airport or to a restaurant you have never visited requires entering a new address. That is fine. The favorites handle the daily pattern.

For a concentrated liquidity pool, registering segments near the current price covers a range that encompasses most normal price action. The exact number of segments and the width of that range depends on the segment size, which varies by pool configuration. The key insight is that a small number of well-chosen segments provides coverage for the overwhelming majority of trades, even though it cannot cover extreme price movements.

The coverage is not total. It does not need to be. The goal is not to eliminate inline accounts entirely. The goal is to compress the common case and accept the occasional fallback for the uncommon case. A transaction that uses ALT compression for the majority of its accounts and includes a couple of inline addresses for the edge cases still fits within the byte limit far more often than a transaction that uses no compression at all.

The Hybrid Approach

The practical implementation is a hybrid. The bot maintains an ALT that contains all the static accounts — pool addresses, token vaults, program IDs, authority PDAs — and also contains the dynamic accounts for the segments near each pool's current price. When building a transaction, the bot checks whether the needed dynamic account is in the table. If it is, the account gets compressed to a one-byte index. If it is not, the account goes inline at its full 32 bytes.

This is the library seating model. A library has two kinds of seating. Reserved seats, with brass nameplates on the desks, assigned to faculty and researchers who are there every day. And open seating, available to anyone on a first-come basis. The reserved seats are always available to their holders — no searching, no uncertainty, no risk of finding them occupied. The open seats serve everyone else, at the cost of occasionally not finding one available.

The ALT-registered dynamic accounts are the reserved seats. They are always available for compression — no additional bytes, no uncertainty, no overflow risk. The inline accounts are the open seats. They work, but they cost more space, and they are used only when the reserved option is not available.

The hybrid approach means the bot does not need to predict the future with perfect accuracy. It needs to predict the common case, which is that the price will stay near its current level. For the common case, the ALT provides compression. For the uncommon case, inline accounts provide correctness. The transaction is always valid — it always includes the right accounts for the current price. The transaction is usually compressed — it usually references those accounts through the ALT. And "usually compressed" is enormously more valuable than "never compressed," which is what the initial intuition suggested.

When the Zone Shifts

Prices do trend. Over hours or days, the price of a pair can drift steadily in one direction, eventually moving out of the registered zone. When this happens, the dynamic accounts in the ALT become stale — they point to segments that the price has left behind, and the segments the price now occupies are not in the table.

This is a maintenance problem, not a design problem. The solution is periodic re-evaluation. The bot monitors the current price relative to the registered segments. When the price drifts to the edge of the registered zone, the bot extends the table with the next set of segments in the direction of the drift. The old segments remain in the table — they do not hurt anything by being there, they just occupy table slots — and the new segments provide coverage for the updated price level.

In extreme cases, if a large number of segments have gone stale and the table is running out of room, the bot can deactivate and close the old table and create a new one with fresh entries centered on the current price. This is the equivalent of canceling a parking pass at a garage you no longer use and buying a new pass at a garage near your new office. The old pass was useful when you worked downtown. You work midtown now. The pass should reflect reality.

The periodic maintenance cost is small compared to the per-transaction savings. Extending a table costs one transaction and a fraction of a SOL in rent deposit. The compression savings apply to every transaction that references those entries. If the bot executes dozens or hundreds of transactions against a pool before the price drifts out of the zone, the savings from compression dwarf the cost of the occasional table extension.

The Assumption That Almost Won

The most interesting part of this entire analysis is not the technical outcome. It is the moment before the analysis, when the intuition almost prevented the analysis from happening.

"Dynamic accounts cannot be registered in an ALT." The statement sounds authoritative. It follows logically from the definition of dynamic. It feels like it should be true. And if I had accepted it without question, I would have permanently excluded an entire category of accounts from compression, permanently accepted larger transactions for every concentrated liquidity swap, and permanently operated with a handicap that did not need to exist.

The assumption was plausible. It was also wrong. And the gap between plausible and correct is exactly the gap that data fills.

There is a pattern here that extends beyond Solana and beyond MEV. In any technical domain, assumptions about impossibility are surprisingly common and surprisingly unexamined. Someone states a limitation, the limitation sounds reasonable, and it propagates through conversations and documentation and mental models until it becomes accepted fact. Nobody checks. Nobody asks "how dynamic is dynamic?" Nobody measures the actual distribution of price movements to see whether the assumed chaos is real or whether it has structure.

This is the equivalent of assuming you need hourly parking because your meeting schedule is unpredictable, when in reality your meetings happen in the same three buildings every week. The unpredictability is real — you genuinely do not know which building tomorrow's meeting is in. But the unpredictability is bounded. It has structure. It clusters. And a parking pass that covers the cluster handles the unpredictability at a fraction of the cost of paying hourly every day.

Don't Just Worry — Verify

The lesson is not that dynamic accounts can always go into ALTs. There are pools with extreme volatility, thin liquidity, and wide price swings where the zone approach provides little benefit. There are edge cases where a price jump makes every registered segment irrelevant in a single block. The lesson is that the determination of whether ALT registration works for dynamic accounts is an empirical question, not a theoretical one.

The theory says "it depends." The theory says it depends on how much prices move, how wide the segments are, how many segments you register, and how often you update the registrations. Those are measurable quantities. They can be observed, counted, and analyzed. The analysis produces an answer that is specific and actionable: register this many segments, update at this frequency, expect this level of coverage.

Skipping the analysis and accepting the intuitive "impossible" conclusion is not conservative. It is lazy. It confuses caution with ignorance. Genuine caution would say: "This might not work. Let me check." Ignorance says: "This cannot work. Let me move on."

The difference between those two responses is the difference between a bot that compresses its concentrated liquidity transactions and a bot that does not. The difference between a bot that fits four-hop cycles into the byte limit and a bot that cannot. The difference, ultimately, between capability and unnecessary limitation.

The concern about dynamic accounts was legitimate. Ignoring it would have been reckless. But accepting it as a conclusion without verification would have been equally costly. The right response is always the same: state the concern, gather the data, let the data resolve the question.

In this case, the data says the zone is wide enough. The price clusters. The segments cover the cluster. The ALT works for dynamic accounts — not perfectly, not in every case, but in enough cases to make the compression worthwhile and the implementation justified.

The monthly pass covers the commute. The favorited routes cover the driving. The reserved seats cover the regulars. And the registered segments cover the price range. Not all of it. Enough of it.