Skip to main content
Base offers two structural advantages for trading agents: Flashblocks (200ms preconfirmed block state, 10× faster than the 2-second block) and an exposed L1/L2 fee structure that enables explicit cost-vs-speed tradeoffs. This page covers only what is unique to Base — general EVM execution patterns are in the Ethereum documentation, and Base’s RPC methods are in the JSON-RPC API Reference and Flashblocks API Reference.

Execution patterns

Use the preconf endpoint for all reads and submissions

Always connect to mainnet-preconf.base.org (or sepolia-preconf.base.org for testnet) rather than the standard endpoint. This is the only way to access Flashblocks pending state, preconfirmed transaction streams, and base_transactionStatus. See Flashblocks endpoints for the full endpoint list including production provider options.

Simulate against preconfirmed state before signing

Call eth_simulateV1 against the preconf endpoint with "blockStateCalls" targeting the pending block before signing any transaction. This catches reverts against current Flashblocks state rather than the last sealed block — which may be up to 2 seconds stale by the time your transaction lands.

Poll base_transactionStatus instead of blocking on a receipt

After submission, base_transactionStatus returns preconfirmed inclusion status within a single Flashblock interval (~200ms). Blocking on eth_getTransactionReceipt waits for a full sealed block (up to 2 seconds). For latency-sensitive strategies, poll base_transactionStatus first and only fall back to the receipt for finality confirmation.

Fee calibration

L2 priority fee heuristics

Use eth_feeHistory over the last 5–10 blocks with reward percentiles [50, 90]:
  • 50th percentile reward — standard inclusion within 1–3 Flashblocks
  • 90th percentile reward — fast inclusion within the next Flashblock
  • maxFeePerGas — set to nextBaseFee * 2 + maxPriorityFeePerGas to survive base fee increases across multiple blocks without overpaying

L1 fee decision rule

Before signing, estimate the L1 cost via the GasPriceOracle. If the ratio below exceeds 0.8 and trade size is small, the L1 fee dominates total cost — consider deferring until Ethereum congestion subsides:
l1FeeUpperBound / (gasLimit × maxFeePerGas + l1FeeUpperBound) > 0.8

Base-specific failure modes

Most transaction errors are standard EVM. These are the Base-specific cases that require different handling:
FailureWhat it meansWhat to do
replacement transaction underpricedReplacing a pending tx requires ≥10% higher maxFeePerGas and maxPriorityFeePerGasIncrease both by ≥10%, resubmit with same nonce
DA throttling (no error code returned)Sequencer is rate-limiting L2 throughput to manage L1 data availability costsFee-bumping does not resolve this — wait for the throttle to lift
For the full error taxonomy, see Troubleshooting Transactions. Nonce for concurrent submissions: Always fetch with eth_getTransactionCount(address, "pending"). For parallel submissions, fetch once and increment locally — fetching fresh per call returns the same value for all concurrent requests.

Strategy signals

Base exposes data that most chains don’t provide at this resolution. The table maps each Base-specific signal to the class of opportunity it enables.
SignalHow to accessOpportunity category
Preconfirmed pending block state (200ms early)eth_getBlockByNumber("pending") on preconf endpointDetect price impact before block seals; act on state changes visible to no one else
Preconfirmed transaction streameth_subscribe("newFlashblockTransactions")First-mover on large trades entering the block
Preconfirmed logseth_subscribe("pendingLogs", { address, topics })Detect liquidation thresholds, pool price events, oracle updates before finality
Fee spike detectioneth_feeHistory trend over last 5 blocksIdentify congestion onset; adjust routing or pause/resume based on cost
L1 base fee trendGasPriceOracle.l1BaseFee() polled over timeTime submissions to minimize L1 data cost; small trades become viable when L1 fee drops
Block gas utilizationgasUsedRatio from eth_feeHistoryPredict upcoming base fee increases; calibrate urgency
The Flashblocks advantage: Most chains expose a pool of pending transactions with uncertain ordering. On Base, the Flashblocks endpoint gives agents a deterministic, ordered view of the next 200ms of chain state before it finalizes. This is an information edge that does not exist on chains with mempool-only visibility. On emerging edges: Execution speed and fee optimization are table stakes. The more durable edge for LLM-based agents is likely in interpreting why chain state is changing — correlating onchain signals (large pending swaps, oracle updates, liquidation proximity) with offchain context faster than any rule-based system can. The signals above are the raw inputs; the synthesis is where the edge lives.