# Table of Contents - [Introduction | Raiku](#introduction-raiku) - [Validators | Raiku](#validators-raiku) - [Raiku Products | Raiku](#raiku-products-raiku) - [Novel App Architectures | Raiku](#novel-app-architectures-raiku) - [Raiku Use Cases | Raiku](#raiku-use-cases-raiku) - [Our Insights | Raiku](#our-insights-raiku) - [Welcome | Raiku](#welcome-raiku) - [Transaction types | Raiku](#transaction-types-raiku) - [Ackermann v1 | Raiku](#ackermann-v1-raiku) - [Milestones & Roadmap | Raiku](#milestones-roadmap-raiku) - [Builders | Raiku](#builders-raiku) - [FAQ | Raiku](#faq-raiku) - [The Ackermann Validator (vAgave) | Raiku](#the-ackermann-validator-vagave-raiku) - [Quickstart | Raiku](#quickstart-raiku) - [Testnet Participation | Raiku](#testnet-participation-raiku) - [Register | Raiku](#register-raiku) - [The Ackermann Sidecar | Raiku](#the-ackermann-sidecar-raiku) - [Configuration | Raiku](#configuration-raiku) - [Observability | Raiku](#observability-raiku) - [Build and Run | Raiku](#build-and-run-raiku) - [Architecture | Raiku](#architecture-raiku) - [Build and Run | Raiku](#build-and-run-raiku) - [Configuration | Raiku](#configuration-raiku) - [Quickstart | Raiku](#quickstart-raiku) - [Register | Raiku](#register-raiku) - [SDK | Raiku](#sdk-raiku) --- # Introduction | Raiku **Note**: Raiku is a rapidly evolving project. We're making swift progress with regular updates to our core infrastructure services, and our documentation is frequently changing. ### [](#background-and-vision) Background and Vision When we founded Raiku, our vision was simple: blockchain networks will continuously struggle to reach their full potential and serve global use cases until they achieve the following three things: * Reliability and security comparable to traditional systems * Performance that can cater to generalised and app-specific use-cases * Design flexibility that serves existing demand for block space while unlocking new and powerful business models for both the Solana ecosystem and external, optimised applications. Solana has achieved significant success positioning itself as the most performant chain capable of supporting Web2-level applications and user experience. Still, the network has had moments where it still struggles with transaction reliability, speed limitations and extractive MEV. These challenges have damaged the overall user experience. We believe Solana will power much of our future digital activity, from capital markets to next generation data, infrastructure networks and AI-powered businesses. To get there, Raiku solves the fundamental challenges that limit Solana’s potential from achieving our collective vision. ### [](#current-network-challenges) Current Network Challenges Raiku addresses 3 critical issues that Solana faces today: 1. **Unreliable Transactions**: Up to 40% of non-vote transactions on Solana fail, creating a poor experience for users and applications alike. 2. **MEV Exploitation**: Harmful practices like sandwich attacks extract value from users, with up to 50% of MEV coming from private mempools that give unfair advantages to insiders and ruin the fundamental primitives that first-principles blockchain design proposes. 3. **Network Congestion:** As demand grows, applications compete for congested block space, leading to performance issues during high usage periods. ### [](#introducing-raiku-network-solanas-coordination-layer) Introducing Raiku Network: Solana's Coordination Layer Raiku is a coordination layer that enhances Solana’s core by enabling seamless collaboration between applications, operators, and the L1. This unlocks higher performance, greater reliability, and scalable throughput across the network. Built from first principles, Raiku gives developers low-latency execution and broad design freedom—making it easier to build competitive, real-world applications onchain. It introduces new primitives that improve scalability without compromising composability or asset fungibility. By decoupling block-building process, Raiku empowers builders to specialise and offer differentiated features—creating new validator revenue opportunities and enabling richer application experiences. At the same time, transparent transaction ordering enhances fairness and aligns incentives across the network. #### [](#eli5-our-technology-enables) **ELI5: Our Technology Enables:** * Three new transaction types including the ability to submit larger translation data to the network via what we call ‘Proof Streaming’. * Faster, more consistent transaction inclusion rates on the network with significantly increased service reliability * The mitigation of harmful MEV, improving UX for many stakeholders * Atomically connecting all extensions on Solana via our Global Account Module to for settlement ### [](#key-benefits) Key Benefits Some of the key benefits include: For Applications[](#for-applications) Raiku enables exponential improvements to the performance and design freedom on-chain applications have on Solana. * Direct state channels between application/user and validator * Fast and guaranteed transaction inclusion * Guaranteed inclusion windows (Ahead of Time Inclusion Signals) * Protection against external MEV * State composability between native and external applications * Multiple revenue opportunities enabled by Raiku primitives Further, Raiku enables unique application architectures on Solana referred to as external applications (or network extensions), where unlocked capabilities include: * System reliability and performance comparable to traditional systems * Uniform account structure and state management * State atomicity for cross-extension operations * Support for alternative VM instructions * Control over transaction ordering and logic and lowest level * Inherit security properties on Solana For Validators[](#for-validators) By adopting the [ackermann-v1](https://docs.raiku.com/technical-docs/ackermann-v1) validators access native and external order flow, creating new revenue streams increasing validator profits/yield. * Increased transaction order-flow from internal and external sources * Higher revenue through state commitments ahead-of-time * Enhanced stake-weighted economics * Low hardware fingerprint, ensuring optimal performance operations. Further, the Raiku comes with all necessary tooling and dashboard infrastructure enabling a 60 minute onboarding process ([validator installation guide](https://docs.raiku.com/technical-docs/node-operator-guide/quickstart) ). * * * [](#connect-with-us) Connect with Us ----------------------------------------- [NextOur Insights](/overview/our-insights) Last updated 28 days ago Was this helpful? ![Page cover image](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252FezKqfwVSh0QU6C8IZVGA%252F4.png%3Falt%3Dmedia%26token%3Daf38691f-4d7a-4e0a-b50f-bbe2e5be703d&width=1248&dpr=4&quality=100&sign=30221c77&sv=2) We’d love for you to join us on this journey to supercharge Solana. Hop into our , follow us on , and sign up on our for the latest updates. If you’re building, curious, or just want to chat—don’t hesitate to reach out. We’re always excited to connect. [**Discord**](https://discord.com/invite/raikucom) [**X**](https://x.com/raikucom) [**website**](https://www.raiku.com) --- # Validators | Raiku [](#testnet-participation) Testnet Participation ----------------------------------------------------- We're thrilled to open a limited number of seats for node operators (NOs) to participate in Raiku testnet — where we are currently working with a number of core NO partners. Participation of Raiku's testnet is designed for seasoned node-runners whom are operating mainnet and testnet validators on Solana. ### [](#why-join-the-private-testnet) Why Join the Private Testnet? By participating in the private testnet, you'll be at the forefront of a transformative shift in how on-chain systems operate. As a testnet participant, you'll help us validate and refine Raiku's core components, enabling the next generation of decentralised applications on Solana. Here’s what you can expect: * **Test and Enhance:** Engage with Raiku, our distributed global coordination layer, to ensure robust service reliability, low-latency processing, and atomic state management for applications on Solana. * **Shape the Future:** Collaborate with our team to improve core metrics, deploy system patches, and contribute to the overall reliability and performance of the Raiku architecture. * **Exclusive Access:** Be among the first to experience and influence the cutting-edge design of Raiku. ### [](#testnet-timeline) Testnet Timeline Raiku testnet will run in planned cohorts over three quarters of 2025. * `**Q1/Q2-2025**`**:** Initial launch of Raiku v1 testnet. * `**Q2/Q3-2025**`**:** Expansion into Raiku v2. ### [](#installation-process) **Installation Process** The process is streamlined into three main steps: 1. Binary installation and initial configuration. Also, we are providing access to our docker image repository and tools to integrate our infrastructure into node operators'. 2. Network and security setup 3. Integration testing with the validator The sidecar's modular design can be deployed and configured seamlessly with existing validator setups — only one option needs to be added to ensure proper security authentication between the sidecar and validator. This allows for a clean separation of concerns. ### [](#prerequisites) Prerequisites Experienced validator operators can deploy the `Ackermann-sidecar` with ease, typically completing setup and installation in under an hour. This process requires one prerequisite: an operational `Agave` validator node must already be running to serve as the foundation for the sidecar integration. ### [](#how-to-register) How to Register To join our testnet program, please submit your application through the form below: [PreviousMilestones & Roadmap](/milestones-and-roadmap) [NextBuilders](/participate/builders) Last updated 26 days ago Was this helpful? --- # Raiku Products | Raiku Raiku introduces novel infrastructure products that extend Solana’s core functionality, enabling greater flexibility and customisation for builders and validators supporting both native and external use cases. [](#raikus-novel-transaction-types) Raiku's Novel Transaction Types ------------------------------------------------------------------------ Raiku enables novel out-of-protocol transaction types on Solana: 1. **Guaranteed Execution:** Ensures fast and guaranteed transaction inclusion, mitigating transaction failures & MEV for applications. 2. **Ahead-of-Time Inclusion Signals:** Applications receive inclusion signals ahead-of-time (AOT), powered by Raiku's enablement AOT block auctions with atomic and sequential slots. 3. **Proof (Data) Streaming:** External applications can stream larger proofs (typically bundled transactions) to Solana for verification and settlement, powered by Raiku's AOT sequential block space auction. ELI5: Ahead-of-Time (AOT) Block Auctions[](#eli5-ahead-of-time-aot-block-auctions) In Solana, **Ahead-of-Time (AoT) block auctions** involves reserving blockspace in advance. For example, at the beginning of an epoch, slots are reserved for the epoch timeframe, and the auction writes the leader schedule on-chain. Builders then submit transactions to the leader, who signs the block. **Key aspects of AoT block auctions include:** * **Decoupled Block Building**: Similar to JIT (Just-in-Time) auctions, AoT auctions aim to separate block construction from block validation to improve efficiency and specialisation. * **Reduced Latency Sensitivity**: Compared to JIT auctions, AoT auctions are less sensitive to latency. The auction runs two days prior, reducing the real-time pressure. * **Pricing Challenges**: Pricing is more difficult because it requires predicting market conditions and MEV (Maximal Extractable Value) flow two days in advance, which increases the barrier to entry. * **Signing**: Builders submit transactions to the leader who signs the block. There are some questions around how complex it is to reason about this architectural design without the need to gossip out who the signer is. There's also the possibility of validators withholding transactions, making it hard to prove that the Builder actually sent them. ELI5: Proof Streaming[](#eli5-proof-streaming) Proof Streaming is a method used by external applications (extensions) to efficiently prove the correctness of state updates, even when they must work within strict transaction size limits. It does this by enabling off-chain event processing to submit proofs that verify state transitions on the base network. The key challenge it overcomes is the difficulty of fitting large cryptographic proofs into limited transaction spaces while maintaining their correctness and soundness. Different methodological approaches—such as Large Proof Segmentation, Incremental Small Proofs, and Delta State Proof Compression—offer trade-offs in proof size, complexity, and verification efficiency, with Delta State Proof Compression being noted for its efficient balance of minimal state changes and proof simplicity. [](#raiku-core-platform-components) Raiku Core Platform Components ----------------------------------------------------------------------- * `Raiku v2` **— Bandwidth Markets (Slot Marketplace):** Slots are stake-weighted, enabling long-term capacity reservations through the primary slot market. A secondary market reallocates unused slots for efficient resource utilisation. The slot-marketplace, serves as an abstraction layer for market participants powered by AOT auctions. * `Raiku v2` **— Global Accounts**: Enables a unified account interface with seamless execution for state management across native and external applications with support for various VM instructions and account formats. * The Global Account Module is a unified framework for representing and managing accounts across different external environments (extensions) and underlying native account state. * It provides a single, consistent account structure that allows seamless interaction between various layers of the system while maintaining state consistency and security. * This unified model helps overcome the issues of state fragmentation common in traditional systems by ensuring that all account state transitions are atomic, verifiable, and standardized across different execution environments. * `Raiku v2` **— RFQ Liquidity:** An off-chain component that connects native and external apps with capital markets, enabling access to deeper and more efficient liquidity than traditional on-chain AMMs. This allows applications to optimise capital deployment through direct market-maker integration. [PreviousOur Insights](/overview/our-insights) [NextNovel App Architectures](/overview/novel-app-architectures) Last updated 28 days ago Was this helpful? ![Page cover image](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252FezKqfwVSh0QU6C8IZVGA%252F4.png%3Falt%3Dmedia%26token%3Daf38691f-4d7a-4e0a-b50f-bbe2e5be703d&width=1248&dpr=4&quality=100&sign=30221c77&sv=2) --- # Novel App Architectures | Raiku [PreviousRaiku Products](/overview/raiku-products) [NextRaiku Use Cases](/overview/raiku-use-cases) Last updated 28 days ago Was this helpful? Through Raiku, developers can build high-performance applications on Solana—both native and external (extensions)—that benefit from: * The ability to submit significantly larger transactions * Faster and more predictable transaction inclusion * Improved service reliability via foresight into inclusion timing * Expanded revenue streams and the creation of entirely new monetisation models * Control over MEV, including the option to mitigate or capture it * Global accounts with support for alternative VMs such as EVM and Move Applications that adopt the Global Account Module unlock significant improvements in bandwidth and latency, directly enhancing their performance and monetisation potential. Definition: Native & External Applications[](#definition-native-and-external-applications) **Native Applications** Are a set of programs (or smart contracts) that are deployed directly on Solana, where there is no significant “external component” at play. * * * **External Applications (Extensions)** Purpose-built environments optimised for specific use cases that maintain independent execution while inheriting Solana's security through the `ackermann-node`. * **Custom Execution Logic:** Extensions can implement custom event processing logic optimised for specific requirements, from HFT systems requiring microsecond precision to privacy-preserving computation needing specialised implementations. * **Independent Sequencer:** Each extension implements its own sequencer for local transaction ordering/execution while relying on the `ackermann` coordination layer for global inclusion and settlement guarantees. * **State Management:** Extensions manage their internal state through a combination of local state tracking and global state synchronisation via the `Ackermann SDK`. Further, the extensions can adopt the global account module, to enable deployment of alternative VM environments such as EVM — Arbitrum Orbit, and enable atomic composability between each extension environment. * * * [](#external-extension-construction) External (Extension) Construction --------------------------------------------------------------------------- It’s important to note that Raiku does not intend to provide a full RaaS offering. However, during the early phases, we anticipate working closely with select teams to help co-develop, onboard, and validate extension environments. Over time, we expect this functionality to be increasingly supported by the broader ecosystem. We might offer a limited offering on Raiku mainnet in the form of a public good sequencer and execution environment based on market feedback and demand. We will further provide support to EVM developers to deploy on Solana as app-extensions as part of a pilot program with the Arbitrum Foundation. ### [](#light-svm) **Light SVM** Light SVM is a specialised execution environment built on Solana's SVM architecture, optimized specifically for financial operations like transfers and swaps. It leverages Anza's `SVM-API` capabilities while introducing constraints and optimisations for financial use cases. ### [](#optimisations) **Optimisations** The Light SVM achieves superior performance for financial operations through three core optimisations: * **Constrained Instruction Set**: Limiting the instruction set to core functions, Light SVM boosts execution efficiency and proof generation time. It focuses on targeted validations for transfers and swaps, avoiding unnecessary checks that add overhead. This allows for optimised account loading, where assumptions about account structures and access patterns enhance performance. * **Programme Caching**: We implement a programme caching function specifically for supported instructions and user account states derived from our Global Account Model. It manages a limited set of programmes, enabling efficient caching that reduces translation between bytecode and machine code. * * * ### [](#economic-alignment) Economic Alignment Arguably, the most crucial point is that our design creates sustainable economic flows between all network participants. Validators earn additional revenue through extension operations, applications benefit from controlled execution costs, and users access more efficient services providing a significantly better UX. Incentive alignment through additional revenue streams: * Priority fees through siQoS * Slot marketplace participation * Premium transaction protection services * Order flow management opportunities This positive-sum relationship ensures that growth in extension activity strengthens rather than strains the underlying network. ### [](#externalised-event-processing) **Externalised Event Processing** By enabling external applications (extensions), applications gain unprecedented control over their execution and transaction ordering logic. Rather than competing for shared computational resources and bandwidth, each application can optimise its scheduler and execution environment infrastructure for specific requirements. This separation of execution from consensus enables: * Microsecond-precision transaction ordering for sophisticated trading systems * Custom virtual machine implementations for domain-specific computation * Tailored privacy guarantees for regulatory compliance * Efficient state management optimised for specific use cases ### [](#enhanced-network-capabilities) Enhanced Network Capabilities This paradigm shift strengthens—rather than diminishes—the role of Solana’ as a base network. By offloading generic event processing, Raiku frees up native bandwidth, allowing the base layer to focus on high-value, performance-critical execution. * More efficient bandwidth allocation across execution windows * Reduced congestion during slot and block construction * Enhanced validator economics through extension fees (via the slot marketplace) * A symbiotic relationship with the broader Solana ecosystem—Raiku complements, rather than competes with, existing infrastructure * Preservation of the network’s core responsibilities: maintaining economic truth and providing robust security guarantees Each targeted optimisation works with while introducing specific improvements for financial use cases resulting in superior transaction performance while maintaining the security guarantees of the base network. [Anza's underlying SVM-API](https://www.anza.xyz/blog/anzas-new-svm-api) [Arbitrum Orbits](https://arbitrum.io/orbit) [LightSVM](/overview/novel-app-architectures#light-svm) Light SVM is used for program execution, and NE Sequencer is used for transaction handling. The Light SVM manages program loading, fees, and extension-specific operations, while the NE Sequencer handles transaction ingress and state management through the Ackermann SDK. The extension connects to the Ackermann Node State Coordination layer for network synchronisation. ![](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252F9oiYXiUDoC6FAaRda0uQ%252FScreenshot%25202025-03-12%2520at%252013.50.27.png%3Falt%3Dmedia%26token%3D5f2ebd01-b7d8-463f-8cf5-b67fc49d9b73&width=768&dpr=4&quality=100&sign=3d2ab460&sv=2) ![](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252FLuxgfCeJBweek6fs43Ve%252FScreenshot%25202025-03-12%2520at%252013.51.11.png%3Falt%3Dmedia%26token%3Df5eb89c2-ea89-40c3-9bfd-14d4a4779d2a&width=768&dpr=4&quality=100&sign=6c22155f&sv=2) ![Page cover image](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252FezKqfwVSh0QU6C8IZVGA%252F4.png%3Falt%3Dmedia%26token%3Daf38691f-4d7a-4e0a-b50f-bbe2e5be703d&width=1248&dpr=4&quality=100&sign=30221c77&sv=2) --- # Raiku Use Cases | Raiku [PreviousNovel App Architectures](/overview/novel-app-architectures) [NextMilestones & Roadmap](/milestones-and-roadmap) Last updated 28 days ago Was this helpful? unlocks a new class of applications on Solana—designed for builders seeking institutional-grade performance, reliability, and control. Below are example use cases, spanning both near-term opportunities and longer-term possibilities across key verticals. If you're building in any of these areas, we’d love to hear from you—our team is here to support you every step of the way. Please join our . Finance (General)[](#finance-general) Raiku’s precise and reliable settlement creates new opportunities for institutional-grade financial applications, enabling the future of finance through secure, high-performance, and efficient operations. **Example use cases include:** * **HFT Trading:** Execute thousands of cross-exchange trades per second with microsecond precision and guaranteed settlement timing. This is ideal for quantitative trading firms and high-frequency trading bots—which typically face much higher transaction reversion rates—where deterministic settlement is critical. (_Note: Ordinary token transfers for typical users usually complete quickly, with failure rates between 1.4% and 5% for 1–5 transactions per day._) * **Cross-Collateralised (and soon, Cross-Ecosystem) Lending Pools:** Enable precise liquidation mechanisms and secure multi-asset collateralisation. * **Hybrid CEX/DEX Exchanges with Superior UX:** Seamlessly bridge centralised exchange liquidity with Solana DeFi while maintaining regulatory compliance, and provide KYC-gated access to decentralised markets for institutional clients. * **Automated Risk Management:** Monitor positions and execute liquidations with microsecond precision. Dedicated validator channels ensure near-instant execution when market conditions change, minimising protocol risk. * **Institutional Settlement Networks:** Establish private settlement channels between major financial institutions with deterministic finality and encrypted transaction flows. This supports instant cross-border settlements while upholding regulatory compliance and transaction privacy. * **Synchronized Options Markets:** Coordinate complex options strategies across multiple venues with guaranteed execution timing. This solution is targeted at market makers managing large derivatives portfolios who require precise, coordinated execution across various strikes and expirations. * **Payment Infrastructure:** Build a lightning-fast settlement network with zero payment failures, guaranteed transaction inclusion, and mitigated MEV impact—even during periods of peak network congestion—by leveraging features such as ahead-of-time block auctions and bandwidth reservation. AI & Machine Learning[](#ai-and-machine-learning) Raiku’s deterministic settlement and guaranteed bandwidth reservation unlock new possibilities for AI systems and frameworks that require precise timing, secure execution, and efficient resource allocation. **Example use cases include:** * **Enterprise AI Model Marketplace:** Create, deploy, and monetise complex AI models and workflows using features offered through Raiku, such as deterministic microsecond inference timing and encrypted execution environments. These enable secure model sharing while protecting intellectual property. * **Federated AI Training Infrastructure:** Coordinate encrypted, large-scale, and verifiable AI training with guaranteed bandwidth and direct validator connections for parallel processing and efficient state proofs. Raiku’s precise timing and privacy-preserving functionality allow enterprises to collaborate while maintaining data sovereignty. * **AI Trading Strategies:** Execute ML-driven trading strategies with deterministic settlement and front-running protection, optimised for high-frequency, low-latency environments. * **Real-Time AI Orchestration Network:** Synchronise multi-model AI workflows with microsecond-level execution precision and atomic state updates across distributed systems—ideal for inferencing pipelines requiring tightly coordinated model responses. DePIN[](#depin) Raiku provides the foundational infrastructure for decentralised physical networks (DePIN) to operate with guaranteed resource allocation, deterministic settlement, and real-time coordination across distributed hardware systems. **Example use cases include:** * **Decentralised Power Grids:** Enable microsecond-level energy trading between distributed power sources, with deterministic settlement to support real-time demand response. Ideal for coordinating renewable energy networks with precise supply–demand matching. * **Smart City Infrastructure & Sensor Networks:** Orchestrate large-scale sensor networks and city infrastructure with guaranteed bandwidth to validators. Supports real-time coordination of traffic systems, utilities, and public services—backed by verifiable state updates. * **Telecom Bandwidth Markets:** Build efficient decentralised markets for cellular and Wi-Fi bandwidth, allowing ISPs and local providers to reserve and trade capacity with microsecond-level settlement. Supports dynamic pricing and real-time allocation based on demand. * **Decentralised Edge Computing Coordination:** Manage distributed edge computing nodes with precise timing and guaranteed resource availability. Designed for IoT networks requiring predictable latency, local processing, and verifiable execution. Gaming & Interactive Systems[](#gaming-and-interactive-systems) Raiku powers next-generation blockchain gaming through atomic state updates and deterministic execution windows—enabling responsive multiplayer gameplay, cross-game asset networks, and complex in-game economies that elevate the user experience beyond traditional gaming infrastructure. **Example use cases include:** * **Millisecond-Synchronised Multiplayer Functionality:** Support large-scale multiplayer games with guaranteed transaction timing and reserved bandwidth channels. Ideal for competitive e-sports, physics-reliant environments, and real-time battle royales requiring seamless coordination across thousands of players. * **Cross-Game Asset Networks:** Build interoperable infrastructure for moving digital assets between game environments with deterministic settlement. Raiku enables unified asset management, ownership verification, and privacy via ZK proofs. * **On-Demand Gaming Infrastructure:** Deploy scalable compute environments with predictable execution windows and guaranteed resource availability. Game studios can instantly scale server performance during peak load, supporting complex economies and institutional-grade liquidity without performance degradation. General Consumer Applications[](#general-consumer-applications) Raiku transforms everyday consumer applications by enabling guaranteed transaction timing and instant settlement. This unlocks entirely new business models for content streaming, social platforms, and loyalty programmes—use cases that were previously impractical on blockchain. **Example use cases include:** * **Decentralised Content Subscription Services:** Build Netflix-style streaming platforms where creators deliver content directly to consumers with guaranteed delivery timing and bandwidth. Viewers pay per second via instant micropayments, while creators receive earnings in real time. * **Premium Social Networks:** Create privacy-centric social platforms with guaranteed message delivery and structured content feeds. Users retain control over their data and can monetise attention through transparent, instant-settlement micropayment systems. * **Consumer Loyalty Programmes:** Develop cross-merchant loyalty networks with instant settlement of points and rewards. Enable real-time redemption across multiple businesses—even during peak network congestion—with guaranteed transaction confirmation. [Raiku’s infrastructure](/overview/raiku-products) [Discord](https://discord.com/invite/raikucom) ![Page cover image](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252FezKqfwVSh0QU6C8IZVGA%252F4.png%3Falt%3Dmedia%26token%3Daf38691f-4d7a-4e0a-b50f-bbe2e5be703d&width=1248&dpr=4&quality=100&sign=30221c77&sv=2) --- # Our Insights | Raiku [](#introductory-reading) Introductory Reading --------------------------------------------------- We identified three critical patterns that shape our solution design by analysing network architecture principles and builder needs. 1\. Bandwidth & Inclusion Reliability[](#id-1.-bandwidth-and-inclusion-reliability) Drawing from fundamental principles of execution guarantees and resource management in distributed systems, we recognise that applications require service reliability (deterministic transaction foresight) and predictable state access. Any unreliability of transaction status will be gamed by actors. * **Predictable Inclusion**: Applications must have guaranteed transaction inclusion within defined time windows, eliminating uncertainty in state transitions * **State Determinism**: All operations across execution environments must produce consistent, deterministic results regardless of network conditions * **Resource Availability:** Critical operations require guaranteed access to network resources, preventing performance degradation during high-demand * **Failure Isolation:** System design must ensure issues in one execution environment don't cascade into others, maintaining overall system reliability 2\. Central Event Operations[](#id-2.-central-event-operations) We recognise the value of maintaining clear architectural boundaries between execution environments and network consensus, as well as the performance gains achieved when applications are able to implement specialised execution logic. Providing applications with greater flexibility for specific use cases results in more efficient, optimised performance. * **Execution/Consensus Separation:** Applications benefit from specialised execution environments distinct from base network consensus, enabling optimised performance for specific use cases while maintaining security guarantees * **Global State Access:** By leveraging the base network as the authoritative source of truth for global state and allowing for flexible execution models, applications can achieve high degrees of performance and consistency. * **Optimised Resource Usage:** Each execution environment can be precisely tuned to its specific requirements—from high-frequency trading to complex gaming logic—while inheriting the security guarantees of the base network. * **Execution Sovereignty:** Applications maintain complete control over their implementation details and execution logic while preserving seamless interoperability with the base network 3\. Global Accounts & State Representation[](#id-3.-global-accounts-and-state-representation) Inspired by the points above, we incorporate a unified account structure that fundamentally changes how network extensions interact with the state: * **Universal State Representation:** A single, consistent account model across all extension environments. * **Composable Account Operations:** Native support for atomic multi-extension account interactions. * **Efficient State Proofs:** Streamlined verification of account state across different execution environments. * * * [](#block-building-evolution) Block Building Evolution ----------------------------------------------------------- As previously mentioned, we believe decoupled block-building systems have proven to be a valuable concept, even with structural improvement on incentive mechanism design, the case for external systems arguably strengthens. Some of the indicative proofs can be found below: * Ecosystem applications require deterministic execution and MEV mitigation * External systems (extensions) facing limitations posed by the underlying network * Validators earning significantly higher block-rewards where Jito historically accounts for 3x the block reward, although only taking 10% (5M to 6M CUs) per block. Block building on Solana is evolving with Raiku’s Ahead-of-Time block auctions. This model allows block builders to offer differentiated features—such as exclusive block space access, custom fee markets, MEV protection (e.g. sandwiching), and transaction pre-confirmations. These capabilities unlock new use cases and strengthen the network’s structural integrity. Basics on Solana Block Building Challenges[](#basics-on-solana-block-building-challenges) Solana builds blocks continuously, enabling low block times. Unlike Ethereum—where each block is constructed and submitted atomically—Solana’s blocks are streamed as a sequence over time. Each block consists of packets called _shreds_ (maximum payload: 1,280 bytes), which are propagated via UDP using Turbine as the network assembles the block in real time. While this streaming approach supports fast block times, it limits a validator’s ability to optimise block construction. Builders have only a partial view of the mempool, which reduces potential block rewards. This tradeoff, combined with issues like transaction reliability and MEV, has pushed both application developers and validators toward _out-of-protocol_ or _decoupled block-building_ strategies. Basics on JIT & AOT Block Space Auction Models[](#basics-on-jit-and-aot-block-space-auction-models) **Just-in-Time (JIT) Block Auctions:** One potential model for block building involves JIT auctions, where builders submit bids at the time of the slot. In this model: * Builders submit bids to an auctioneer, who then selects the highest bid for submission to the leader. * This approach allows for more accurate pricing as it is based on the current state of the network. * However, it also introduces trust assumptions, as the auctioneer must not leak data or manipulate the process. * There are still open research questions about how to handle private order flow and prevent malicious behaviour. **Ahead-of-Time (AOT) Block Auctions:** AOT block auctions is where slots are bought in advance, possibly at the beginning of an epoch. This model involves: * Builders bidding for slots at the beginning of an epoch. * The auction results are written on-chain, determining the leader schedule. * Builders potentially signing transactions, which would require validators to gossip out key pairs to the network. * This model has lower latency requirements compared to JIT auctions but may be harder to price because it requires predicting market conditions in advance, and may increase the barrier to entry for smaller builders. Tradeoffs on Decoupled Block Building[](#tradeoffs-on-decoupled-block-building) #### [](#pros) **Pros** * **Rapid Iteration on Protocol Design** Easier to experiment with and deploy new auction designs or fee market mechanisms when updates are confined to a single builder node, rather than requiring coordinated upgrades across a wide validator set. * **Specialisation Drives Revenue** Enabling block builders to offer different feature sets allows for specialisation according to market demand which can lead to higher revenue potential. * **Feature Differentiation** Builders can introduce and compete on specialised features, such as pre-confirmations or latency guarantees * **Dedicated Block Space for Critical Apps** Enables priority or exclusive access to block space for certain applications (e.g., oracle updates), improving reliability and reducing latency for time-sensitive operations. * * * #### [](#cons) **Cons** * **Increased Architectural Complexity** Introducing separate builder roles adds layers to the protocol architecture, increasing the surface area for bugs and requiring more sophisticated coordination logic. * **Expanded Trust Assumptions** Delegating block construction to third-party builders introduces new trust dynamics, especially if builder selection is opaque or centralised. * **Censorship Risk** Builders may prioritise profit over neutrality, increasing the risk of transaction censorship—particularly for transactions with low fees or regulatory concerns. * * * ### [](#system-reliability-and-mev) System Reliability & MEV A significant proportion of Solana's transaction volume stems from spam related to MEV extraction. Analysis of the ratio between reverted and successful transactions reveals patterns that indicate MEV bots competing for arbitrage opportunities. * Addresses performing 1–5 daily transactions (predominantly retail users) experience a revert rate of 1.4%, which increases to 4.6% for those with 6–50 daily transactions. * Notably, addresses conducting over 10,000 daily transactions see revert rates soar to 66.7%. * Furthermore, high-activity addresses with over 100,000 daily transactions (bots) are responsible for 95.2% of all reverted transactions. By adopting Raiku’s design principles, we can ensure execution and inclusion guarantees, where transactions are filtered (pre-screened) before landing on the network (validators) mitigating network spam. Transaction senders will also bypass MEV sandwiching attacks by using Raiku. **Network Spam & MEV Structural Issues** (Further Reader)[](#network-spam-and-mev-structural-issues-further-reader) * Jito's internal analysis reveals a growing number of sandwich attacks occurring outside of Jito's auction mechanism, indicating the presence of additional block engines or modified validator clients engaging in sandwiching activities. * Transactions on Solana are primarily ordered based on when they reach the leader (scheduler). However, the parallelized scheduler introduces network jitter, which can impact ordering. As a result, senders often spam transactions to increase the chances of fast inclusion—especially when timing is critical. This behavior creates unnecessary load on the network and degrades overall performance. [PreviousIntroduction](/) [NextRaiku Products](/overview/raiku-products) Last updated 28 days ago Was this helpful? reveals varying revert rates across various activity levels: Between January and February 2025, the overall revert rate for all non-vote transactions was between ~35 to 40% (), which indicates that a large portion of the network’s computing resources are consumed by processing failed arbitrages. Network centralisation issues of stake-weight (swQoS), leading to private mempools and sandwich attacks. Much of Solana's sandwiching attacks, of up 50% () originates from a private mempool operated by a single entity. Other market actors are using durable nonces to increase transaction landing rates at a faster time than the average transaction by having off-chain private blind auctions — leading to network spam, as transactions are retried over and over by increment, until it’s accepted () [A cohort analysis from Blockworks Research](https://solana.blockworksresearch.com/?dashboard=sol-onchain-activity¤cy=USD&interval=weekly) [source](https://solana.blockworksresearch.com/?dashboard=sol-onchain-activity¤cy=USD&interval=weekly) [source](https://www.helius.dev/blog/solana-mev-report#case-study-vpe-sandwich-program) [source](https://x.com/trentdotsol/status/1863716515209682976?s=46) ![Page cover image](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252FezKqfwVSh0QU6C8IZVGA%252F4.png%3Falt%3Dmedia%26token%3Daf38691f-4d7a-4e0a-b50f-bbe2e5be703d&width=1248&dpr=4&quality=100&sign=30221c77&sv=2) --- # Welcome | Raiku [NextAckermann v1](/technical-docs/ackermann-v1) Last updated 1 month ago Was this helpful? [](#introduction) Introduction ----------------------------------- Welcome to the Raiku Documentation and its first version of its infrastructure called Ackermann. This documentation highlights what's `Ackermann v1` for builders and provides a comprehensive guide for NOs (Node Operators) and users. Ackermann is our technical solution (also referred as the Ackermann infrastructure) that allows external systems who want to settle on Solana to be fast, scalable and guarantees them better inclusion as well as extending the features of the L1 itself. Ackermann is in active development and is not yet ready for mainnet use. We'll be opening **Q1 2024** a private beta on _**testnet**_, which will closely be followed by a **Q3-Q4 2025** _**mainnet**_ release. This documentation reflects Raiku's current implementation and architecture. As we continuously enhance our protocol and incorporate new features, this documentation is regularly updated. Please ensure you're viewing the latest version of this documentation by checking the last updated timestamp or version number at the bottom of each page. Below the different sections where you can jump right in depending on your need. [](#jump-right-in) Jump right in ------------------------------------- [](/technical-docs/node-operator-guide/quickstart) [](https://github.com/solforge-labs/ackermann/blob/main/docs/public/devnet/broken-reference/README.md) **Concepts documentation** Learn the concepts and use cases that Raiku solves **Technical documentation** Learn more about the technicals behind our our infrastructure **Node Operator Guide** Learn how to run and operate a node **User Guide** Learn how to use our node to send us transactions [Ackermann v1](/technical-docs/ackermann-v1) [Quickstart](/technical-docs/node-operator-guide/quickstart) [Quickstart](/technical-docs/developer-guide/quickstart) [Raiku](https://docs.raiku.com/) ![Page cover image](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F840502766-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fjye3DdeTodH7AQyCju8t%252Fuploads%252F4PQ6UayjdgztGOCwnRVH%252FImage%25204%2520from%2520Gitbook.png%3Falt%3Dmedia%26token%3D20449e70-795c-4ff2-9415-5957875000b3&width=1248&dpr=4&quality=100&sign=b99b6fb1&sv=2) --- # Transaction types | Raiku Raiku enables novel application architectures which gives the developers and builders the freedom to choose which types of transaction they want to use depending on their use cases and their needs. _**sendTransaction**_[](#sendtransaction) The Solana base transaction type is leveraging swQoS mechanism inherited from the network, in a way that we do not centralise all the tx's solely going through the validators with the highest amount of stakes but still allow the same guarantees than the base network. _**sendInclusionTransaction**_[](#sendinclusiontransaction) A Raiku transaction type which leverages our own siQoS mechanism, in a way that allows the users to get the first slot avaiable for very fast inclusion (around 1s) with a precommitement of < 50ms. _**sendSlotInclusionTransaction**_[](#sendslotinclusiontransaction) A Raiku transaction type which once again leverages our own siQoS mechanism, in a way that allows the users to plan ahead of time regarding when they want their transactions to be included - up to 60s at a said slot with a precommitement of < 50ms. _**sendCrossChainTransaction**_[](#sendcrosschaintransaction) Another raiku transaction type which allows the user to leverage either one of the transaction types describe in the above (_**sendTransaction, sendInclusionTransaction, sendSlotInclusionTransaction)**_ in order to execute cross-chain swaps. All our transaction types exclusively accept Solana's _**finalized commitment level**_, ensuring the best possible transaction landing rate. Additionally, these transactions leverage a decentralized, geographically optimized transaction coordinator (with nodes in London, New York, and Singapore), which enhances the resilience and robustness of our transaction types while mitigating the centralization trends currently observed in the network. Through our node-sidecar connections with network validators, we can secure the optimal transaction lane based on network traffic and other relevant factors. [PreviousArchitecture](/technical-docs/ackermann-v1/architecture) [NextTestnet Participation](/technical-docs/testnet-participation) Last updated 1 month ago Was this helpful? --- # Ackermann v1 | Raiku [PreviousWelcome](/technical-docs) [NextArchitecture](/technical-docs/ackermann-v1/architecture) Last updated 1 month ago Was this helpful? The Raiku protocol consists of multiple interconnected components that work together to create a robust and decentralized network. If you are more interested in the technicals by contributing, you can refer to the of this guide. If you're interested in running a Raiku Solana validator node and helping maintain the network, please refer to our separate . If you're interested in having an improved experience using the Solana network, please refer to our separate . [Developer section](https://github.com/solforge-labs/ackermann/blob/main/docs/public/devnet/ackermann-v1/broken-reference/README.md) [Node Operator Guide](https://github.com/solforge-labs/ackermann/blob/main/docs/public/devnet/ackermann-v1/broken-reference/README.md) [User Guide](https://github.com/solforge-labs/ackermann/blob/main/docs/public/devnet/ackermann-v1/broken-reference/README.md) --- # Milestones & Roadmap | Raiku [PreviousRaiku Use Cases](/overview/raiku-use-cases) [NextValidators](/participate/validators) Last updated 28 days ago Was this helpful? Raiku began development in July 2024 with a clear goal: to bring deterministic execution, guaranteed inclusion, and scalable coordination infrastructure to the Solana ecosystem. Since then, we've made significant progress across both technical development and ecosystem traction. [](#progress-to-date) Progress to Date ------------------------------------------- 1 ### [](#devnet-deployment) Devnet Deployment We deployed `Raiku v1`including our modified validator (sidecar) and the ackermann-node coordination network on Devnet. It has been running continuously and incident-free since launch, validating our implementation model for **Ahead-of-Time (AOT) block auctions**, **inclusion signals**, and **fast transaction inclusion**. * **Timeframe:** Q2, Q3 & Q4 2024 * **Version:** `Raiku v1` 2 ### [](#core-validator-partners) Core Validator Partners Despite being early-stage, Raiku has already gained strong support from leading validator partners including **Kiln**, **Figment**, **Chorus One**, **Everstake**, and others actively participating in our test phases. * **Timeframe:** Q4 2024 & Q1 2025 * **Version:** `Raiku v1` 3 ### [](#ecosystem-engagement) Ecosystem Engagement Beyond infrastructure, there is **growing demand from both Solana-native applications and extensions** (purpose-built environments) exploring Raiku to power novel execution logic, bandwidth reservation, and MEV-resilient designs. Infrastructure and interoperability providers have also begun exploring integration with Raiku’s primitives to unlock next-gen use cases on Solana mainnet. * **Timeframe:** 2025 * **Version:** `Raiku v1` * * * [](#road-to-mainnet) Road to Mainnet ----------------------------------------- 1 ### [](#private-testnet) Private Testnet Currently live with a curated set of core validator partners. This stage is focused on validating stability, performance benchmarks, and operational workflows in a semi-controlled environment. * **Timeframe:** Q1 2025 * **Version:** `Raiku v1` 2 ### [](#public-testnet) Public Testnet Raiku v2 will introduce extended functionality, including: 1. The **Global Account Module** for unified state management across native and external applications 2. **RFQ Liquidity Infrastructure** 3. Expanded Ahead-of-Time coordination and slot marketplace features This public testnet phase will act as the bridge between our private validator testing and full-scale mainnet deployment—offering broader access to builders and protocol integrators. * **Timeframe:** Q2 & Q3 2025 * **Version:** `Raiku v2` 3 ### [](#mainnet-launch) Mainnet Launch The launch of Raiku v2 on mainnet will bring production-ready infrastructure to support high-performance applications, enabling the next generation of scalable, composable, and deterministic systems on Solana. * **Timeframe:** Q2 & Q3 2025 * **Version:** `Raiku v2` 4 ### [](#beyond-mainnet-launch) Beyond Mainnet Launch As mainnet has launched, we’re not just refining—we’re expanding. Expect a steady stream of new capabilities, including advanced developer tooling, real-time metrics dashboards, and full SDK support to streamline onboarding for builders and infrastructure providers alike. But this is just the beginning. We're laying the groundwork for something much bigger—stay tuned. * **Timeframe:** Q1 2026 * **Version:** `Raiku v3` * * * ![Page cover image](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252FezKqfwVSh0QU6C8IZVGA%252F4.png%3Falt%3Dmedia%26token%3Daf38691f-4d7a-4e0a-b50f-bbe2e5be703d&width=1248&dpr=4&quality=100&sign=30221c77&sv=2) We’d love for you to join us on this journey to supercharge Solana. Hop into our , follow us on , and sign up on our for the latest updates. If you’re building, curious, or just want to chat—don’t hesitate to reach out. We’re always excited to connect. [**Discord**](https://discord.com/invite/raikucom) [**X**](https://x.com/raikucom) [**website**](https://www.raiku.com) --- # Builders | Raiku [PreviousValidators](/participate/validators) Last updated 27 days ago Was this helpful? [](#developer-documentation) Developer Documentation --------------------------------------------------------- **Documentation Under Construction** We are currently working on developer documentation which will be released during public testnet. In the meantime, we'd love for you to join our and sign up on our website for updates. As always, please do reach out to the team to learn more! [](#raikumai-builders-program) Raikumai — Builders Program --------------------------------------------------------------- **Raikumai** is Raiku’s builder programme for early-stage startups and developers building high-performance, onchain applications. It’s designed for teams who move fast, think big, and want to push the boundaries of what’s possible on Solana—with support from the engineers behind Raiku. Each cohort is limited to **8 startups** to ensure deep collaboration, focused support, and strong collective momentum. * * * ### [](#the-raikumai-stack) The Raikumai Stack **Engineering Support** * Work directly with Raiku’s core engineering team. * Get hands-on support for architecture design, protocol integration, and performance optimisation. * Early access to new features, technical documentation, and SDKs. * Tight feedback loops with the people building the infrastructure you're building on. **Growth & Distribution** * Tap into Raiku’s growing network of validators, protocols, and infrastructure partners. * Co-marketing opportunities and community exposure as part of the Raiku ecosystem. * Introductions to other key players across Solana and beyond for technical and distribution partnerships. **Fundraising & Investor Network** * Access warm intros to a vetted network of investors who understand high-performance onchain systems. * Support in refining your pitch, traction narrative, and roadmap. * Optional participation in demo days or investor showcase events with aligned capital partners. **Community & Collaboration** * Join a high-calibre cohort of builders solving similar technical and product challenges. * Contribute to and benefit from the **Builders Pool**—a shared equity/token structure that aligns incentives and encourages long-term collaboration. * Share lessons, blockers, and breakthroughs in real-time through private channels and syncs. * * * ### [](#join-the-program) Join the program If you are interested in joining **Raikumai**, we want to hear from you. We respond promptly and are always here to support great builders—just note that we can only accept **8 startups per cohort** to maintain quality and focus. and open a ticket to apply for Raikumai. Introduce yourself, share what you’re building, and a member of the team will get in touch. [Discord](https://discord.com/invite/raikucom) [**Join our Discord**](https://discord.com/invite/raikucom) ![Page cover image](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F2132699174-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FL2eei6Nkih5ljxLZw2IP%252Fuploads%252FezKqfwVSh0QU6C8IZVGA%252F4.png%3Falt%3Dmedia%26token%3Daf38691f-4d7a-4e0a-b50f-bbe2e5be703d&width=1248&dpr=4&quality=100&sign=30221c77&sv=2) --- # FAQ | Raiku [PreviousObservability](/technical-docs/node-operator-guide/running-a-sidecar/observability) [NextQuickstart](/technical-docs/developer-guide/quickstart) Was this helpful? --- # The Ackermann Validator (vAgave) | Raiku [PreviousRegister](/technical-docs/node-operator-guide/quickstart-1) [NextBuild and Run](/technical-docs/node-operator-guide/running-a-validator/build-and-run) Last updated 1 month ago Was this helpful? Running our modified version of the Solana validator node doesn't differ much from the . It should be fairly easy for experienced NOs to run one of our modified version of a Solana validator nodes and sidecar starting with the . [official Solana Documentation](https://docs.solanalabs.com/operations/guides/validator-start) [Building section](/technical-docs/node-operator-guide/running-a-validator/build-and-run) --- # Quickstart | Raiku [PreviousTestnet Participation](/technical-docs/testnet-participation) [NextRegister](/technical-docs/node-operator-guide/quickstart-1) Last updated 1 month ago Was this helpful? Node Operators (NOs) maintain the network's health by providing hardware infrastructure and running our modified version of the Solana validator node alongside our sidecar component. Or If you're interested in having an improved experience using the Solana network, please refer to our separate . As a NO who wants to use our Ackermann infrastructure, you need to available in the next section of this guide. [User Guide](https://github.com/solforge-labs/ackermann/blob/main/docs/public/devnet/node-operator-guide/broken-reference/README.md) [complete the protocol registration process](/technical-docs/node-operator-guide/quickstart-1) --- # Testnet Participation | Raiku [PreviousTransaction types](/technical-docs/ackermann-v1/components-communication) [NextQuickstart](/technical-docs/node-operator-guide/quickstart) Last updated 1 month ago Was this helpful? For NOs who want to run our infrastructure on testnet For Builders who want a better Solana experience building applications --- # Register | Raiku [PreviousQuickstart](/technical-docs/node-operator-guide/quickstart) [NextThe Ackermann Validator (vAgave)](/technical-docs/node-operator-guide/running-a-validator) Last updated 1 month ago Was this helpful? To join our Testnet program, please submit your application through . Once our team confirms your acceptance, you may proceed to the next section of this guide which is dedicated to . [this form](https://forms.raiku.com/t/nzvVsuFLz2us) [setting up one of our supported Ackermann Validator Nodes](/technical-docs/node-operator-guide/running-a-validator) --- # The Ackermann Sidecar | Raiku [PreviousConfiguration](/technical-docs/node-operator-guide/running-a-validator/configuration) [NextBuild and Run](/technical-docs/node-operator-guide/running-a-sidecar/build-and-run) Last updated 2 months ago Was this helpful? Once running one of our modified version of the Solana validator nodes, you need to set up the sidecar which acts as a bridge between the Ackermann node and the . [Ackerman validator](/technical-docs/node-operator-guide/running-a-validator) --- # Configuration | Raiku [PreviousBuild and Run](/technical-docs/node-operator-guide/running-a-validator/build-and-run) [NextThe Ackermann Sidecar](/technical-docs/node-operator-guide/running-a-sidecar) Last updated 1 month ago Was this helpful? The process of running our the Ackermann validator is mostly identical to the official Solana . First, follow the to set up your validator base configuration. Once completed, proceed with the Raiku-specific validator node configuration. [](#configure-an-ackermann-validator) Configure an Ackermann validator --------------------------------------------------------------------------- Before jumping in, please be aware that all the resources are available in . We are providing you with the binaries, the docker images and the Flux HelmRelease as well as the monitoring dashboards. In this section, we'll focus on the Ackermann validator CLI parameters that extend the Agave validator node. ### [](#ackermann-validator-specific-cli-parameters) **Ackermann validator-specific CLI Parameters** `--privileged-api-keys`: This parameter allows the sidecar to use the RPC that provides the configuration of the stake weighted map declaration of the validator. This allows us to more efficiently dispatch transactions across the network for a faster and more reliable inclusion. Add to your configuration the following parameter: Copy --privileged-api-keys= If this key is not provided, the sidecar will not be able to retrieve the information that is needed to create the bridge between the Ackermann validator and the Ackermann node. You are now all set and your validator should be running. Once you have verified that everything is up and running, you can continue with . [documentation](https://docs.solanalabs.com/operations/guides/validator-start) [official documentation](https://docs.solanalabs.com/operations/guides/validator-start) [this repository](http://github.com/raiku-protocol/ackermann-ext-resources) [setting up the Ackermann sidecar](/technical-docs/node-operator-guide/running-a-sidecar) --- # Observability | Raiku [PreviousConfiguration](/technical-docs/node-operator-guide/running-a-sidecar/configuration) [NextFAQ](/technical-docs/node-operator-guide/running-a-sidecar/faq) Last updated 1 month ago Was this helpful? We provide comprehensive observability for our components through Prometheus metrics exposed at `sidecar:33333`. Configure your Prometheus scraper to monitor this endpoint internally. To help visualize these metrics, we are providing you with Kibana dashboards that will help understand what's happening in your infrastructure, including: * Pod-specific metrics with historical data tracking * Rate analysis per pod over time * Stream monitoring for both stderr and stdout * Real-time log viewing with detailed thread information * etc The dashboard includes an interactive log viewer showing detailed sidecar operations, task execution, and configuration parameters. This enables you to monitor your node's health, performance, and operational status in real-time. The metrics are refreshed at regular intervals, providing up-to-date insights into your node's operation. We are using those dashboards and we are more happy to receive your feedbacks and improve on what the community needs. The dashboards are available at . [https://github.com/raiku-protocol/ackermann](https://github.com/raiku-protocol/ackermann) Sidecar log dashboard Sidecar Metrics dashboard ![](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F840502766-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fjye3DdeTodH7AQyCju8t%252Fuploads%252FDTfTVcStBN1w67w1fBph%252FScreenshot%25202025-03-21%2520at%252015.24.33.png%3Falt%3Dmedia%26token%3Da84cb698-c5da-4ed8-bf60-31c1d67ac570&width=768&dpr=4&quality=100&sign=313e9fe0&sv=2) ![](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F840502766-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fjye3DdeTodH7AQyCju8t%252Fuploads%252F1vcHXyGKVGSluYgo5mKF%252FScreenshot%25202025-03-21%2520at%252015.25.46.png%3Falt%3Dmedia%26token%3D786f7509-575f-49f5-9131-71260ae451fb&width=768&dpr=4&quality=100&sign=307053e7&sv=2) --- # Build and Run | Raiku [PreviousThe Ackermann Validator (vAgave)](/technical-docs/node-operator-guide/running-a-validator) [NextConfiguration](/technical-docs/node-operator-guide/running-a-validator/configuration) Last updated 1 month ago Was this helpful? The Ackermann infrastructure relies on common validator implementations, with some modifications to allow faster execution and transaction inclusion. Our approach enhances the performance of validators while maintaining compatibility with the Solana network and ecosystem. The Ackermann validator runs alongside its as the latter creates a bridge between the Ackermann node and the Ackermann validator. New protected endpoints are exposed by the Ackermann validator in order to be able to schedule the transactions across our fleet of Ackermann validators. As a result, you cannot use a regular Agave validator node but one of our modified validator nodes. We only support a modified version of the Agave client at the moment [](#the-ackermann-validator) The Ackermann validator --------------------------------------------------------- The Agave client is an implementation developed by the . Raiku maintains a fork of this client with performance enhancements and expose a new QoS service called slot-inclusion QoS (siQoS). The Ackermann validator is available at and will soon be opened to the public. ### [](#building-from-source) **Building from Source** To build the Ackermann fork from source: 1. Clone the repository: Copy git clone https://github.com/raiku-protocol/agave.git cd agave 2. Build the client: Copy cargo build ### [](#using-prebuilt-binary) **Using Prebuilt Binary** ### [](#using-our-official-docker-image) **Using our official docker image** For those who prefer to run a validator in a docker container, you can find the images in our GCP artifact repository, here: * `europe-west3-docker.pkg.dev/raiku-mainnet/ackermann/external/ackermann-agave` For those who prefer not to build from source, you can go to and use one of our prebuild binaries. You need to use the authentication file that has been shared with you following the by the Raiku team in order to be able to download our docker images [sidecar](/technical-docs/node-operator-guide/running-a-sidecar) [Anza team](http://anza.xyz) [https://github.com/raiku-protocol/agave](https://github.com/raiku-protocol/agave) [https://github.com/raiku-protocol/agave/tags](https://github.com/raiku-protocol/agave/tags) [onboarding process](/technical-docs/node-operator-guide/quickstart-1) --- # Architecture | Raiku [PreviousAckermann v1](/technical-docs/ackermann-v1) [NextTransaction types](/technical-docs/ackermann-v1/components-communication) Last updated 1 month ago Was this helpful? Raiku is an advanced protocol built on Solana that introduces innovative transaction scheduling capabilities while leveraging the underlying blockchain's security and decentralization. By combining modified Solana validators with specialized coordination software, Raiku creates a powerful infrastructure for precise transaction execution and enhanced network functionality. [](#system-components) System Components --------------------------------------------- The Raiku system consists of these primary components below which come together to enable Raiku protocol. System Components[](#system-components-1) 1. `Ackermann-node` which is the coordination network responsible for finding the optimal path depending on the transaction type(s), communicating with our `Ackermann-sidecar.` 2. `Ackermann-sidecar` which is Agave compatible, which ensures the bridge between between the `Ackermann-node` and the `Ackermann-validator.` 3. `Ackermann-validator`\- Raiku's technical design introduces the`Ackermann-sidecar` approach, which minimizes modifications to existing validator codebases while implementing novel features without compromising performance. This paradigm enables seamless integration with diverse validator implementations, reducing validator development efforts and responding effectively to Network Operators' (NOs') demands. [](#extending-solana) Extending Solana ------------------------------------------- The `Ackermann-node` and `sidecar` enable validators on Solana to provide soft-commitments about transaction landing, leveraging stake-weighted quality of service (swQoS) as well as introducing our own quality of service, slot-inclusion (siQoS). Raiku operates in an optimistic failure mode: proposers _can_ breach any commitments they make, but will be penalised when they do. The system consists of multiple components and features, which is rolled out in production over different release phases. A high level overview of each phase is described below: * **Raiku v1** enables (1) deterministic and fast transaction inclusion, and (2) ahead-of-time inclusion which allows applications to reserve block-space either ahead-of-time (AOT) or just-in-time (JIT) where applications can interact with builders in real time, enabling instant transaction confirmation. * **Raiku v2** enables (1) global account model for external applications, which provides a uniform account data-structure supporting instructions from various virtual machines such as SVM, EVM and Move. (2) An RFQ Liquidity system. * **Raiku v3** (third version) optimises for global message-passing latency and network load-balancing by allowing the public market to operate the `Ackermann-node` at their own accord. Ultimately, this will increase the value of differentiated block space for users and applications, and generate more yield for validators. * * * Simple interactions between system components Native & External Apps Transaction Flow Diagram ![](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F840502766-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fjye3DdeTodH7AQyCju8t%252Fuploads%252Fj5m9PoqKgdDIPd6qVIMl%252Fgen-arch.png%3Falt%3Dmedia%26token%3Dd26d47b0-e5d6-4715-ac58-39ff4e89e307&width=768&dpr=4&quality=100&sign=8b04cce&sv=2) ![](https://docs.raiku.com/~gitbook/image?url=https%3A%2F%2F840502766-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fjye3DdeTodH7AQyCju8t%252Fuploads%252FrkFibfg7p3MuKTZ7FOAt%252FScreenshot%25202025-03-12%2520at%252014.47.21.png%3Falt%3Dmedia%26token%3D9b261b4d-6a4a-4052-ab59-43ff08fda38b&width=768&dpr=4&quality=100&sign=fdf91f3a&sv=2) --- # Build and Run | Raiku [PreviousThe Ackermann Sidecar](/technical-docs/node-operator-guide/running-a-sidecar) [NextConfiguration](/technical-docs/node-operator-guide/running-a-sidecar/configuration) Last updated 19 days ago Was this helpful? The Ackermann sidecar provides an efficient transaction dispatch mechanism between our Ackermann node and Ackermann validator through its proprietary protocol. It functions as a middleware bridge that ensures reliable and continuous communication with the node at all times. From a security perspective, it helps us maintain the smallest possible fingerprint on any Solana validator node with barely any performance overhead. Before exploring the configuration details, we recommend building or running the Ackermann sidecar on your system by following the instructions in this section. [](#build-from-source) Build from source --------------------------------------------- The sidecar is available at . Copy make build-sidecar ACKERMANN_SC_LOGGER_VERBOSITY=info make run-sidecar You should be able to run the sidecar at this point. However, you may experience some errors in the output related to the sidecar's dependencies - the Ackermann node and validator. You need to go through the configuration of the sidecar and if this doesn't work, you can find some help in our . Copy ❯ make run-sidecar cargo run -p ackermann-sidecar Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.48s Running `target/debug/ackermann-sidecar` 2025-03-24T06:53:43.082782Z INFO ThreadId(01) ackermann_sidecar::cli: crates/sidecar/src/cli.rs:411: Starting Ackermann SideCar 2025-03-24T06:53:43.082897Z INFO ThreadId(01) ackermann_sidecar::cli: crates/sidecar/src/cli.rs:412: Version: 0.1.41 2025-03-24T06:53:43.082903Z INFO ThreadId(01) ackermann_sidecar::cli: crates/sidecar/src/cli.rs:413: 2025-03-24T06:53:43.082908Z INFO ThreadId(01) ackermann_sidecar::cli: crates/sidecar/src/cli.rs:414: ⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣶⣿⣿⣿⣿⣿⣿⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡇⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⣴⣿⢟⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡇⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⣼⣿⣣⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣯⣾⣿⣿⡿⢟⣭⡿⠋⣠⣿⣿⣿⣿⣿⠟⣡⣾⣿⣷⣿⣿⣿⣿⠁⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⢰⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠷⠋⢁⣤⣿⡿⣛⣿⡿⠋⠀⣰⣿⣿⣿⣿⣿⣿⡿⢹⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⢀⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡿⠛⠉⢁⣠⣾⠿⣛⣽⡾⠟⠉⠀⢀⣼⣿⣿⣿⣿⣿⣿⠏⠀⠘⡄⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⢀⣾⣏⣼⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣴⡶⢾⣿⣯⣶⡿⠛⠁⠀⠀⠀⣴⣿⣿⣿⣿⣿⡿⠛⠁⠀⠀⠀⡇⠀⠀⠀⠀⠀ ⠀⠀⠀⢠⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠃⠈⢰⡞⠛⠯⠉⠙⢷⠀⠀⠀⣠⣾⣿⣿⣿⣿⡿⠟⠓⠦⢄⡀⠀⠀⢱⠀⠀⠀⠀⠀ ⠀⠀⢠⣿⡏⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠿⠟⣿⣿⣷⣤⡀⠀⣀⣴⣿⣿⣿⣿⣿⠿⠛⠁⠐⠂⠀⠀⠈⠑⠢⠸⡄⠀⠀⠀⠀ ⠀⠀⣞⡟⢨⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠘⠧⣒⣀⣻⣿⣷⣿⣹⣾⢟⣫⣵⡿⠟⠋⢡⢴⣶⣶⣤⣄⣀⡀⠀⠀⠀⠢⣽⡄⠀⠀⠀ ⠀⠀⣿⣷⣸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠻⣏⠀⠀⠀⠀⠀⠀⠈⣩⡽⠾⠟⠋⠁⠀⠀⠀⠀⢀⣿⣿⣿⣯⡿⠿⣦⣄⠀⣸⣿⣷⣄⠀⠀ ⡆⠀⣿⣿⣿⣿⣿⣿⣿⣟⣿⣿⣿⣿⡿⠀⠈⠂⠀⠀⠀⠀⠀⠀⠀⠀⠀⡐⠁⠀⠀⠀⠀⠀⠀⠀⠉⠙⠪⣍⣢⣌⣻⣼⣿⡿⢋⣿⣦⡀ ⠹⡀⢹⣿⡏⣸⣿⡇⣿⣿⣿⣿⣿⣿⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣿⡿⠋⢠⣾⣿⣿⣷ ⠀⡇⠘⣿⡅⣿⣿⡇⣾⣿⣿⣿⣿⣿⣷⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣤⣶⠿⠟⠁⢀⣴⡿⣿⣿⣿⣿ ⠀⢸⠀⢻⡿⠽⣿⣿⠹⣿⣿⣿⣿⣿⣿⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢈⠴⠋⠁⠀⣠⣶⣿⡿⢣⣿⣿⣿⣿ ⠀⠈⣑⡮⣷⠤⠽⠿⢧⣙⣿⣿⣿⣿⣿⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⡤⠖⠛⢯⠞⢉⣠⣿⣿⣿⣿⣿ ⠀⠀⠁⡴⡇⠀⠀⡄⠀⠀⠉⣿⣿⣿⣿⣿⡆⠀⠀⠀⠀⠀⣿⣭⣍⣉⠓⠒⠲⠤⢄⡀⠀⠀⠀⠀⠀⠀⠀⠄⠊⠁⣰⣿⣿⣿⣿⣿⣿⣿ ⠀⠀⡟⠀⡇⠀⡰⠿⣿⣟⣢⢼⣿⣿⣿⣿⣿⣆⠀⠀⠀⠀⠘⣿⡿⠿⠿⣿⣶⣶⣦⣼⡷⠀⠀⠀⠀⠀⠀⠀⣠⣾⣿⣿⢯⣿⣿⣿⣿⣿ ⠀⠀⠀⠀⠀⣼⠷⠚⠉⠈⠻⣿⣶⣭⣝⡿⢿⣿⣦⠀⠀⠀⠀⠈⠳⠤⣀⣀⣀⣠⠾⠋⠀⠀⠀⠀⠀⠀⣠⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⠀⢰⠦⠒⡫⠀⠀⣀⢴⡨⠗⠚⢻⣿⣿⣿⣷⣶⣭⣗⡢⠤⣀⣀⠀⠲⠤⠤⠤⠀⠀⠀⠀⠀⠀⢀⣴⣿⣿⢟⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿ ⠀⢸⠀⠰⠁⣤⠾⠋⠁⠀⠀⠀⠀⠹⣍⣿⣷⣯⣝⡻⠿⣕⣲⣤⢭⣉⣉⣒⠒⠤⠀⣠⣀⣤⣾⣿⣟⣿⣿⣿⣿⣿⣿⣿⣿⣿⢻⣿⣿⣿ ⢀⡇⠀⣴⢫⡁⠀⠀⣀⡴⠞⠛⠉⠉⢿⢿⣿⠻⣍⠙⠱⣦⣬⣙⡻⠿⣿⣿⣿⣿⣿⣿⣿⣖⣦⠤⢴⣶⣾⣿⠟⠟⢉⣼⣿⡿⢸⣿⣿⣿ ⣾⡇⠀⢻⡄⢙⠛⠋⠁⠀⠀⠀⢀⡄⠸⣷⣯⣳⢤⣉⡒⠦⣝⡛⠿⣛⣶⣶⣶⣤⡄⠠⠤⠤⠴⣶⣿⣿⣿⠏⢀⣤⣾⣿⣿⠃⣼⣿⣿⡿ ⣿⠹⠀⠀⡇⠘⡇⠀⠀⢤⣤⡶⠋⢀⣴⣿⣿⣿⡳⢮⣉⠓⠶⠍⠑⠒⠊⠉⠛⠒⠦⣤⣤⠴⠟⣉⣥⢏⣡⣶⣿⣿⡿⠛⣡⣾⣿⣿⣿⣿ ⣿⣇⠀⠀⠀⠀⢱⠀⠀⠀⠘⣇⣰⣿⣿⣟⢿⣿⣿⡷⢦⣝⣲⣶⣶⠦⢤⣤⡤⠤⠄⣠⣴⣾⠿⣫⣷⠟⢛⡋⠉⢀⡄⣼⣿⣿⣿⣿⣯⣵ ⣿⣿⠀⠀⠀⠀⠀⢧⡀⠀⠀⠘⣿⢸⣿⣿⣿⣝⢿⣯⡲⢶⣤⣭⣿⣛⡛⣉⣴⣾⡿⢟⣫⣴⣾⣟⣵⣾⣿⡏⢰⣿⣼⣿⣿⣿⣿⣾⠟⠋ 2025-03-24T06:53:43.083074Z INFO ThreadId(01) ackermann_sidecar::cli: crates/sidecar/src/cli.rs:442: 2025-03-24T06:53:43.083108Z INFO ThreadId(01) ackermann_sidecar::cli: crates/sidecar/src/cli.rs:445: Config { logger_verbosity: "info", solana_client: SolanaClientConfig { url: http://localhost:8899, commitment_level: Finalized, timeout: 30s, retry: RetryConfig { max_attempts: 5, base_exponent: 2, max_interval: 30s, backoff_multiplier: 500, }, network_type: Quic, quic_host: "127.0.0.1", quic_identity_keypair: [\ xxx\ ], }, tasks: TasksConfig { node_stream_supervisor_config: NodeStreamSupervisorConfigCli { sibling_tasks_channel_size: 100000, ackermann_node_config: AckermannNodeGrpcConfig { node_url: "http://localhost:50052", timeout: 1s, retry: RetryConfig { max_attempts: 5, base_exponent: 2, max_interval: 30s, backoff_multiplier: 500, }, auth: AuthConfig { is_auth_required: true, private_key: "-----BEGIN PRIVATE KEY-----xxx\n-----END PRIVATE KEY-----\n", identity: "sidecar-1", token_expiration: 30s, token_header: "X-Auth-Token", identity_header: "X-Auth-Identity", }, }, params_shared_with_node: ParametersSharedWithNode { send_transaction_config: SendTransactionConfig { timeout: 10s, }, }, stream_with_node: NodeStreamSupervisorStreamWithNodeConfigCli { channel_size: 10000, retry: RetryConfig { max_attempts: 120, base_exponent: 2, max_interval: 300s, backoff_multiplier: 500, }, }, forward_transactions_task: NodeStreamSupervisorForwardTransactionsTaskConfigCli { channel_size: 10000, forward_transactions_task_config: ForwardTransactionTaskConfigCli { transaction_submission_slot_delta: 10, transaction_queue: ForwardTransactionTaskTransactionQueueConfigCli { sleep_interval: 500µs, max_age: 60s, retry_interval: 400ms, max_retries: 100, queue_channel_size: 10000, }, }, }, validator_health_task: NodeStreamSupervisorValidatorHealthTaskConfigCli { channel_size: 10000, interval: 1s, }, last_slot_update_task: NodeStreamSupervisorLastSlotUpdateTaskConfigCli { connection_retry: RetryConfig { max_attempts: 60, base_exponent: 2, max_interval: 30s, backoff_multiplier: 500, }, wss_url: ws://localhost:8900, }, }, node_identities_task_config: NodeIdentitiesTaskConfig { tx_channel_size: 10, refresh_interval: 2s, }, metrics_task_config: MetricsTaskConfig { tx_channel_size: 1000, log_interval: 60s, }, }, metrics_server: MetricsServerConfig { socket_addr: "127.0.0.1:50054", shutdown_timeout: 2s, }, grpc_server: GrpcServerConfig { socket_addr: "127.0.0.1:50055", shutdown_timeout: 2s, }, } 2025-03-24T06:53:43.083599Z INFO ThreadId(01) ackermann_sidecar::cli: crates/sidecar/src/cli.rs:446: Chain spec: ChainSpecWrapper { inner: Local } 2025-03-24T06:53:43.090083Z INFO ThreadId(01) ackermann_drivers::net: crates/drivers/src/net.rs:14: Resolved 127.0.0.1 to [127.0.0.1:0] 2025-03-24T06:53:43.094322Z INFO ThreadId(01) ackermann_sidecar::tasks::solana_interface::quic: crates/sidecar/src/tasks/solana_interface/quic.rs:66: Connecting to TPU address: 127.0.0.1:1033 2025-03-24T06:53:43.094397Z INFO ThreadId(01) ackermann_sidecar::tasks::metrics_task: crates/sidecar/src/tasks/metrics_task.rs:151: MetricsTask has started 2025-03-24T06:53:43.095333Z INFO ThreadId(05) ackermann_sidecar::tasks::metrics_task: crates/sidecar/src/tasks/metrics_task.rs:175: Current metrics: MetricsData { tx_queue_size_total: 0, txs_forwarded_to_chain_total: 0, txs_failed_total: 0, txs_received_total: 0, txs_already_processed_total: 0, txs_blockhash_not_found_total: 0, last_processed_slot: 0, last_message_received_at: None, last_forward_transaction_at: None, last_nodestream_send_at: None, last_validator_health_send_at: None, last_tx_received_at: None, sidecar_data: SidecarData { validator_identity: 8iCrmxJkA8kyEQQidECF6dcVki2M1Af1uLMpwNhgfXJ9, sidecar_pubkey: EGpCw8F3h5xrvi8Ut17pWr6SjCs4ca3HGmsXkNfSjuo, sidecar_config: SidecarConfig { send_transaction_config: SidecarSendTransactionConfig { timeout: 10s } } } } [](#prebuilt-binary) **Prebuilt Binary** --------------------------------------------- [](#prebuilt-container) Prebuilt Container ----------------------------------------------- For those who prefer to run a validator in a docker container, you can find the images in our GCP artifact repository, here: * `europe-west3-docker.pkg.dev/raiku-mainnet/ackermann/external/ackermann-sidecar` You should now see the sidecar running and logs being printed to the console. For the different configurations, you can check the next section. For those who prefer not to build from source or use a docker container, you can go to and use one of our prebuild releases. [https://github.com/raiku-protocol/ackermann](https://github.com/raiku-protocol/ackermann) [FAQ](/technical-docs/node-operator-guide/running-a-sidecar/faq) [https://github.com/raiku-protocol/ackermann/tags](https://github.com/raiku-protocol/agave/tags) --- # Configuration | Raiku [PreviousBuild and Run](/technical-docs/node-operator-guide/running-a-sidecar/build-and-run) [NextObservability](/technical-docs/node-operator-guide/running-a-sidecar/observability) Last updated 5 days ago Was this helpful? This section will guide you through the configuration of the Ackermann sidecar that is required in order to get the infrastructure up and running. There's two different ways that the sidecar can be configured, the first one is using a configuration file and the second one is using environment variables. ### [](#configuration-file) Configuration file The sidecar configuration file is located at `etc/default.toml`. This file contains the configuration for the sidecar. The configuration file is in the format. The configuration file contains the following fields: Copy ############################################################ ### Global Configuration ### ############################################################ # optional variables # version passed to the software for debug purposes as this values is displayed in the health endpoint) ACKERMANN_SC_VERSION = "0.1.0" # mandatory variables # log verbosity level, can be the following values: # (warn, debug, info, error) logger_verbosity = "info" ############################################################ ### GRPC Server ### ############################################################ # the sidecar grpc server that is used to get its health and some monitoring data [grpc_server] socket_addr = "127.0.0.1:50055" graceful_shutdown_timeout = "2s" ############################################################ ### Metrics Server ### ############################################################ # the sidecar metrics server that is used to expose Prometheus metrics [metrics_server] socket_addr = "127.0.0.1:50054" graceful_shutdown_timeout = "2s" ############################################################ ### Solana Client ### ############################################################ # the sidecar communicates with the validator node # here you can find the options that can be tweaked in order to give # you the best outcome possible depending on your architecture [solana_client] # validator rpc url url = "http://localhost:8899" # commitment level commitment_level = "finalized" # timeout before dropping the request timeout = "30s" # general retry mechanism - each option is self-explanatory retry.max_attempts = 5 retry.base_exponent = 2 retry.max_interval = "30s" retry.backoff_multiplier = 500 # connection mode, can be the following values: # (rpc, quic) # rpc will be deprecated soon, it's used on devnet for testing purposes network_type = "quic" # in case of a quic network type selected (as it should) # network_type = "quic" quic_socket_addr_binding = "127.0.0.1" quic_host = "127.0.0.1" quic_identity_keypair = "" # override this variable using your secret injector ############################################################ ### Node Stream Supervisor ### ############################################################ [tasks.node_stream_supervisor] # Size of the channel used for communication between sibling tasks sibling_tasks_channel_size = 10000 # The interval at which the NodeStreamSupervisor reevaluates the shutdown conditions reevaluate_shutdown_interval = "1s" # Configuration for connecting to the Ackermann node [tasks.node_stream_supervisor.ackermann_node_sc_grpc_server] # URL of the Ackermann node node_url = "http://localhost:50052" # Retry configuration for node connection # This retry configuration is used when the sidecar is trying to connect to the Ackermann node for the first time # for reconnects, the retry configuration is defined in the `tasks.node_stream_supervisor.stream_with_node` section retry.max_attempts = 5 retry.base_exponent = 2 retry.max_interval = "30s" retry.backoff_multiplier = 500 # Authentication settings authentication.is_required = true # ES256 private key for signing requests, this should the key that # you used to generate the pubkey given to our team during the onboarding process authentication.private_key = "" # override this variable using your secret injector # Unique identity for the sidecar authentication.identity = "sidecar-1-company-name" # Token expiration time authentication.token_expiration = "30s" # Configuration for the channel used to send messages between the Sidecar and the Node # More info: https://docs.rs/tonic/latest/tonic/transport/struct.Server.html # https://docs.rs/tonic/latest/tonic/transport/struct.Endpoint.html channel.connect_timeout = "5s" channel.timeout = "5s" channel.tcp_keepalive = "30s" channel.tcp_nodelay = true channel.http2_keep_alive_interval = "None" channel.keep_alive_timeout = "None" channel.keep_alive_while_idle = true channel.buffer_size = 131072 #128KB channel.initial_stream_window_size = 16777216 #16MB channel.initial_connection_window_size = 16777216 #16MB channel.http2_adaptive_window = false # Timeout for the connection establishment between the sidecar and the node establish_connection_timeout = "10s" # Parameters shared with the Ackermann node [tasks.node_stream_supervisor.params_shared_with_node.send_transaction_config] # Maximum timeout for transaction forwarding timeout = "10s" shutdown_timeout = "30s" # Configuration for the stream connection with the node [tasks.node_stream_supervisor.stream_with_node] # Size of the channel for node communication channel_size = 10000 # Stream connection retry configuration to the node # This retry configuration is used when the sidecar is trying to establish a stream with the node # and when the connection is lost. For first initial connection, the retry configuration is defined in the # `tasks.node_stream_supervisor.ackermann_node_sc_grpc_server` section retry.max_attempts = 120 retry.base_exponent = 2 retry.max_interval = "5m" retry.backoff_multiplier = 500 # Configuration for the transaction forwarding task [tasks.node_stream_supervisor.forward_transactions_task] # Size of the channel for transaction forwarding channel_size = 10000 [tasks.node_stream_supervisor.forward_transactions_task.forward_transactions_task_config] # Transaction submission slot delta. # This is to ensure that the validator has enough time to process the transaction. # A smaller value can result in transaction missing the target slot. A value larger than 20 can cause the validator # to drop the transaction. transaction_submission_slot_delta = 10 # Configuration for the transaction queue [tasks.node_stream_supervisor.forward_transactions_task.forward_transactions_task_config.transaction_queue] # Interval between queue processing attempts sleep_interval = "500us" # Maximum age of transactions in the queue max_age = "60s" # Interval between transaction retry attempts retry_interval = "400ms" # Maximum number of retry attempts per transaction max_retries = 100 # Size of the queue channel queue_channel_size = 10000 # Configuration for the validator health monitoring task [tasks.node_stream_supervisor.validator_health_task] # Size of the channel for health updates channel_size = 10000 # Interval for health checks interval = "1s" # Configuration for the slot update task [tasks.node_stream_supervisor.last_slot_update_task] # Retry configuration for pubsub connection connection_retry.max_attempts = 20 connection_retry.base_exponent = 2 connection_retry.max_interval = "30s" connection_retry.backoff_multiplier = 500 # WebSocket URL for slot updates wss_url = "ws://localhost:8900" ############################################################ ### Standalone Tasks ### ############################################################ # the sidecar task responsible for exposing metrics to the metrics server [tasks.metrics_task] tx_channel_size = 1000 # display the sidecar metrics in the log at a certain interval - noise reduction log_interval = "60s" [tasks.node_identities_task] # the bounded channel size that is used by the task to send information related # to the validator identites tx_channel_size = 10 # call the validator at every interval to refresh the data in case any new # is being added on the fly refresh_interval = "2s" ### [](#authentication-to-the-protocol-node) Authentication to the protocol node This section covers a little more indepth the authentication between the Ackermann sidecar and the Ackermann node. The sidecar communicates with the node using gRPC and implements several security measures: * Signs requests using a private key * Uses a unique identity for self-identification * Sets token expiration times These mechanisms ensure secure and verifiable communication between components. More about security concern in the onbording form. #### [](#a-note-on-token-expiration) **A Note on token expiration** Token expiration defines the period after which a token becomes invalid. For security purposes, operators should maintain short token expiration times. However, the token expiration time must exceed the connection timeout between the sidecar and the node. Therefore, always ensure that `tasks.node_stream_supervisor.ackermann.authentication.token_expiration` is greater than `tasks.node_stream_supervisor.ackermann.timeout` to prevent connectivity issues. ### [](#precedence-and-overriding-configuration-values) Precedence and overriding configuration values The values from the configuration file can be overridden with using environment variables. This is particularly useful if you are injecting those environment variables in your deployment pipeline. The environment variables should be prefixed with `ACKERMANN_SC_`. For example, to override the `logger_verbosity` value, you can set the environment variable `ACKERMANN_SC_LOGGER_VERBOSITY`. If the value you are trying to override is nested, you can use the double underscore `__` to separate the nested values. For example, to override the `pubkey` value in the `rollup_grpc_server.auth_config.customers.identity_pubkey` section, you can set the environment variable as such `ACKERMANN_SC_ROLLUP_GRPC_SERVER__CUSTOMERS__IDENTITY_PUBKEY`. Currently, our protocol operates on a permissionned basis, allowing access to only approved NOs. If you wish to become one, please see the . [TOML](https://toml.io/en/) [Register section](/technical-docs/node-operator-guide/quickstart-1) --- # Quickstart | Raiku [PreviousFAQ](/technical-docs/node-operator-guide/running-a-sidecar/faq) [NextRegister](/technical-docs/developer-guide/quickstart-1) Last updated 1 month ago Was this helpful? As a Solana user or builder who wants to have a better Solana experience, our SDK is available for use on testnet. Or If you're interested in running our infrastructure, please refer to our separate If you want to use our SDK, you need to available in the next section of this guide. [NO Guide.](/technical-docs/node-operator-guide/quickstart) [complete the protocol registration process](/technical-docs/node-operator-guide/quickstart-1) --- # Register | Raiku To join our testnet program, please submit your application through the form below. Once our team confirms your acceptance, you may proceed to the next section of this guide which is dedicated to using our SDK with the API Key attributed to your team. [PreviousQuickstart](/technical-docs/developer-guide/quickstart) [NextSDK](/technical-docs/developer-guide/sdk) Last updated 1 month ago Was this helpful? --- # SDK | Raiku Only privately available for users registered in the private testnet. [PreviousRegister](/technical-docs/developer-guide/quickstart-1) Last updated 1 month ago Was this helpful? ---