Overview
Deterministic block placement lets searchers and protocols execute their bundles after specific addresses have changed state in the block. The builder monitors the watched addresses during block construction and places the bundle once all of them have been touched at least once.
This is useful when your strategy depends on reacting to state changes made by other transactions — for example, executing after a DEX pool rebalances, after an oracle updates, or after a liquidation modifies a lending protocol's state.
How It Works
The searcher submits a bundle via
eth_sendDeterministicBundlewith a list of watched addresses and a target block.The builder constructs the block with regular orderflow.
As transactions execute, the builder tracks which watched addresses have been touched.
Once all watched addresses have been touched at least once, the builder attempts to place the bundle.
If the bundle execution fails, the builder may reattempt placement after additional state changes to the watched addresses.
If none of the watched addresses are modified by other transactions, the bundle is not included in the block.
Use Cases
DEX arbitrage — execute after a pool's reserves change from a swap or liquidity event
Liquidations — act after a lending protocol's state is updated by a price oracle or repayment
Protocol settlement — settle after dependent contracts have been modified by other transactions
State-dependent strategies — any strategy that needs to execute with knowledge that specific addresses have been touched
Compatibility
Deterministic bundles use the same base parameter format as eth_sendBundle — including replacementUuid, revertingTxHashes, and refund parameters — with an additional required watchedAddresses field. Cancel with eth_cancelBundle.
Rate Limits
Standard order flow rate limits apply. Contact the Eureka team to request higher limits for production integrations.
API Methods
Submit a bundle placed after watched addresses change state
All requests are sent as JSON-RPC 2.0 POST to:
Last updated