> For the complete documentation index, see [llms.txt](https://docs.blockrazor.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blockrazor.io/get-started/use-cases/trading-bot.md). # Trading Bot In onchain trading, a Trading Bot's competitiveness depends not only on its strategy, but also on two critical dimensions of speed: 1. **Signal monitoring speed**: How early the bot can detect a new pool, market-opening event, or target-wallet transaction. 2. **Transaction submission speed**: How quickly the bot can deliver a transaction to a Leader, Builder, Validator, or Sequencer. The complete transaction path is as follows: > Onchain event → Signal monitoring and parsing → Strategy evaluation → Transaction construction and signing → Transaction submission → Ordering node receives the transaction → Onchain inclusion Signal monitoring determines when a bot can act, while transaction submission determines when its transaction reaches the chain. Latency at either stage can eliminate the strategy's original advantage. ### Typical Trading Bot Scenarios #### **Sniper** A Sniper Bot monitors new token deployments, new liquidity pools, market-opening transactions, or other predefined events. Once a target signal appears, it immediately constructs and submits a transaction. Its primary objective is to discover trading opportunities earlier, enter the target block or slot, and secure a more favorable ordering position. #### **Copy Trading** A Copy Trading Bot monitors the buys, sells, or position changes of a designated Leader wallet. It then constructs a Follower transaction according to predefined amounts, ratios, and strategy rules. Its primary objective is to reduce the inclusion-time gap between the Leader and Follower and minimize their execution-price difference. Sniper and Copy Trading Bots monitor different targets: the former focuses on new pools, market openings, and contract events, while the latter focuses on designated wallet activity. However, both depend on the same underlying path: receiving signals, parsing signals, constructing transactions, and submitting them quickly. ### Trading Bot Pain Points #### **Pain Point 1: Slow Signal Monitoring** **Waiting for complete blocks delays signals** Standard RPC or WebSocket services often deliver transaction data only after a node has received, processed, or even reconstructed a block. This can mean: * A competitor has already submitted a transaction when a Sniper Bot detects a new pool. * The market price has already changed when a Copy Trading Bot detects the Leader's transaction. * The original opportunity decays while the bot waits for data. **Public nodes introduce longer data paths** Public nodes may introduce cross-region transmission, multiple proxy layers, shared-resource queues, rate limits during peak traffic, and connection jitter. Even a difference of tens of milliseconds can directly affect the final execution position in competitive Sniper and Copy Trading scenarios. **A single data source provides limited signal coverage** On chains that support Pending Transactions, public and private transactions may propagate through different paths: * Public Mempool mainly covers publicly broadcast Pending Transactions. * Private transactions may not appear in the Public Mempool. * Confirmed onchain signals offer greater certainty but arrive later. A Trading Bot should select Pending data, private order flow, or block data according to its target chain and strategy. #### **Pain Point 2: Slow Transaction Submission** Receiving a signal first does not guarantee execution first. After strategy evaluation, a transaction may still pass through a public RPC, proxy layers, cross-region networks, and intermediate relay nodes. These stages consume the lead gained during signal monitoring and can cause: * A Sniper Bot to miss the target block or slot. * A Copy Trading Bot to land several blocks behind the Leader. * A Follower to receive a materially worse execution price than the Leader. * A transaction to fail because the market state has changed. The destination that must receive a transaction quickly differs by chain:
ChainTransaction DestinationPrimary Speed Consideration
SolanaCurrent and upcoming LeadersLeader routing and SWQoS transmission
EthereumBuilder / ValidatorFaster entry into propagation and block-building paths
BSCBuilder / ValidatorReaching the target block's processing window in time
BaseSequencerShortening the transaction path to the Sequencer
Robinhood ChainOfficial SequencerArrival time under FCFS ordering
Note: Robinhood Chain uses First-Come, First-Served ordering. Transaction order depends on arrival time at the Sequencer, and a higher fee cannot move a transaction ahead of one that arrived earlier. The submission path is therefore a direct competitive variable. ### Recommended Services BlockRazor provides low-latency infrastructure for Sniper and Copy Trading Bots across both signal monitoring and transaction submission. #### Signal Monitoring Services
ChainRecommended ServicesDifferences and Selection Guidance
SolanaShred Stream
Geyser Stream		Shred Stream transmits shreds before complete block reconstruction; Geyser Stream provides structured transaction and account data.
EthereumPublic Mempool
Block Stream		Public Mempool monitors publicly broadcast Pending Transactions; Block Stream monitors confirmed onchain signals.
BSCPublic Mempool
Private Mempool
Block Stream		Public and Private Mempool complement each other to provide earlier Pending signals; Block Stream monitors confirmed onchain signals.
BaseFlashBlock Stream
Block Stream		FlashBlock Stream provides preconfirmation data before a complete block is formed; Block Stream provides complete block data.
Robinhood ChainSequencer FeedProximity-based access and optimized transmission paths provide faster and more stable delivery of block data pushed by the Sequencer.
> Sniper and Copy Trading Bots can use the same monitoring services. The difference lies in the signals each bot filters and parses. #### Transaction Submission Services
ChainRecommended ServicesDifferences and Selection Guidance
SolanaSend TransactionUses a global high-performance network and SWQoS paths to deliver transactions quickly to current and upcoming Leaders.
EthereumBroadcast TxOptimized for maximum broadcast speed but does not provide MEV protection. Use BlockRazor RPC when MEV protection is required.
BSC

Broadcast Tx

Fast Submit

Broadcast Tx provides maximum transaction broadcast speed but no MEV protection; use BlockRazor RPC when MEV protection is required. Fast Submit uses a dedicated submission entry point and optimized cross-region paths to shorten the route to the BlockRazor Builder.
Baseeth_sendRawTransactionProvides standardized, multi-region transaction submission for quickly delivering signed transactions to the Base Sequencer.
Robinhood Chaineth_sendRawTransactionUses multi-region entry points and optimized routing to reach the official FCFS Sequencer faster.
> Signal monitoring services determine when a bot can act. Transaction submission services determine when the transaction reaches the ordering node. Prefer a regional endpoint close to the bot's deployment location. ### Benchmark BlockRazor has published the following relevant performance tests:
ChainServiceBenchmarkWhat It Measures
SolanaShred StreamSolana Shred Stream BenchmarkCompares the first-arrival rate and arrival-time difference of BlockRazor and Jito shreds across multiple regions.
SolanaSend TransactionBenchmarking Solana Send Transaction ServiceUses consistent Tips, Priority Fees, and Durable Nonce transactions to compare transaction races over SWQoS paths.
BSCFast SubmitBSC Fast Submit BenchmarkMeasures submission-latency improvements from fewer proxies, network hops, and optimized cross-region paths.
BaseRPC
Block Stream
FlashBlock Stream		Base BenchmarkCompares transaction ordering positions and the data-arrival latency of Block Stream and FlashBlock Stream.
Robinhood ChainSequencer FeedSequencer Feed BenchmarkCompares first-arrival rates and latency distributions between BlockRazor and the official Feed across three AWS Ohio Availability Zones.
Robinhood ChainRobinhood Chain RPCRobinhood Chain RPC BenchmarkUses same-nonce transactions to compare the competitive inclusion rates of BlockRazor RPC and the official RPC across multiple regions.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.blockrazor.io/get-started/use-cases/trading-bot.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.