RPC and confirmation requirements
Follow IMPORTANT and configure the following provider behavior before bidding.
Ethereum coherent reads
Section titled “Ethereum coherent reads”Supply a primary and at least one secondary read endpoint. Providers must serve mainnet and match the configured runtime hash. Required methods—eth_call, eth_getBalance, eth_getCode, and eth_getTransactionCount—must support EIP-1898:
{"blockHash": "0x…", "requireCanonical": true}Each operation starts with the freshest eligible provider. Fallback must serve the same canonical block, including its hash, height, timestamp, and base fee. Failed partial reads are discarded; completed reverts and invariant failures stop the operation. This is provider failover, not quorum voting.
Example limits reject blocks over 60 seconds old or 15 seconds ahead. A provider height spread above two blocks, or conflicting hashes at one height, stops new exposure while committed recovery continues.
Private Ethereum submission
Section titled “Private Ethereum submission”Configure at least two explicit private submission entries, including one that also serves reads for sensitive simulations. Signed transactions and recovery rebroadcasts use only this list.
Providers must protect delivery from public-mempool/searcher exposure and include otherwise valid reverting transactions. Revert filtering can leave a nonce unconsumed and block later obligations. The solver has no fee-bump or same-nonce cancellation path.
After an ambiguous response, reconcile receipts and rebroadcast the persisted signed bytes. A submission acknowledgement is not inclusion.
Confirmations and auction timing
Section titled “Confirmations and auction timing”The supported model permits replacement of the current Ethereum tip. Minimum/default two confirmations count inclusion plus one successor; deeper reorganizations are outside that model.
A fresh bid requires exactly one canonical successor to creation, unchanged terms, and more than 12 seconds before auction end on both chain and host clocks. Before first Monero relay, the award must reach configured depth and leave the required payment time. Increasing confirmation depth requires reviewing timing reserves.
Monero services
Section titled “Monero services”Use one trusted, synchronized, non-bootstrap mainnet daemon in unrestricted mode. Configure at least two fallback propagation daemons on distinct hosts; their observations and relay support do not supply trusted witness facts.
The example admits a tip skew of at most three blocks. Wallet RPC must be authenticated and loopback-only; its configured daemon handles first relay. Fallback failures after commitment must not suppress recovery.