Refs #46
PR: feat/21-mempool-monitor
File: crates/charon-scanner/src/mempool.rs
Function: MempoolMonitor::run_once
Problem
MempoolMonitor::run_once calls subscribe_pending_transactions() on the provider stored at construction time. On all public BSC RPC endpoints (Binance public WS, Ankr, Allnodes, QuickNode shared tier) eth_subscribe for newPendingTransactions is either disabled outright or returns only transactions from that node's local pool, not the global mempool. The PR's stated design goal of a ~3 s one-block head start is only achievable with a paid MEV-streaming service (bloxroute, blocknative) or a self-hosted BSC geth node with the full txpool exposed.
The current implementation has no startup check that the subscription is actually delivering data, no config key to declare which endpoint type is in use, and no operational documentation warning the operator that the default BNB_WS_URL from config/default.toml will not work for this feature. An operator deploying on any public endpoint will observe zero OracleUpdate events and zero pre-signs with no error or warning to diagnose the root cause.
Risk
The central feature of this PR is silently non-functional on the standard deployment path documented in the repo. No alert, no metric, no startup failure. Operators may believe the bot is monitoring the mempool when it is not.
Required fix
- Add a config key (e.g. mempool_rpc_type = "bloxroute" | "self-hosted" | "public") and emit a startup warn! or bail! when public is selected.
- Add a check in run_once: if no pending tx arrives within N seconds of subscription establishment, emit a warn! with diagnosis.
- Document the required endpoint type in rustdoc on MempoolMonitor.
- Open a tracking issue for MEV-stream integration and reference it from the module comment.
Refs #46
PR: feat/21-mempool-monitor
File: crates/charon-scanner/src/mempool.rs
Function: MempoolMonitor::run_once
Problem
MempoolMonitor::run_once calls subscribe_pending_transactions() on the provider stored at construction time. On all public BSC RPC endpoints (Binance public WS, Ankr, Allnodes, QuickNode shared tier) eth_subscribe for newPendingTransactions is either disabled outright or returns only transactions from that node's local pool, not the global mempool. The PR's stated design goal of a ~3 s one-block head start is only achievable with a paid MEV-streaming service (bloxroute, blocknative) or a self-hosted BSC geth node with the full txpool exposed.
The current implementation has no startup check that the subscription is actually delivering data, no config key to declare which endpoint type is in use, and no operational documentation warning the operator that the default BNB_WS_URL from config/default.toml will not work for this feature. An operator deploying on any public endpoint will observe zero OracleUpdate events and zero pre-signs with no error or warning to diagnose the root cause.
Risk
The central feature of this PR is silently non-functional on the standard deployment path documented in the repo. No alert, no metric, no startup failure. Operators may believe the bot is monitoring the mempool when it is not.
Required fix