GRPC

Built upon the open-source Yellowstone protocol (Layer 1), Carbium optimizes the delivery pipeline to serve comprehensive, atomic block data with industry-leading latency (~22ms). While other providers prioritize raw "shreds" for marginal speed gains, Carbium focuses on data fidelity and parsing efficiency, offering a gold standard stream for sophisticated trading, indexing, and analytics.

The Carbium Difference

In the Solana ecosystem, gRPC providers generally fall into two categories: those who stream Shreds (raw data fragments) and those who stream Full Blocks (complete ledger units).

1. The "Latency Trap"

A common marketing tactic is to advertise "Shred" latency (8–11ms) as superior to "Full Block" latency (22ms). However, this metric is often misleading when viewed against the actual Solana network speed.

The Reality: Because Solana slots occur every ~400ms, the 13ms difference between receiving a shred and a full block effectively changes nothing regarding transaction inclusion or execution. You cannot "beat" the slot significantly faster with shreds.

2. Why We Choose Full Blocks (The Gold Standard)

Carbium prioritizes Full Block delivery to provide a robust engineering solution:

• Atomic Integrity: Receive the complete state update in one go. No partial failures or missing fragments.
• Parsing Efficiency: Ideal for complex database indexing (Postgres/RocksDB) where data completeness is critical.
• Simplicity: Reduces the overhead of reassembling shreds on the client side.

Note: We understand some legacy systems prefer shreds. Carbium will be adding a Shreds (Layer 2 Complete) tier soon for users who require that specific ingestion method.

Architecture: From L1 to L2

Carbium is not just a host; it is an optimization layer.

1. Layer 1 (Yellowstone): We utilize the standard, open-source Rust implementation used to interface with Solana's RocksDB.
2. Layer 2 (Carbium): We apply a proprietary optimization pipeline that aggregates shreds into atomic blocks server-side, ensuring maximum fidelity before the data ever reaches your application.

Connection Details

Carbium uses the standard Yellowstone gRPC proto definitions. If you have used other Solana gRPC services, switching to Carbium is a drop-in replacement.

Endpoint

• WebSocket URL: wss://grpc.carbium.io
• Authentication:
  • Header: x-token: <YOUR_API_KEY> (Recommended for standard clients)
  • Query Param: ?apiKey=<YOUR_API_KEY> (For quick connection testing)

Code Examples

Rust

Using the standard yellowstone-grpc-client crate.

use yellowstone_grpc_client::GeyserGrpcClient;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // 1. Define Endpoint & Auth
    let endpoint = "[https://grpc.carbium.io](https://grpc.carbium.io)";
    let x_token = "YOUR_API_KEY";

    // 2. Connect to Carbium Layer 2
    let mut client = GeyserGrpcClient::connect(endpoint, x_token, None)?;
    
    // 3. Subscribe to Full Blocks
    // Carbium streams are optimized for 'blocks' subscriptions
    let (mut subscribe_tx, mut stream) = client.subscribe().await?;
    
    // ... define your subscription filters here
    
    Ok(())
}

FAQ

Q: Is Carbium compatible with standard Yellowstone clients?

A: Yes. Carbium is fully compatible with the standard open-source Yellowstone protocol. You can use existing libraries (Rust, TS, Go, Python) and simply swap the endpoint URL to point to Carbium's Layer 2 network.

Q: Why is your "Full Block" stream 22ms when others claim 10ms?

A: Those claims usually refer to "shreds" (partial data). Carbium delivers the entire block in 22ms. We are the fastest Full Block provider in the industry.

Q: Does the extra 12ms latency matter for trading?

A: Generally, no. With Solana's slot times averaging 400ms, a 12ms delta is negligible for execution. However, the data quality difference is massive. Full Blocks allow for robust, error-free parsing that shreds cannot match.