solana-e2e-benchmark is a Rust toolkit for testing and inspecting the end-to-end latency of Solana transactions. It sends a constructed transaction through a gRPC transaction sender, monitors transactions involving a configured account through Yellowstone gRPC, and can detect the submitted transaction from received Solana shreds.
The repository includes two binaries:
BotSimulatorruns repeated command-line benchmark cases and logs transaction events.BotWebServerprovides a browser interface for sending test transactions and viewing client, construction, send, and Yellowstone gRPC timestamps.
Important
Transaction construction is intentionally left for the user to implement in src/common/tx_constructor.rs. The repository will not run a benchmark until construct_tx() returns a valid transaction signature and serialized transaction.
The command-line simulator follows this flow:
- Subscribe to Yellowstone gRPC transaction updates at
processedcommitment, filtered byconcerned_account. - Connect to the configured transaction sender over gRPC and perform a health check.
- Start an
unshredprocessor on the configured UDP listen address. - Construct a transaction and record its signature for shred matching.
- Submit the serialized transaction through the sender's
SendTransactionRPC infastmode. - Log account-filtered transaction updates from Yellowstone gRPC and matching transaction signatures detected in received shreds.
BotSimulator currently runs 100 test cases with a five-second interval after an initial startup wait. The program emits timestamped logs for analysis; it does not calculate an aggregate latency report.
- Rust and Cargo
- A Protocol Buffers compiler (
protoc), used bybuild.rs - A Yellowstone gRPC endpoint
- A compatible transaction-sender gRPC endpoint and API key
- A UDP shred source for shred-based observation when using
BotSimulator - A Solana signing account suitable for the transaction logic you implement
git clone https://github.com/BlockRazorinc/solana-e2e-benchmark.git
cd solana-e2e-benchmarkImplement construct_tx() in:
src/common/tx_constructor.rs
The function must return:
(signature, serialized_transaction)Both values are strings. The signing account used by the constructed transaction must match the account supplied through --concerned_account, so the Yellowstone gRPC account filter can observe the transaction.
Keep private keys and API credentials out of the repository.
cargo build --releaseThe release binaries are generated at:
target/release/BotSimulator
target/release/BotWebServer
./target/release/BotSimulator \
--yellow_stone_grpc_endpoint <YELLOWSTONE_GRPC_ENDPOINT> \
--shred_listen_addr <SHRED_LISTEN_ADDRESS> \
--sender_grpc_endpoint <TRANSACTION_SENDER_GRPC_ENDPOINT> \
--sender_grpc_auth_key <TRANSACTION_SENDER_API_KEY> \
--concerned_account <SOLANA_ACCOUNT_ADDRESS>| Option | Purpose | Default |
|---|---|---|
--yellow_stone_grpc_endpoint |
Yellowstone gRPC endpoint used to subscribe to processed transaction updates | http://127.0.0.1:10001 |
--shred_listen_addr |
Local address on which the unshred processor receives shreds | 0.0.0.0:20000 |
--sender_grpc_endpoint |
gRPC endpoint used to submit transactions | http://newyork.solana-grpc.blockrazor.xyz:80 |
--sender_grpc_auth_key |
API key added to sender gRPC requests as apikey metadata |
# |
--concerned_account |
Solana account used by the Yellowstone gRPC transaction filter | # |
Replace placeholder defaults such as # with valid values before running the benchmark.
Start the browser-based transaction test interface with:
./target/release/BotWebServer \
--web_port <WEB_PORT> \
--yellow_stone_grpc_endpoint <YELLOWSTONE_GRPC_ENDPOINT> \
--sender_grpc_endpoint <TRANSACTION_SENDER_GRPC_ENDPOINT> \
--sender_grpc_auth_key <TRANSACTION_SENDER_API_KEY> \
--concerned_account <SOLANA_ACCOUNT_ADDRESS>Then open:
http://localhost:<WEB_PORT>
The default web port is 3000. The page can submit one request or automatically run 2, 5, 10, 15, 20, 33, or 100 requests, waiting five seconds between automatic requests.
For each request, the interface displays:
- Client request and response timestamps
- Transaction construction start and end timestamps
- Transaction send start and end timestamps
- The time at which the matching signature is observed through Yellowstone gRPC
The web server exposes the transaction trigger at:
GET /api/send_tx
The simulator logs key events including:
- Transaction construction start and completion
- The generated transaction signature
- gRPC transaction submission start and response
- Matching transaction receipt through the shred processor
- Yellowstone gRPC transaction updates with server-provided creation timestamps
Use these events to inspect the transaction path and derive the latency measurements relevant to your environment. Because the current implementation logs observations instead of producing percentile statistics, any aggregation or comparison must be performed separately.
.
├── proto/server.proto # Transaction-sender gRPC service definition
├── src/BotSimulator/main.rs # Repeated CLI benchmark runner
├── src/BotWebServer/main.rs # Axum web interface and timing response
└── src/common/
├── trader_simulator.rs # Coordinates construction and submission
├── tx_constructor.rs # User-supplied transaction construction
├── tx_sender.rs # Sender gRPC client
├── types.rs # Command-line options and defaults
├── unshred_handler.rs # Matches transaction signatures from shreds
├── utils.rs # Timestamp formatting
└── yellow_stone_grpc_client.rs # Yellowstone gRPC subscription client
BotSimulatoruses the transaction signature returned byconstruct_tx()to match shred events.- The Yellowstone gRPC subscription includes transactions involving
concerned_accountand usesprocessedcommitment. - Sender requests use
mode: "fast", no safe window, andrevertProtection: falsein the current implementation. BotWebServerreports Yellowstone gRPC observation timing but does not start the shred listener.