Robinhood could have been built on Solana: here's why

ICYMI: In our last post, we broke down why Robinhood chose Arbitrum Orbit for its tokenized stock platform, not because Solana lacked performance (it doesn’t, especially with current and upcoming offchain upgrades that push finality to just 150 ms), but because Solana didn’t offer complete control over transaction ordering (needed to protect against MEV) and the customizability Robinhood required.

Arbitrum Orbit: Control came at the cost of Interoperability

In traditional finance, trade manipulation like front-running and back-running is illegal; intermediaries must guarantee fair, ordered execution. Onchain, where public validators can’t enforce this, Robinhood needed infrastructure that gave it full control over transaction ordering.

That’s why it chose Arbitrum Orbit: by operating its own sequencer, Robinhood could completely block MEV, ensuring trades weren’t reordered, front-run, or back-run, a critical requirement for compliance and auditability.But this control came at a cost: Robinhood lost seamless access to the broader DeFi ecosystem, as L2 chains like Orbit lack built-in interoperability.> Liquidity was locked inside a walled garden, cut off from broader DeFi markets, smooth cross-chain interaction, and easy connection to the rest of the ecosystem. Arbitrum Orbit chains don’t enjoy plug-and-play access to other Orbit chains or external networks.

As a result, users must rely on intermediaries to move assets and execute logic across ecosystems, often incurring additional costs, all while operating within a tightly permissioned framework.

Why Solana alone is not enough and how Raiku makes it possible

Solana is one of the fastest blockchains in the world — thanks to its monolithic design, where all apps share the same runtime. This allows seamless composability with other programs, like oracles, stablecoins, or DeFi protocols, without bridges or extra infrastructure.

But this shared design comes with exactly the limitations Robinhood couldn’t accept.

Apps can’t decide the order of their own transactions. The same validator set processes everything together, so a trading app can’t guarantee when a trade will go through or prevent it from being MEV'ed. It also can’t easily build in compliance checks or enforce custom rules, because execution is handled uniformly across all apps.

That’s where Raiku comes in.

Raiku gives apps on Solana the kind of control they usually only get on app-specific chains, but without sacrificing Solana’s performance or its access to a vibrant, shared ecosystem. 

With Raiku, apps can:

• Eliminate MEV exposure 
• Choose when and where their transactions are included
• Reserve space in future blocks through slot auctions
• Receive cryptographic pre-confirmations before final settlement
• Run compliance checks and business logic privately, and only publish final results onchain

Before we walk through how Robinhood could run on Raiku and trace the full transaction lifecycle, it’s important to understand the two execution models Raiku supports: native apps and extension apps.

• Native apps run directly on Solana but get enhancements like scheduled inclusion, early confirmations, and reduced MEV exposure.
• Extension apps run their execution logic privately, maintain full control over transaction sequencing, and only submit finalized results to Solana. They’re ideal for applications that require regulatory compliance, custom runtime environments, and strict control over how and when transactions are ordered for protection against all forms of MEV.

Let’s now break down the core components that make this possible.

Raiku Components

1. Ackermann Node

The Ackermann Node is the offchain brain of Raiku. Think of it as a decentralized scheduler that gives applications control over how, when, and where their transactions land on Solana, without modifying Solana’s core consensus.It orchestrates the entire lifecycle of a transaction and enables guaranteed transaction inclusion through the following systems:

a. Slot Auctions (AOT / JIT)

Raiku’s Ackermann Node enables applications to reserve blockspace through two slot auction modes: Ahead-of-Time (AOT) and Just-in-Time (JIT). These mechanisms provide guaranteed transaction inclusion and significantly reduce exposure to MEV attacks, such as front-running or sandwiching, by bypassing the public mempool.

With AOT scheduling, Robinhood can reserve specific future slots in advance, like booking a time on a calendar. These slots are secured ahead of time, so transactions never enter a mempool, meaning they’re invisible to other actors and fully protected against MEV, including front-running and reordering. This guarantees precise timing, enables early confirmations for users, and supports regulatory workflows.

AOT is ideal for predictable operations like daily Net Asset Value (NAV) reports, which require accurate and consistent valuation snapshots, as well as compliance-driven trade batches or scheduled settlements, where certainty and auditability are critical.

With JIT scheduling, Robinhood bids for a slot just moments before submitting a trade. This gives it flexibility to react quickly to market conditions, such as large Requests for Quotes (RFQs), where a buyer asks multiple sellers for price quotes, or high-frequency trades, while still keeping the trade completely private until it’s confirmed.

The transaction is submitted directly to the selected validator without entering any public or private mempool, which prevents other actors from seeing or exploiting it before inclusion. While JIT also protects against MEV, it carries slightly more risk than AOT since it's executed closer to real-time, where misbehavior by validators could have more impact.

In short:

• AOT provides the strongest MEV protection and guaranteed inclusion for scheduled trades.
• JIT offers fast execution and hidden order flow for reactive trades, with slightly less MEV protection due to its immediacy.

b. Quality of Service (QoS) Guarantees

Quality of Service (QoS) refers to how reliably and predictably a system delivers on its performance promises, especially when demand is high. In Raiku, QoS is about ensuring that certain transactions are prioritized and included exactly when they need to be, while still making room for lower-priority flows.

Raiku introduces two levels of QoS to help apps like Robinhood balance deterministic inclusion with throughput efficiency:

Slot-Inclusion QoS (siQoS):Reserves a configurable portion of each Solana block (e.g., 25%) specifically for transactions that win Raiku’s AOT or JIT slot auctions.

Stake-Weighted QoS (swQoS):Allocates the remaining bandwidth based on validator stake and performance. This path is suitable for lower-priority or cost-sensitive trades, allowing Robinhood to optimize for throughput while maintaining reliability.

Together, siQoS and swQoS form a layered QoS system that gives Robinhood determinism for compliance-sensitive flows and flexibility for everything else.

c. Transaction Classification and RoutingEach transaction is matched to the best validator based on policy, load, and slot availability.Ackermann evaluates:

• The leader schedule
• Validator stake and uptime
• Sidecar availability and health
• Current network bandwidth
• Any custom Robinhood constraints (e.g., SOC 2 compliance)

This intelligent routing ensures transactions are delivered on time and through trusted infrastructure. Ackermann also tracks validator reliability over time to improve future routing decisions.

d. Pre-Confirmation SignalsPre-confirmations are cryptographic promises that a transaction will be included in a specific slot, even before it reaches finality onchain. They give applications like Robinhood early assurance that a trade is locked in, enabling faster user feedback and regulatory certainty.

• For siQoS-based transactions, Ackermann sends a cryptographic pre-confirmation once the slot is secured. This lets Robinhood show users an instant “Trade Confirmed” status even before onchain finality.
• For swQoS-based transactions, soft pre-confirmations may be issued if validator capacity and reliability thresholds are met.

e. Fallback and Penalty LogicIf inclusion fails, Ackermann can reroute the transaction to an alternate validator or sidecar. If no alternative is viable, fallback to swQoS or native submission is triggered.Validators that miss pre-committed slots may be penalized or deprioritized in future routing decisions, preserving reliability under network stress.

2. Ackermann Sidecar

Every Solana validator running Raiku also runs a Sidecar, a lightweight process that enforces Ackermann’s offchain scheduling decisions.Once Ackermann assigns a transaction to a validator, the Sidecar takes over:

• Queues and executes the transaction according to QoS class (siQoS or swQoS)
• Enforces slot inclusion guarantees, especially for high-priority siQoS lanes
• Runs local checks for pre-confirmation logic (e.g., balance, compliance, risk models)
• Monitors validator execution and reports missed slots or failures to Ackermann

In short, the Sidecar bridges offchain coordination and onchain execution, ensuring Raiku’s scheduling logic is enforced precisely and reliably across the network.

3. Global Account Model

Raiku’s Global Account Model (GAM) allows both native and extension apps to interact with Solana’s global state in a unified and composable way.

• Native apps continue using Solana’s built-in VM and runtime as usual.
• Extension apps can run on custom VMs like EVM, Move, or WASM, executing logic outside Solana’s runtime, yet still commit state changes back to Solana through GAM.

This gives developers the flexibility to use specialized execution environments without fragmenting liquidity or making it less composable.It’s similar in spirit to what Arbitrum Orbit offers with Stylus, which lets apps write contracts in Rust or C++ alongside Solidity. That flexibility was one of the reasons Robinhood chose Arbitrum, but with Raiku, extension apps can gain that same flexibility while staying connected to Solana’s shared global state.

Two Paths for Robinhood on Solana

With these components in place, Raiku unlocks two distinct paths for Robinhood to go live on Solana: as a native app or as an extension app.

What if Robinhood used Raiku as a Native App on Solana?

If Robinhood ran as a native app using Raiku, its trades would still execute inside Solana’s runtime, but with major enhancements, here is how it would look like:

1. A user places a trade (e.g., buying tokenized Apple stock).
2. Robinhood submits the trade to the Ackermann Node via Raiku SDK.
3. Ackermann schedules the trade using either:
   1. AOT for pre-scheduled flows (e.g., NAV batches).
   2. JIT for live market reactions (e.g., RFQs, HFTs).
4. Once the slot is secured, Robinhood receives a cryptographic pre-confirmation.
5. The transaction is privately delivered to the selected validator.
6. The validator executes the trade in Solana’s runtime at the exact scheduled time.
7. Final confirmation is returned; state changes are recorded onchain.

Benefits of Native Apps (with Raiku):

• Deterministic inclusion: Robinhood knows exactly when a trade will land, thanks to AOT/JIT slot auctions.
• Network-layer MEV protection: Trades bypass the public mempool and are privately routed, reducing front-running and sandwich risks at submission.
• Pre-confirmations: Cryptographic pre-acks give users real-time confidence before final settlement.
• Shared liquidity: Native apps run inside Solana’s global state, ensuring seamless access to DeFi protocols, stablecoins, oracles, and other programs.

But Native Apps aren’t enough

Even with Raiku’s upgrades, native apps still run inside Solana’s shared runtime, which limits control in key areas:

• No custom execution logic: Native apps must use Solana’s standard VM, making it hard to embed KYC checks, per-user limits, or internal risk models.
• No private sequencer: Apps can’t fully control the order of their own transactions, which is critical for batching, matching, and enforcing compliance rules.
• MEV exposure remains: While Raiku removes public mempool risk, validators may still share order flow privately, exposing trades to front-running or sandwich attacks.

For a regulated platform like Robinhood, that’s not enough. Full control requires private execution, which only extension apps provide.

Introducing Raiku Extensions as the complete Solution

Extension apps follow the native app flow up to execution but offload logic to a dedicated infrastructure, giving platforms like Robinhood:

• Independent Sequencer: Full control over transaction ordering to prevent MEV risks.
• Off-Chain Simulation: Batch, match, and validate trades before on-chain submission.
• Custom Compliance Logic: Enforce KYC, risk rules, and regulatory filters.
• Custom VM Support: Execute logic outside Solana’s standard VM.
• Single Commitment: Submit only final outcomes on-chain.
• Execution Sovereignty: No reliance on validator-side ordering, ensuring privacy and composability with Solana’s ecosystem.

Settlement occurs onchain, but execution logic remains under Robinhood’s control, balancing control with interoperability.

How It Works: Step-by-Step Flow

1. Private Sequencer for Transaction Ordering:User trades enter Robinhood’s private sequencer, avoiding public or private mempools to eliminate MEV risks like sandwich attacks. The sequencer enforces internal rules (e.g., per-user throttling, exposure limits, real-time risk checks), ensuring deterministic ordering critical for financial products, unattainable in Solana’s shared runtime.
2. Offchain Simulation in Custom VM:Trades are bundled into a batch and processed in Robinhood’s custom virtual machine (e.g., LightSVM or WASM-based engine). The VM simulates pricing, fee logic, and order matching deterministically. Raiku’s GAM enables interoperability with Solana’s global state, ensuring seamless integration while keeping execution self-contained.
3. Ackermann Node Schedules Batch via siQoS:The finalized transaction batch is sent to the Ackermann Node, which routes it through siQoS using AOT or JIT auctions. The Node reserves a validator slot for guaranteed inclusion, optimizing for timing and reliability.
4. Pre-Confirmation for User Feedback:After scheduling, the Ackermann Node sends a cryptographic pre-confirmation to Robinhood’s UI, enabling an instant “Trade Confirmed” status. This supports compliance workflows and enhances user experience, though finality depends on Solana’s consensus.
5. Sidecar Validator Executes Batch:The transaction batch is delivered to the assigned validator’s Ackermann-sidecar. When the reserved slot arrives, the Sidecar forwards the batch to the block leader for inclusion in the block.
6. Finality on Solana:Solana’s consensus finalizes the batch within ~150ms (via upgrades like APE/MCL). Robinhood’s UI updates from “confirmed” to “finalized,” reflecting the completed trade.

Why Extensions are ideal for Robinhood

Raiku’s extension model gives Robinhood more control and flexibility than it had on Arbitrum Orbit, while keeping the speed and interoperability of Solana. Key benefits include:

• MEV Protection with Private SequencingWith a custom sequencer powered by Raiku Extensions, Robinhood decides exactly when and in what order its trades are processed. This prevents anyone else from interfering with the trade — no jumping ahead (front-running), no following behind (back-running), and no inserting trades around it (sandwiching).
• Custom Execution EnvironmentsExtensions let Robinhood use custom virtual machines to enforce internal logic like KYC/AML checks, risk scoring, and SOC 2 controls, all critical for regulated trading.
• Composable Settlement via Global Account Module (GAM)Even though execution happens off-chain, Robinhood can still settle to Solana’s shared state. That means it retains seamless access to DeFi protocols, stablecoins, oracles, and liquidity, unlike Orbit, which isolates liquidity on each app-chain.
• Full Execution Sovereignty Without FragmentationRobinhood gets rollup-like control without leaving the Solana ecosystem or giving up shared security, atomic composability, or low-latency finality.

Raiku’s extensions empower Robinhood to build a tokenized stock platform on Solana, surpassing the control of Arbitrum Orbit’s sequencer model while leveraging Solana’s high performance and interoperability. The private sequencer eliminates MEV risks like sandwich attacks (50% of Solana’s MEV, per Helius) by avoiding mempool exposure. Custom VMs enable compliance logic (e.g., KYC/AML, SOC 2) and complex trade execution. GAM ensures seamless integration with Solana’s DeFi ecosystem, overcoming Orbit’s liquidity isolation for a scalable, secure, and compliant platform.

So, is Robinhood and the next wave of institutions ready for Solana?

Absolutely yes.

With Raiku, Solana gives Robinhood the best of both worlds: institutional-grade execution control and full access to the world’s fastest, most composable Layer 1. 

Robinhood now gets everything it needs: guaranteed transaction inclusion via AOT/JIT auctions, flexible sequencing, off-chain simulation, embedded compliance logic, and full execution control, all while staying composable on Solana’s global state. No rollups, no bridges, no liquidity fragmentation, and no tradeoffs on performance or auditability.

Raiku makes Solana ready not just for Robinhood but for every institution that needs compliance-grade execution without giving up speed or composability. Arbitrum may have won Robinhood, but the next wave, Fidelity, Visa, Stripe, FanDuel, is still wide open.

Solana is ready. Raiku makes it possible.