We run a relay that depends on revert protection: a transaction that would revert must never be included. We test every path on a testnet before mainnet, and on Unichain we can’t, because eth_sendBundle is only reachable on mainnet.
The same requests, sent on 2026-10-23 to each public endpoint:
mainnet.unichain.org
eth_sendBundle {"txs": []} → -32602 "bundle has no txs"
eth_sendBundle {"txs": ["0x02"]} → -32602 "typed transaction too short"
sepolia.unichain.org
eth_sendBundle {"txs": []} → -32601 "rpc method is not whitelisted"
eth_sendBundle {"txs": ["0x02"]} → -32601 "rpc method is not whitelisted"
web3_clientVersion → "op-reth/v2.7.0-rc.3-e45aad88/x86_64-linux"
Third-party Sepolia RPCs don’t help either: publicnode and dRPC answer “method not found”. The docs say to use the mainnet endpoint for bundles, so this may be deliberate. But it means the first time anyone can check that revert protection holds for their transactions is on mainnet.
- Could
eth_sendBundlebe whitelisted onsepolia.unichain.org, or a testnet bundle endpoint published? Is the Sepolia builder running with revert protection enabled at all? - Is a bundle’s transaction kept out of p2p gossip and out of rollup-boost’s fallback block? If it reaches the default execution client’s pool, a fallback block (builder lagging or down) could include it reverting. Is that excluded by configuration?