A Dedicated Architecture for Solana at Coinbase
Tl;dr: To meet the scaling demands of Solana, Coinbase has moved away from its legacy chain-agnostic processing model. We engineered a dedicated, high-throughput streaming architecture with parallel block processing, resulting in a 12x increase in transaction processing throughput and a 20% reduction in deposit latency.
Six years ago, Coinbase integrated Solana into its platform using a generalized, chain-agnostic transaction processing architecture. This "one-size-fits-all" approach, while streamlining integration across 60 different blockchains, was fundamentally constrained by the "lowest common denominator" of network behaviors.
Our legacy system consists of three distinct layers:
The Node Layer: Operates the blockchain infrastructure and provides RPC endpoints for accessing raw ledger data.
The Indexing Layer (Blockchain I/O): Functions as an abstraction that standardizes the system by polling for finalized blocks and parsing transaction details.
The Wallet Layer (Wallet Service): Acts as the source of truth for all Coinbase-managed blockchain addresses to filter for Coinbase-relevant transaction data delivered through a sequential gRPC stream while simultaneously managing balance lookups and transaction construction.
Figure 1: High level architecture of Legacy System
This legacy design introduced two critical bottlenecks that resulted in delayed deposits and withdrawals during peak traffic periods.
Sequential Processing: The design was beholden to constraints necessary for other chains, such as strict sequential processing for nonce management and accounting for chain reorgs. These were artificial bottlenecks for Solana, which does not use nonces and achieves fast finality.
Polling Latency: The "Blockchain I/O" layer relied on inefficiently polling RPC endpoints for finalized slots. This introduced unavoidable delays, a major issue during high-traffic events, and was incompatible with the sub-second finality anticipated with Solana's upcoming Alpenglow consensus upgrade.
The Innovation: A Dedicated Streaming Pipeline
We collaborated with the Solana Foundation, Anza, Helius, and Triton One to design a dedicated, Solana-specific processing architecture.The centerpiece of this design is Solana I/O, a custom-built indexing and abstraction layer designed to decouple Solana’s high-throughput data stream from our shared legacy stack. This allowed us to modernize the infrastructure while maintaining the high-level Wallet Service interface, effectively preserving all existing security protocols and reconciliation logic.
This vision is realized through a specialized, parallel streaming pipeline:
Address Registration: The Wallet Service identifies new addresses for tracking and notifies Solana I/O, which records them in a database (a.1, a.2).
Hybrid Real-Time Ingestion: Transitions from slow polling to a hybrid model to leverage Geyser and stream finalized slot heights in real-time, which immediately triggers parallel RPC calls to retrieve block data (b.1, b.2, b.3).
This approach combines high reliability with zero data loss, facilitating seamless node failovers and historical data backfilling, which are typically challenging for architectures relying exclusively on push-based Geyser streams.
Parallel Filtering and Kafka Streaming: The Solana I/O processor parses blocks and filters transactions for tracked addresses in parallel, writing them to a dedicated Kafka cluster as individual messages (b.4, b.5).
Concurrent Processing: A specialized Kafka consumer ingests the parsed blocks and filtered transaction data, transforming them into existing entity structures before storing them in the Wallet Service’s database in parallel (b6, b7, b8).
This "transform-then-store" approach ensures a seamless drop-in replacement for legacy subcomponents.
Since parallel processing can cause data to arrive out of order, the system uses a high-water mark as a checkpoint to maintain the strict sequencing that certain components need.
Event Notification: Once writes are confirmed, the Solana I/O consumer triggers event-driven processes like real-time deposit notifications (b.9).
Figure 2: New Solana transaction processing architecture
By enabling the concurrent parsing, filtering, and persistence of multiple blocks, this architecture eliminates legacy backlogs and drastically reduces end-to-end latency.
The Impact: High Throughput and Lower Latency
The new architecture was validated through a 30-day Shadow Mode, which ran in parallel with the legacy system to ensure zero discrepancies in balance updates and transaction states. On September 10, 2025, the system was promoted to production.
Rigorous production load testing established new performance benchmarks for the platform:
12x increase in Solana transaction processing throughput.
5x increase in Solana withdrawal volume capacity.
These synthetic benchmarks have translated directly into real-world resilience. Since going live, the architecture has seamlessly absorbed production traffic spikes of 8x the baseline volume with no performance degradation and achieved a 20% reduction in deposit latency.
Figure 3: Volume of Interesting Solana Transactions Processed Per Second
Figure 4: Solana Deposit Processing Latency
This re-architecture ensures Coinbase is built to scale alongside Solana’s growth, enabling broader support of the Solana ecosystem, its developers, and its users.
