Skip to main content

Overview

grpc.raze.bot exposes a Yellowstone Geyser gRPC feed (Dragon’s Mouth) — the same geyser.Geyser/Subscribe interface used by the major Solana data providers. It is the lowest-latency way to consume raw account, slot, transaction, block and entry updates from Raze, and is fully compatible with the standard yellowstone-grpc client libraries.
Endpointgrpc.raze.bot:443
TransportHTTP/2 over TLS
Servicegeyser.Geyser (Yellowstone / Dragon’s Mouth)
Authx-token metadata = your sk_ API key
RoutingGeoDNS routes to the nearest region automatically
For higher-level, pre-parsed events (trades, deploys, migrations, alerts) use the Streaming WebSocket API at wss://ws.raze.bot/ws/sol. Use gRPC when you want the raw geyser stream and minimum latency.

Authentication

Pass your API key as the x-token gRPC metadata header on the channel. This is the same key you use as X-Api-Key / ?apikey= on the REST and RPC endpoints — only the header name differs (Yellowstone clients call it x-token).
metadata:  x-token: sk_your_api_key
Requests without a valid token are rejected with UNAUTHENTICATED.

Subscribe

A single Subscribe bidirectional stream carries every update type. Filter by account, transaction, slot, block, blockMeta or entry in the SubscribeRequest.
// cargo add yellowstone-grpc-client yellowstone-grpc-proto futures tokio
use yellowstone_grpc_client::GeyserGrpcClient;
use yellowstone_grpc_proto::geyser::{
    SubscribeRequest, SubscribeRequestFilterTransactions, CommitmentLevel,
};
use std::collections::HashMap;
use futures::{SinkExt, StreamExt};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let mut client = GeyserGrpcClient::build_from_shared("https://grpc.raze.bot:443")?
        .x_token(Some("sk_your_api_key"))?
        .tls_config(Default::default())?
        .connect()
        .await?;

    let mut txs = HashMap::new();
    txs.insert("all".to_string(), SubscribeRequestFilterTransactions {
        vote: Some(false),
        failed: Some(false),
        ..Default::default()
    });

    let req = SubscribeRequest {
        transactions: txs,
        commitment: Some(CommitmentLevel::Processed as i32),
        ..Default::default()
    };

    let (mut sink, mut stream) = client.subscribe().await?;
    sink.send(req).await?;
    while let Some(update) = stream.next().await {
        println!("{:?}", update?);
    }
    Ok(())
}

Update types

The SubscribeRequest accepts the standard Yellowstone filter maps; set the ones you need and leave the rest empty:
FilterStreams
accountsAccount writes (by owner / account / data filters)
slotsSlot status updates
transactionsFull transactions (filter by accountInclude / accountExclude / accountRequired, vote, failed)
transactionsStatusTransaction status only (lighter than full transactions)
blocksFull blocks
blocksMetaBlock metadata (no transactions)
entryEntries (PoH ticks)
commitment may be PROCESSED, CONFIRMED or FINALIZED.
Transactions cost roughly 10× the bandwidth of account updates — scope your filters (accountInclude, accountRequired) as tightly as possible to keep latency low.