Raiku: Determinism for Payments

There is a hidden uncertainty behind “instant” payments.

Modern payments look seamless; balances update instantly, transfers show as complete, and merchants see funds as received. But beneath that polished experience lies deep uncertainty. What users see isn’t a final settlement; it’s a temporary promise that gets reconciled later (manually matched and verified between banks to confirm that the money actually moved).

Behind every “instant” transfer is a slow process of fund movement, credit extension, and reconciliation. Actual money, known as settlement, moves hours or even days later through legacy banking rails.

What Settlement really means

Settlement is when money truly clears between financial institutions, not when your app updates. Each part of the system handles this delay differently:

Neobanks (e.g., Chime, Revolut, Monzo)

‍Neobanks rely on ACH or SWIFT for actual settlement. They credit balances instantly, but only receive funds overnight or the next day. To simulate instant transfers, they front capital and reconcile later, effectively turning every “instant deposit” into a short-term loan.

Payment Processors (e.g., Stripe, Checkout.com, PayPal)

‍Processors give merchants immediate payout confirmations even though underlying ACH or card payments settle days later. They absorb this gap by advancing funds and handling retries, chargebacks, and reconciliation in the background.

Cross-Border Corridors (e.g., USD ↔ EUR)

‍SWIFT doesn’t move money; it just sends messages. Settlement passes through chains of correspondent banks, often taking 1–5 business days and costing $15–$50 per transfer. To maintain predictability, banks pre-fund foreign accounts and reconcile once the money arrives.

Across all these systems, “instant” payments are manufactured illusions. Institutions maintain them through pre-funding, credit floats, and reconciliation loops, not to make payments fast, but to make them predictable enough for payroll, FX, and treasury operations to function.

Stablecoins Changed the Game

Stablecoins showed there’s a simpler way: real, final settlement on public blockchains. A USDC transfer doesn’t wait for overnight cycles or correspondence chains; it settles globally within seconds. The market’s response is clear: in less than five years, stablecoin volumes have reached around 40% of U.S. ACH volume.

The Next Step

With stablecoins proving that money itself can move instantly, the next logical step is to build payment infrastructure on top of these rails.

Build the on-chain equivalents of Stripe, Checkout.com, and Worldpay.Build neobanks that don’t rely on pre-funding tricks.Build cross-border corridors that don’t depend on slow correspondent banks.High-throughput blockchains like Solana offer low-latency, scalable transaction processing suitable for real-time payments. However, enterprise-grade systems require additional guarantees, including predictable transaction inclusion, auditability, and service-level agreements (SLAs).

That’s where Raiku comes in.

Raiku: Enterprise-Grade Certainty on Solana

Raiku enables enterprise-grade certainty for institutions building on Solana. It ensures transactions execute exactly when and how they’re supposed to. It does this by improving how applications interact with Solana through two layers: native and extensions.

The Native Layer

Native applications are Solana programs that live entirely on the network. They use Solana’s existing runtime but face unpredictable inclusion and lack the ability to offer timing guarantees, especially during high-activity events. Raiku fixes that by adding a scheduling and auction layer on top, making Solana’s execution predictable. By allowing validators to promise blockspace ahead of time, Raiku is able to slot transactions into the space made available by the validator without introducing additional delays. Raiku does this in two ways:

1. Just-in-Time (JIT) — “Put me in the very next slot.”Used for urgent, high-priority actions like instant merchant payouts, refund processing, or card settlement events. Winning a JIT auction guarantees inclusion in the next available Solana slot regardless of network congestion. For a payment processing platform, this could be used to support high-value, near-instant transfers in situations where the stakes are high and funds have to arrive immediately.

2. Ahead-of-Time (AOT) — “Put me in this specific future slot.”Used for predictable, time-sensitive flows like scheduled treasury sweeps or batch disbursements. AOT lets processors pre-purchase blockspace for exact timestamps (e.g., 09:00:00 UTC) and guarantees execution at that moment, no matter the network load.

Both paths run through Raiku’s coordination layer, the Ackermann Node and Sidecar, which together route, schedule, and confirm transactions before they hit the Solana validator network.

The workflow usually looks like this:

1. Submit a Transaction Intent Processors send a Raiku intent specifying:

- What the transaction does (e.g., payout, refund, swap)

- When it should execute (JIT or AOT)

- The maximum priority fee bid

- Optional execution conditions

2. Slot Reservation and Pre-ConfirmationThe Ackermann Node schedules the transaction and issues a pre-confirmation, a signed guarantee that the transaction has a reserved slot and locked position. For example, “include merchant payout batch in the next slot” (JIT) or “settle payroll sweep at 18:00 UTC” (AOT).

3. Deterministic ExecutionWhen the slot arrives, the Sidecar, running alongside Solana validators, delivers the transaction bundle directly to the block leader’s TPU (transaction processing unit). This avoids networking delays, gossip bottlenecks, and QUIC throttling, ensuring every payment lands exactly as scheduled.

4. Dynamic Slot AllocationRaiku continuously balances capacity between AOT reservations and JIT walk-ins, preventing either from starving the other. This dynamic allocation keeps both real-time and scheduled transactions reliable, even at high network load.

The Extensions Layer

Extensions are external execution environments built for specific use cases, like high-frequency trading, AI inference, or private settlements. Each one runs independently with its own sequencer and custom logic, but still inherits Solana’s security and finality through Raiku.

These extensions will connect to Solana via the Global Account Model (GAM), a unified state system that lets data and assets move seamlessly between native apps and external ones. Developers can even deploy alternative virtual machines (like EVM or Move) and interact with them atomically across environments.

To see what this looks like in practice, we can examine how Raiku powers real-world use cases such as neobanks, payment processors, and other enterprise-grade financial systems.

Case studies

Raiku’s deterministic execution model can be applied across multiple financial systems, from consumer-facing neobanks to institutional payment processors.

Neobanks: Scheduling Operations

Neobanks started as digital-only banks that gave users slick, app-based experiences without physical branches. Traditional neobanks (like Chime or N26) layered modern UX on top of legacy rails like ACH and SWIFT.

Over the past few years, we’ve seen the rise of crypto neobanks, platforms like Revolut, Tria, Xapo, and UR, that integrate stablecoins and DeFi directly into the banking experience.

But despite this progress, one core issue remains unsolved: deterministic transaction inclusion.

For enterprises, operations like card top-ups, payroll, treasury sweeps, and bulk payouts run on strict schedules governed by liquidity cut-offs, compliance rules, and SLAs. A missed settlement window or delayed sweep can cascade through systems, breaking reconciliation, breaching contracts, and disrupting financial control.

Raiku: Turning Instant UX into Guaranteed Infrastructure

For neobanks, this means every transaction, from user top-ups to payroll disbursements, can be scheduled, guaranteed, and proven ahead of time.

AOT enables neobanks to pre-purchase guaranteed inclusion slots for critical payment windows, typically 35+ slots (~15 seconds) or more ahead.Through Raiku’s siQoS marketplace, they can book blockspace for exact future timestamps, such as 09:00:00 UTC for payroll or 18:00 UTC for treasury rebalancing.

- How it works: Neobanks use the “put me in this specific future slot” model. Validators commit to execute those transactions in that slot, regardless of network congestion, providing 99.9%+ execution reliability.Pricing: Slots are priced through open English-style auctions, enabling efficient price discovery. Institutions that plan ahead often pay less than they would during volatile network conditions.

- Outcome: Every transaction executes with deterministic timing, and Raiku produces cryptographic settlement receipts that prove who executed what, when, and in what order, including optional KYC/AML metadata for compliance.

- Payroll due at 09:00 UTC? Reserve slots 12,345–12,347 a day ahead.

- Treasury sweep at market close? Lock that window precisely, with validator commitment.

- Batch settlements across regions? Execute atomically across slots with deterministic proofs.

How Raiku executes transactions

When the reserved slot arrives, Raiku’s infrastructure ensures the transaction lands exactly where it should.

At the core is the Ackermann Node, which functions as Raiku’s transaction router and scheduler. It:

- Accepts incoming transactions from applications like neobanks,

- Finds the best validator route using real-time network monitoring, and

- Schedules each transaction into a precise future slot.

Once a transaction is matched to a slot, the Ackermann Node sends a pre-confirmation, a cryptographic signal that guarantees inclusion. For example, a neobank running payroll can see this preconf and know with certainty that their batch will execute in the 09:00 UTC slot.

When that slot arrives, the Ackermann Sidecar, a lightweight program that runs next to the validator (compatible with the Agave, Jito and soon Firedancer clients), takes over. It sends the pre-confirmed transaction bundle directly to the TPU of the block leader, bypassing the public mempool entirely. This avoids delays, dropped transactions, and network throttling, ensuring the transaction executes precisely as scheduled.If a validator or Sidecar becomes unavailable, the Ackermann Node automatically reroutes through another node or falls back to standard Solana RPC, maintaining reliability without manual intervention.

With Raiku:

- No more credit floats. Neobanks don’t have to front capital to simulate instant deposits.

- No more reconciliation overhead. Each execution is self-auditing and timestamped.

- No more timing risk. Settlements happen exactly when planned, regardless of network congestion.

- Regulator-grade transparency. Audit trails are native to the ledger, not retrofitted later.

Payment Processors: Real-Time Settlement

Payment processors like Stripe, Checkout.com, and PayPal handle thousands of payments per second, where even small delays can ripple through merchant networks. In traditional systems, settlements are only finalized days later through ACH or card networks, creating uncertainty that must be absorbed through pre-funding, risk buffers, and reconciliation cycles.

Raiku’s Just-in-Time (JIT) transactions eliminate this delay entirely.

How JIT Works

Just-in-Time (JIT) in Raiku is a real-time transaction inclusion system; it ensures that your transaction lands in the very next Solana slot, not “whenever the network can fit it.”

In normal Solana flow, transactions compete for bandwidth and often get delayed or dropped, particularly if the RPC provider is experiencing heavy load. When routed to validators utilizing the Jito client (currently used by ~95% of the network), those transactions are then placed into a mempool, where they may or may not then be selected for processing in the next block. If the transaction isn’t selected in time, it expires and must be resubmitted.

Raiku fixes this by introducing JIT block auctions, allowing builders and applications to bid for immediate inclusion right as the slot begins.The Ackermann Node runs this micro-auction in real time, selects the highest (or earliest valid) bid, and sends the transaction bundle straight to the validator leader’s TPU through the Sidecar, using priority lanes to avoid network bottlenecks and completely bypassing the mempool (if the validator uses one).

Because the auction happens at the slot boundary, pricing reflects live network conditions; whoever values blockspace most in that instant wins inclusion.

This makes JIT ideal for time-critical actions like liquidations, arbitrage, or NFT mints, and for payment processors executing instant merchant payouts or refund settlements, where every second of delay impacts cash flow, accounting credibility and customer trust.

Pricing Model

JIT operates via a first-price sealed-bid auction system:

- Each transaction submits a priority-fee bid in SOL.

- The minimum bid equals the network’s current priority fee plus a 5% premium.

- The highest bids secure inclusion in the next slot, ensuring fast, fair access during congestion.

Conclusion

Raiku’s transaction system combines AOT and JIT execution to cover both scheduled and real-time requirements across all financial applications.

AOT secures blockspace in advance for predictable operations like payroll, treasury rebalancing, or institutional settlements, ensuring they execute in fixed slots at known times.

JIT provides immediate execution for time-sensitive actions such as card payments, instant payouts, or real-time liquidity adjustments, guaranteeing inclusion in the next available block.

Together, they create a unified framework that supports both planned and reactive settlement flows with deterministic inclusion and verifiable ordering.

‍