Gas and fees

The numbers on this page come from STATUS.md section 2 (probes on 2026-09-15 and 2026-09-16). Sample counts were not logged; treat each as a single reading. They are observations, not a model. The source of record is STATUS.md in the BLCK repo.

Gas token

ETH. There is no native token. The docs say "Robinhood Chain uses ETH as its native gas token", and L1 SequencerInbox.isUsingFeeToken() returns false. You fund a searcher wallet with ETH and nothing else.

L2 basefee

The L2 basefee has a floor of 0.02 gwei. ArbGasInfo.getMinimumGasPrice() returned 20000000 wei.

Observed mainnet basefee on 2026-09-15: about 0.066 gwei. A single reading, not an average. It says the basefee was a bit over three times the floor at that time, and nothing else.

TODO (blck-probe): log basefee per block over a window and commit the series under benchmarks/data with region and timestamp.

L1 data component

Every L2 transaction also pays for its share of the data posted to Ethereum. Robinhood Chain posts that data as EIP-4844 blobs. Nitro exposes an L1 basefee estimate through ArbGasInfo.getL1BaseFeeEstimate(). Whether the L1 charge on mainnet is derived from that value is open (Q6).

Here is the open problem. That call returns 0 on mainnet, which is unexplained (Q6 in STATUS.md). Candidates named there: a blob-era pricing path or an L1 fee subsidy. Neither is confirmed.

Until this is resolved:

• Do not model the L1 component from the precompile alone on mainnet.
• Compare effectiveGasPrice and the total fee paid across real receipts against what the precompile implies.
• Expect blck-sim's gas model to carry this as an explicit unknown.

If you know the answer, or can show it from a receipt, that is worth a pull request.

Priority fee has no ordering effect

eth_maxPriorityFeePerGas returns 0. The docs: "Priority gas auctions do not exist here; consequently, increasing your fee will not shift your transaction ahead of others already in the queue."

Set maxPriorityFeePerGas to 0. Setting it higher does not move you. See 02 for the rest of what does not exist here.

What to set for maxFeePerGas in a latency race

Price does not buy position. The only job of maxFeePerGas on this chain is to make sure your transaction never fails on fee. Sequencer-edge engineering treats the fee cap as a correctness setting, not a lever.

If basefee at inclusion exceeds your cap the transaction is rejected before it runs, so a tight cap loses the race on a transaction that never executed.

So set the cap high relative to the basefee you last read. The floor is 0.02 gwei and the one mainnet observation was 0.066 gwei, so the absolute numbers are small. Under standard EIP-1559 arithmetic, with a priority fee of 0, you are charged the basefee at inclusion, not your cap. BLCK has not yet confirmed on this chain that the amount charged matches that arithmetic exactly. TODO (blck-probe send mode): compare effectiveGasPrice in mainnet receipts against the cap and the block basefee, and record it.

A practical rule until then: read the basefee, multiply by a generous factor, and re-read on a timer rather than per transaction. Do not spend a round trip on eth_gasPrice in the hot path. That round trip is the latency you are trying to remove.

Gas limit is a separate setting and a separate failure mode. Simulate first (blck-sim, Milestone 3) and set the limit from the simulation with headroom. Running out of gas is a revert like any other, and reverts still pay.

Gas as the cost of spam strategies

With no auction and no mempool, one obvious strategy is volume: fire on every trigger, fire several variants, fire early and let the losers revert. That works up to the point where the gas bill exceeds what the winners make.

Every reverted transaction pays for the gas it consumed up to the revert. At a 0.02 gwei floor with ETH as gas, the per-transaction cost is small. It is not zero, and it scales with how many transactions you send. Budget reverts as a line item. Track them per strategy. A strategy that is profitable per fill can be unprofitable per attempt.

Two more things:

• Nitro produces blocks only when there are transactions. Your volume makes blocks. Block count on this chain is partly a function of what searchers do.
• The L1 data component applies per transaction and is currently unexplained on mainnet. If receipts show it is non-zero, volume is more expensive than the L2 basefee alone suggests.

Summary