Raze.bot Developers

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 metadata and entry updates from Raze, and works with the standard yellowstone-grpc client libraries unchanged.


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 — on Subscribe and on every unary method (GetSlot, GetLatestBlockhash, GetBlockHeight, IsBlockhashValid, GetVersion, Ping, SubscribeReplayInfo), all of which this endpoint implements. A single Subscribe stream carries every update type. Filter by account, transaction, transactionsStatus, slot, blockMeta or entry in the SubscribeRequest — see the support table below for the two exceptions.

The stream is bidirectional on the wire but read-once in practice: only the first SubscribeRequest is applied. Re-sending one to change filters mid-stream does nothing today — reconnect with the new filters instead.

// 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(())
}

// npm i @triton-one/yellowstone-grpc
import Client, { CommitmentLevel } from "@triton-one/yellowstone-grpc";

const client = new Client("https://grpc.raze.bot:443", "sk_your_api_key", undefined);

const stream = await client.subscribe();
stream.on("data", (update) => console.log(update));

stream.write({
  accounts: {},
  slots: {},
  transactions: {
    all: { vote: false, failed: false, accountInclude: [], accountExclude: [], accountRequired: [] },
  },
  transactionsStatus: {},
  blocks: {},
  blocksMeta: {},
  entry: {},
  commitment: CommitmentLevel.PROCESSED,
  accountsDataSlice: [],
});

grpcurl \
  -H 'x-token: sk_your_api_key' \
  -d '{"transactions":{"all":{"vote":false,"failed":false}},"commitment":"PROCESSED"}' \
  grpc.raze.bot:443 geyser.Geyser/Subscribe

Update types

The SubscribeRequest accepts the standard Yellowstone filter maps; set the ones you need and leave the rest empty:

Filter	Streams	Status
`accounts`	Account writes, by `account` / `owner`	✅ served
`slots`	Slot status updates	✅ served
`transactions`	Full transactions (`accountInclude` / `accountExclude` / `accountRequired`, `vote`, `failed`)	✅ served
`transactionsStatus`	Transaction status only (lighter than full `transactions`)	✅ served — `vote` / `failed` only, see below
`blocksMeta`	Block metadata (no transactions)	✅ served
`entry`	Entries (PoH ticks)	✅ served
`blocks`	Full blocks	⛔ not served — the request is rejected with `UNIMPLEMENTED`, never silently ignored

Two limits worth knowing before you write the request, because both are answered with an explicit error rather than partial data:

transactionsStatus carries no account keys (slot, signature, isVote, index, err), so accountInclude / accountExclude / accountRequired / signature cannot be honoured on that map and are rejected. Use transactions when you need account-level predicates.
blocks requires a full-block subscription upstream, which this endpoint does not carry. Use blocksMeta plus transactions (or entry).

fromSlot (replay) is not supported here: the subscription is declined rather than silently served live-from-now.

commitment is currently accepted and not applied: the merged feed is a deduplicated union delivered at processed speed, and every subscriber receives updates as they arrive. Do not rely on CONFIRMED / FINALIZED to delay or filter what you receive — use the slots stream to track commitment transitions yourself. Account-data predicates (memcmp, datasize, tokenAccountState, lamports) are likewise parsed but not applied today.

Transactions cost roughly 10× the bandwidth of account updates — scope your filters (accountInclude, accountRequired) as tightly as possible to keep latency low.

Streaming API

gRPC (Yellowstone)

Code Snippets

gRPC (Yellowstone)

Overview

Authentication

Update types

​Overview

​Authentication

​Subscribe

​Update types

Overview

Authentication

Subscribe

Update types