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.
| |
|---|
| Endpoint | grpc.raze.bot:443 |
| Transport | HTTP/2 over TLS |
| Service | geyser.Geyser (Yellowstone / Dragon’s Mouth) |
| Auth | x-token metadata = your sk_ API key |
| Routing | GeoDNS 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:
| Filter | Streams |
|---|
accounts | Account writes (by owner / account / data filters) |
slots | Slot status updates |
transactions | Full transactions (filter by accountInclude / accountExclude / accountRequired, vote, failed) |
transactionsStatus | Transaction status only (lighter than full transactions) |
blocks | Full blocks |
blocksMeta | Block metadata (no transactions) |
entry | Entries (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.