In an effort to solidify its position as decentralized Nasdaq, complexity on Solana is set to compound, and the importance of transaction landing services for low latency traders and apps is about to increase meaningfully.

In response to this, we’re launching Zela, the most architecturally advanced execution platform on Solana. Zela is a remote procedure execution platform that collapses the entire transaction workflow - read, compute, simulate, decide and submit - into a single near-producer execution. It combines DoubleZero fiber, colocation, high-staked transaction forwarding, and soon, raw shred delivery, into a single, high-performance integrated stack purpose built for low latency actors.

OVERVIEW

The Tx Landing Market Today

Transaction landing on Solana today is beget with extraordinary complexity, which leads to poor UX for low latency actors, e.g. searchers, liquidation bots, and market makers.  

The complexities ultimately translate into wasted hardware and bandwidth resources and wider spreads for retail. Validator hardware requirements are higher than otherwise, leading to a higher degree of validator centralization than otherwise. Low latency traders spend precious hardware resources blasting duplicate transactions instead of finding the next arb, and incur unnecessary fees along the way. And most importantly, because landing is fraught with uncertainty, total trading costs are higher than otherwise, holding back broader ecosystem growth.  

Market noise is visible in the numbers. 74% of all ingress traffic is duplicate. Bots-sent transactions have a 58% failure rate. Only 1.3% of raw tx ingress attempts that reach the leader actually gets packed into the block. The transaction landing market today is a reflection of this complexity. There are dozens of providers, and serious players must use a handful of providers by necessity.  

Complexity Before The Leader

Here we visualize the complexity from the point a transaction is sent to the network to the time it finally lands.  

Every yellow box on this diagram is a place where your transaction can die or get delayed. To be clear, these are not points where the transaction fail, i.e., make it into the block, but fail to change state due to a rule violation. They are points where transactions simply disappear. No error message, no logs, just gone. The leader never sees them.  

There are multiple ways that transactions delay or drop before they even reach the leader. To name a few, the RPC picks the wrong leader. The validator is unstaked and dropped during congestion. Jito bundles get priority. Network jitter pushes you past the slot boundary or packets get lost.  

Within the leader, it may decide your transaction is not interesting. There is a lot of talk about schedulers on Solana today, and scheduling is a valid problem space. But it’s important to contextualize: all of this happens before the scheduler ever touches your transaction.  

Complexity at the leader

This diagram details what happens inside the leader.  

First, your transaction passes SigVerify (most don’t). In case the RPC aimed to the incorrect validator, it may even hold you transaction and not send it to current leader. Next, it enters the scheduler’s heap, ordered by fee per compute unit. Here arises an issue - the heap continuously fills and drains. A transaction that arrives 1ms later waits for the next round. So your position is a mix of how much you paid and when you showed up.

If your transaction conflicts with another, they go to the same thread, sequentially. The one with higher fee goes first. A taker knows their profit and can rationally outbid your cancel every time.

The blue line at the bottom is the Jito block engine. Bundles bypass the validator's local SigVerify stage because the Block Engine has already verified signatures upstream, and they execute on a dedicated BundleStage thread. During the first 80% of a slot's PoH ticks, the validator partially reduces compute capacity available to non-bundle transactions, giving Jito bundles a structural head start.  

Bottom line: you only control two things: speed and fee.

Multiple Ways to Lose

The compounding complexity creates an environment where low latency players and their RPC  
& transaction landing service providers can lose in many ways.  

With too many routing variables and no clear optimal path, traders are forced to guess between TPUs, bundles, RPCs, and SWQoS. Even when they commit to a path, silent failures and limited observability leave low latency actors blind to what went wrong. Paying more through priority fees offers no guarantee of position, as standard TPU access is perpetually crowded out by bundles. And ultimately, the validator leader's full discretion over inclusion and ordering means the outcome was never truly in the trader's hands to begin with.

All this, and complexity on Solana is about to compound further. Four major changes are coming to the Solana network, all seemingly within the next 12 months.  

Agave 4.0 removes SWQoS as a reliable edge. Alpenglow compresses finality and frees up block space. Constellation breaks the single-leader monopoly on inclusion and ordering. And ACE lets applications define their own transaction ordering directly. Most importantly, these changes are seemingly imminent. Agave 4.0 is rolling out right now, Alpenglow passed governance with 98% support, Constellation's whitepaper is published, and BAM is already live.

While these protocol changes bolster censorship resistance, they compound the network complexity and shift competitive advantage toward low-latency, topology-aware execution.

ZELA

Zela & Remote Procedure Execution

This is why we built Zela, RockawayX's remote procedure execution (RPE) platform. Zela compresses and colocates the entire low latency pipeline to nodes across the globe: read, compute, simulate, decide & submit – all abstracted away for low latency actors. It integrates private DoubleZero fiber routing, colocation, staked transaction forwarding, and, in the future, raw shred delivery into a single stack.

Here we quickly review the core pillars of Zela’s mechanism.  

• Remote Procedure Execution (RPE). This is Zela's zero-to-one innovation. Where traditional RPC workflows require multiple round-trips between a remote backend and the chain, RPE enables the ability to execute your app logic directly on nodes colocated with nodes around the world. Said another way, instead of executing transactions over the network, RPE allows low latency actors to execute on collocated nodes. RPE executes custom logic in a WebAssembly sandbox on nodes physically colocated with Solana validators across the globe, collapsing the entire workflow - Read, compute, simulate, decide and submit - into a single near-producer call.  

• Colocation / “Follow The Leader” Routing. Zela maintains executor nodes co-located with high-staked validators in Tokyo, Frankfurt, and Dubai, with always-on routers streaming the slot/leader feed. Each procedure call is dispatched to the executor closest to the current leader, and as Solana moves to Constellation, to the relevant proposers in parallel.

• DoubleZero fiber. Zela routes data and transactions over DoubleZero's private fiber network, bypassing public internet congestion entirely. DoubleZero already covers more than 50% of all Solana stake. Its FPGA-based edge filtration strips duplicates and filters spam before traffic ever reaches a validator's CPU, materially reducing validator overhead while improving transaction quality. The system will also enable DoubleZero Edge shreds for early state awareness.  

Why Now

Solana is about to undergo its most consequential architectural change in its history. Four upgrades – Constellation, Alpenglow, Agave 4.0, and ACE – and changes in between will collectively reshape how transactions are processed, ordered, and land on Solana. We believe these network upgrades represent an expansion of Zela’s value proposition to low latency actors.  

‍Constellation: A Multi-Proposer World Built for Zela's Architecture

Constellation is the most structurally significant of the four upgrades, and it is also the one that most directly validates the assumptions underlying Zela's design.

Under the current single-leader model, the network's latency bottleneck is relatively blunt - one validator controls the block, and the race is simply to reach that leader faster than everyone else. Constellation replaces this with 16 concurrent proposers. At first glance, this might seem to dilute the value of collocation. In practice, it does the opposite: it puts a premium on routing intelligence.

With 16 proposers active simultaneously, low latency actors must now make an increasingly complex set of decisions: which proposers to target, and how to weight them by trust, geographic proximity, attester connectivity, and current congestion. This is precisely the kind of multi-variable optimization that Zela's distributed collocation infrastructure is built to perform. Rather than "follow the leader," the new paradigm is "intelligently route to the right proposers". Zela's architecture, with nodes positioned across the network, is well-suited to serve multiple proposers in parallel.

Solana's compression of block production to 200-millisecond windows, further subdivided into 50-millisecond cycles, has an equally important consequence: it dramatically reduces the leverage that auctions exert over transaction ordering.  

Today, a well-funded participant can simply outbid rivals and wait. Under Constellation, the window inside which tip-based reordering is even possible collapses to 50 milliseconds per sub-phase. In that environment, being early matters simply paying more, and low-latency infrastructure becomes more relevat.

Constellation's new scheduler compounds this effect. The current continuous processing loop creates a perverse dynamic where a low-priority transaction submitted early can be repeatedly displaced by higher-priority arrivals, potentially waiting for a long time. Constellation's group-processing model collects ready transactions per cycle and processes them together, meaning a transaction's arrival time affects which cycle it lands in, and missing the cutoff pushes it to the next 50ms window.  

Finally, validator plugins are often relied on to reorder transactions across an entire leader's block, but these tools could face challenges under Constellation. A plugin that could once control a full block can now influence at most one of sixteen proposers during a single 50-millisecond cycle. Moreover, these services promise clients priority block positioning. Even with multiple proposers running the plugin, any non-participating proposer's transactions can land ahead of a client's most expensively prioritized one. Legacy validator plugins must adapt to these changes.

Alpenglow: More Capacity, Better Data Distribution

Alpenglow's two mechanisms, Votor and Rotor, both work in Zela's favor, though through different channels.

Votor moves validator voting entirely offchain. Vote transactions currently represent approximately 75% of Solana's transactions. Alpenglow frees all of it for non-vote transactions. Validator votes, which currently consume enormous scheduler and heap capacity, will be handled offchain. This frees substantial compute for non-voting transactions, meaning the scheduler's heap will be materially less congested.  

In the current environment, low latency but low-priority fee transactions are frequently pushed aside by the sheer volume of high priority traffic. As that congestion eases, Zela's approach - prioritizing arrival time and intelligent routing over fee escalation - becomes less disadvantaged relative to pure fee-based transaction landing strategies.

Rotor replaces the current Turbine data distribution tree, which is slower and creates significant propagation inequality between the first and last to receive data. With Rotor, data distribution is faster. For Zela, which depends on keeping its geographically distributed RPE nodes current with the latest chain state, this is a direct operational improvement. Fresher data at every node means better routing decisions and more reliable transaction simulation.

Agave 4.0: Staked Weight of Service Loses Edge

Agave 4.0 demotes SWQoS from a primary congestion-management tool to a backstop applied only during peak congestion. Under the current regime, stake-weighted connections receive preferential treatment regardless of conditions, giving services that simulate or accumulate stake a structural advantage. That advantage shrinks significantly under Agave 4.0. With SWQoS no longer a dominant factor in normal operating conditions, the relevant variables shift back toward routing, colocation, and fees, favoring Zela’s approach.  

ACE: A Nuanced Effect

ACE introduces a mechanism by which smart contracts can define their own transaction ordering. For those participants, this means they may no longer need to compete in the priority fee auction or invest in low-latency infrastructure.  

The effect is bounded: ACE benefits only those actors whose transactions are processed within ACE-enabled contracts, and the broader ecosystem of retail users, arbitrageurs, and protocol interactions outside ACE-enabled contracts remains fully exposed to the latency and fee dynamics that Zela addresses.

The Broader Picture

Across these four upgrades, a consistent pattern emerges: Solana is becoming an environment where the complexity of optimal transaction submission increases, where low-latency infrastructure gains importance relative to auction strategies, and where blunt tools - validator plugins, stake simulation, and bundles - may lose effectiveness.  

That asymmetry, compounded across four simultaneous architectural shifts, is why we see a structural need for Zela’s Remote Procedure Execution platform for low latency actors on Solana 2.0.