Why Offchain Compute Matters on Solana

As crypto applications expand into real-world domains like finance, AI, DePIN, and retail trading, they are beginning to hit infrastructure ceilings. On Solana, for instance, over 95% of high-frequency trading (HFT) transactions still fail due to unpredictable execution, highlighting a growing gap between what modern apps demand and what monolithic L1 compute can reliably deliver.

Robinhood’s launch of a tokenized stock platform exposed this gap more clearly than ever. Instead of building on Solana, they chose Arbitrum.

Why? What did they need that Solana couldn’t offer yet?

Could this have been built on Solana?

Solana was a serious contender. Robinhood already supports Solana staking and offers zero-fee wallet access. As of May 2025, it had been actively evaluating both Arbitrum and Solana as the base layer for its EU trading service, before ultimately selecting Arbitrum.

Robinhood’s infrastructure requirements and chain selection

Robinhood’s tokenized trading platform, launched on June 30, 2025, marked a major convergence of regulated finance and crypto infrastructure. It enables 24/7 access to over 200 U.S. stocks, ETFs, and high-profile private equity shares like SpaceX and OpenAI.

To meet the demands of real-time trading, regulatory compliance, and future composability, Robinhood chose to build on Arbitrum Orbit. The decision was driven by a need for fine-grained control over transaction sequencing, infrastructure-level customizability, and protocol logic, all critical for supporting 24/7 tokenized equities under strict compliance requirements.

Robinhood needed an infrastructure that could:

• Satisfy strict compliance requirements (KYC, AML, securities rules)
• Support both retail users and institutional partners
• Guarantee deterministic, MEV-resistant transaction ordering
• Enable smart contract development in Rust and C++ (via Stylus)
• Deliver low-latency execution for real-time markets
• Integrate deeply with Robinhood Wallet, Bitstamp, and future DeFi products
• Remain composable with existing EVM-based liquidity and tooling

Arbitrum Orbit met these demands through full-stack customization:

• Stylus for Rust/C++ smart contract support within a multi-VM environment
• Queue-based sequencing to enforce fair ordering and reduce front-running
• Sub-250ms block times for institutional-grade performance
• EVM compatibility for seamless DeFi integrations
• Launchpad access via Arbitrum One, with optional migration to Robinhood’s own chain
• Immediate composability with protocols like Uniswap, GMX, and Aave

Granular control over transaction sequencing and infrastructure-level customization were two of the most critical requirements for Robinhood’s tokenized stock platform.

As Johann Kerbrat (GM of Robinhood Crypto) put it:

“We want to make sure that we can control the products we launch… and build tools that others can build on.”

By running their own single sequencer, Robinhood can prevent front-running and other practices that would be illegal in traditional markets. Orbit’s customizable architecture gave them the ability to control how blocks are built, how transactions are ordered, and how upgrades are managed, all essential for regulatory compliance.

Could this have been built on Solana?

The answer isn’t a simple yes or no.

But with execution upgrades like APE live and consensus overhauls like Alpenglow and MCL underway, Solana’s architecture now meets most of Robinhood’s needs and is on track to support the rest.

Key offchain compute protocol upgrades and validator incentive changes have fundamentally changed what’s possible, especially for apps demanding real-time execution, compliance alignment, and sequencing guarantees.

Originally, Solana’s architecture PoH, Tower BFT, and a single-leader schedule, were tuned for fast, parallel execution of simple transactions. It worked well for DeFi, but tightly coupled consensus and execution, limiting flexibility. Finality delays and lack of deterministic control made it hard to build complex, regulated systems like Robinhood’s.

That’s changed. Let’s walk through what Solana now enables and what still needs work.

Solana's protocol upgrades enable offchain compute

Asynchronous Program Execution (APE): Decoupling Consensus from Execution

Solana’s traditional model tightly coupled consensus with user transaction execution. Every block had to wait for all user programs to finish even slow ones, before finality. 

APE changes this by separating consensus logic and user logic into two execution domains:

• Vote Execution Domain (VED): Executes fast, system-level operations necessary for consensus (e.g., votes, SOL transfers).
• User Execution Domain (UED): Executes user-facing smart contracts like token transfers, DeFi, or governance.

This split unlocks several critical benefits:

• Faster finality: Validators can vote and finalize based on the fast VED path, even if UED programs are still processing.
• Fault isolation: A stuck or faulty contract no longer stalls consensus.
• Parallelism: Voting and user program execution can run concurrently, even across different hardware.

🟢 Status: Live on Mainnet since late 2024. Already powering improved reliability and throughput in production workloads.

Multiple Concurrent Leaders (MCL): Scaling through parallel Block Production

Solana used to appoint a single leader per slot, giving that validator total control over which transactions were included. That was fast, but centralized and prone to MEV.

MCL breaks this model by assigning multiple leaders per slot, each operating a distinct lane (Lane A, Lane B, etc.), producing blocks in parallel. This introduces:

• Higher throughput: More leaders = more transactions per second.
• User choice: Users can submit transactions to specific lanes or leaders, avoiding monopolies or poor QoS.
• Reduced MEV: No single leader controls ordering across the entire block.
• Rollover capacity: Unused compute from one lane can be carried forward to others.
• Sequencing flexibility: Each lane can be optimized for different inclusion policies or applications.

🟡 Status: Under active development. Initial MCL prototypes are running in test environments, but no mainnet deployment timeline has been announced.

Alpenglow (Rotor + Votor): Finality Under 150ms

Solana’s new consensus engine, Alpenglow, discards older mechanisms like Proof of History and Tower BFT in favor of simpler, faster primitives:

• Rotor: One-hop, rapid block propagation across validators.
• Votor: Off-chain, BLS-signed votes aggregated into consensus certificates.

Alpenglow reduces finality time from 12.8 seconds to ~100–150ms, while:

• Eliminating vote transactions (no blockspace overhead)
• Simplifying consensus logic (no lockouts, no hash clocks)
• Improving validator economics (no fees to vote = smaller validators can participate)
• Enhancing safety and liveness (tolerates 20% adversarial + 20% offline)

🟠 Status: Announced at Accelerate in May 2025. Reference implementation exists on GitHub, but deployment to mainnet is targeted for early 2026, pending community review, SIMD formalization, and governance vote.

Competitive Block Building Market

At its core, offchain compute can only function if validators reliably accept, order, and include externally coordinated transactions. This shifts the problem of execution from being purely technical to being deeply economic.

Solana has taken meaningful steps toward enabling a competitive block-building market, where validators are economically incentivized to behave predictably and align with application needs:

• SIMD-0096 routes 100% of priority fees to validators, creating the basis for sustainable inclusion markets. This change in 2024 replaced the previous 50/50 burn-split model and now directs all priority fees to the block leader.
• SIMD-0123 will soon introduce native protocol-level reward sharing, allowing validators to automatically distribute any block revenue—fees, tips, or external payments—to all stakers. This change has been approved via governance, but not yet live as the implementation is pending engineering coordination.
• SIMD-0212, 0180, 0185 introduce formal slashing frameworks to penalize censorship, double-signing, and failure to include valid transactions. While currently under discussioon, these proposals are expected to be activated alongside upcoming consensus upgrades (e.g. Alpenglow) to enforce deterministic inclusion and improve validator accountability.

By tying validator rewards to application-aligned behavior, Solana builds the foundation for offchain coordination to thrive. It fosters a staking environment that is not just performant but accountable, reducing the risk of malicious behavior, slot manipulation, or transaction exclusion.

This incentive overhaul is essential for apps like Robinhood that depend on external sequencing systems, and seek strong guarantees around transaction inclusion and block-building fairness.

So, Time of Truth: Could Robinhood have chosen Solana?

Almost. Once APE, MCL, and Alpenglow are in place, Solana now delivers many of the core requirements of Robinhood:

• Sub-150 ms settlement for real-time trading (via Alpenglow)
• Deterministic inclusion lanes with lane-specific control (via MCL)
• Off-chain coordination without blocking consensus (via APE)
• Validator alignment with app-level logic (via SIMDs 0096/0123/0228 + slashing)

On raw speed, cost, and throughput, Solana is at parity or better than Arbitrum Orbit.

What’s still not yet fully met are two regulatory-critical factors:

End-to-end authority over block-building: MCL lets Robinhood steer order flow into a dedicated lane and negotiate policies with the leaders scheduled for that lane. That sharply reduces MEV exposure, but ultimate inclusion still rests with a rotating validator set. Orbit goes one step further: a single, in-house sequencer from day one, giving auditors a clean, centralized trail.

Sovereign runtime & upgrade path: On Solana, Robinhood can ship upgrade--controlled programs (e.g., only their signer can deploy new versions) and even run a high-stake validator cohort to shepherd changes. Final say on the base runtime, though, still sits with the wider network. Orbit chains are fully self-governed: Robinhood chooses the VM mix (EVM + Stylus Rust/C++) and can hard-fork or add KYC logic on its own schedule, without waiting for L1-wide consensus.

In short, Solana’s new design meaningfully mitigates the control gaps that once ruled it out, but Orbit still provides the all-inclusive, regulator-friendly sovereignty Robinhood was after.

And yet, real-world prototypes already exist.

Drift, Solana’s leading perpetuals DEX, combines off-chain sequencing (via its Swift sidecar) with on-chain settlement, enabling low-latency trading and execution control exactly what apps like Robinhood require.

With JIT auctions, Pyth oracles, and USDC cross-chain routing via CCTP, Drift shows that MEV-aware sequencing, regulatory-grade pricing, and composable settlement are already live on Solana.

What’s missing is a generalized coordination layer that all apps can use without building custom sidecars or sequencers.

That’s where Raiku enters the picture.

Introducing Raiku: Bringing Deterministic Control to Solana via Edge Compute

Raiku launched in 2024 to address the final missing piece in Solana’s infrastructure: enabling applications to guarantee transaction inclusion, enforce custom sequencing policies, and apply offchain compliance logic, without launching a separate chain.

While Solana’s protocol upgrades, APE, MCL, and Alpenglow, introduce core capabilities like asynchronous execution, parallel block production, and sub-150ms finality, they don’t fully address the needs of applications that require deterministic control over execution, especially in regulated or high-frequency environments.

Raiku fills that gap by introducing an off-chain, edge compute layer that operates just outside consensus but in tight coordination with Solana validators. This coordination is powered by a new system of validator-run sidecars and a programmable scheduler (Ackermann-node), which collectively enable:

• Guaranteed inclusion through Ahead-of-Time (AOT) and Just-in-Time (JIT) slot reservations: Secure blockspace exactly when it’s needed, even during peak congestion.
• Application-level filtering, such as KYC checks or jurisdiction-specific rules: Enforce compliance logic off-chain without delaying transaction flow.
• MEV-resistant ordering aligned with business logic: Customize transaction sequencing to minimize front-running and align with app priorities.
• Pre-confirmations before finality, improving UX and compliance confidence: Deliver early execution guarantees to users and market participants.
• Execution-layer flexibility via Raiku’s upcoming Global Account Model, supporting SVM, EVM, and Move: Deploy across multiple VM environments while maintaining shared coordination and control logic.

Rather than modifying Solana’s protocol, Raiku builds on top of it, embedding deterministic guarantees into how slots are scheduled and filled. This off-chain edge coordination allows builders to maintain the speed, liquidity, and composability of Solana while gaining the predictability and auditability required for real-world deployment.

If Raiku had existed in early 2025 on mainnet, Robinhood wouldn’t have needed to launch a custom Arbitrum Orbit chain. With Raiku, sequencing guarantees, custom filters, and inclusion control can now be deployed natively on Solana.

We’ll explore how Raiku enables offchain compute in depth in the next article, but for now, it’s clear that with Solana’s protocol upgrades and Raiku’s coordination layer, applications like Robinhood could have been built natively, without compromising on compliance or performance.