First-come, first-served: pricing transactions on Robinhood Chain

Robinhood Chain's documentation says it in one sentence: "Priority gas auctions do not exist here; consequently, increasing your fee will not shift your transaction ahead of others already in the queue." On 2026-10-13 we checked what the fee methods report on the live network. eth_maxPriorityFeePerGas returned 0x0. eth_feeHistory over five blocks returned 0x0 for the 25th, 50th and 75th reward percentiles in every block. The base fee was 0.020466 gwei, and the chain's own floor, read from the ArbGasInfo precompile, was 0.02 gwei.

So the job of a fee policy here is different from Ethereum's. You are not bidding for position; you are making sure the transaction is valid at the base fee when it reaches the sequencer, with a gas limit that covers both halves of the fee. This post shows the responses, where the L1 data fee goes, and a submission policy for bots that matches a first-come, first-served queue. For the cross-chain view of tips, see priority fees on Solana, Ethereum and other chains; this one stays on Robinhood Chain.

What the sequencer does with your fee fields

An EIP-1559 transaction carries maxFeePerGas and maxPriorityFeePerGas. On Ethereum the tip goes to the block producer, who orders by it. Robinhood Chain is an Arbitrum Nitro chain whose sequencer orders by arrival time, per the official Differences from Ethereum page.

Arbitrum's gas and fees deep dive adds the mechanism. A tip does anything only if two settings are both on: tip collection (setCollectTips, which "ships disabled") and an ordering policy that sorts by the priority fee. For a first-come, first-served chain that does not collect tips, the documented effect of a tip is "Nothing. Arrival time sets the order, and the sender pays the basefee." Robinhood Chain's pages state the ordering but do not say whether tip collection is enabled, so we do not claim either way. The practical rule holds regardless: with arrival-time ordering a tip cannot buy position, so set maxPriorityFeePerGas to 0x0 — which is what the network's own estimator returns.

Our eth_maxPriorityFeePerGas reference puts it the same way: pay the field "for compatibility with wallets and tooling that expect the field, not to buy position".

What the fee methods returned on 2026-10-13

All calls below went to Robinhood Chain's official public RPC between 12:43 and 12:47 UTC on 2026-10-13. Values are wei unless marked.

And the eth_feeHistory call, five blocks back from latest with three percentiles:

{"jsonrpc":"2.0","id":1,"method":"eth_feeHistory","params":["0x5","latest",[25,50,75]]}

{"jsonrpc":"2.0","id":1,"result":{
  "oldestBlock":"0x537764c",
  "reward":[["0x0","0x0","0x0"],["0x0","0x0","0x0"],["0x0","0x0","0x0"],["0x0","0x0","0x0"],["0x0","0x0","0x0"]],
  "baseFeePerGas":["0x13301c0","0x1331160","0x1342aa0","0x136e9c0","0x1384950","0x1312d00"],
  "gasUsedRatio":[1,1,1,1,0.198378]}}

Two readings matter. First, every reward is zero: nobody in those blocks paid a tip at any of the three percentiles, which is what you expect when tips do not buy order. Second, the base fee moved — from 20,120,000 to 20,466,000 wei across five blocks, then back to the 20,000,000 floor for the next block. Small in absolute terms, but it means a maxFeePerGas pinned exactly to the current base fee can fail a block later. We do not interpret gasUsedRatio here: Arbitrum's deep dive describes a base fee that reacts to a backlog rather than to Ethereum's per-block target, and we have not verified what the field measures on this chain.

At these numbers an empty transfer cost 21,225 × 20,466,000 wei, about 0.00000043 ETH. That arithmetic is the whole fee — there is no separate L1 invoice.

Where the fee goes: L2 execution and L1 data

The official Gas & Fees page lists two components: the L2 execution fee ("gas used × L2 gas price") and the L1 data fee for posting your calldata to Ethereum, which "varies with Ethereum network congestion and is proportional to the size of your transaction's calldata". Both are "bundled into the gas your transaction pays". Arbitrum's deep dive explains how: the L1 cost is divided by the current L2 base fee and charged as extra gas units, the "poster fee".

 signer (wallet, bot)
   │  signed tx: maxFeePerGas, maxPriorityFeePerGas (0), gasLimit from eth_estimateGas
   ▼
 RPC endpoint ──► sequencer queue ── ordered by arrival time; the tip is not a sort key
                       │
                       ▼
                 L2 block ── gasUsed = L2 execution gas
                       │                + L1 data cost ÷ L2 base fee   (poster fee, in gas units)
                       │      you pay gasUsed × L2 base fee
                       ▼
                 batch posted to Ethereum ── ordering fixed
                       │
                       ▼
                 Ethereum finality ── about 13 minutes after posting

Two consequences for code. The gas limit from eth_estimateGas already includes the L1 part — Arbitrum's docs say the estimate times the L2 gas price "tells you how much total ETH is required" — and that "the value returned by eth_estimateGas will change over time" as Ethereum calldata prices move. So estimate per transaction, close to signing, and keep a modest margin. And calldata size is the lever you control: the official page recommends packing arguments tightly and batching.

At the moment we looked, the L1 component was zero: gasEstimateComponents reported 0 gas for L1 and getL1BaseFeeEstimate reported 0. Do not build on that. The official page describes the L1 fee as variable, and the pricing that produced a zero at 12:47 UTC is not a published constant. A fee model that assumes zero will under-provision the gas limit the first time Ethereum gets busy.

A submission policy for bots

On a first-come, first-served sequencer the variables you control are the validity of the transaction and when it arrives. Our fast submission reference and wallet backend guide give the rules we apply; condensed:

1. Tip zero, cap with headroom. maxPriorityFeePerGas = 0. Set maxFeePerGas to a multiple of the current base fee. Under Arbitrum's model you pay the base fee, not your cap, so the headroom protects the transaction without costing anything when the base fee stays flat.
2. Prepare before the critical path. Nonce, gas estimate and signature should exist before the trigger. The send reference: "Keep submission connections warm and prepare/sign before the critical path."
3. Submit once. A replacement with a higher tip cannot jump ahead of the original in an arrival-ordered queue, and resending identical bytes adds nothing. Persist the hash before the first send.
4. The hash is a handle, the receipt is the outcome. "A returned hash means the request was routed, not that the transaction was included." Poll the receipt; a null receipt means "not yet", not "failed".
5. Retry transport, not rejections. Retry a dropped connection; do not retry a deterministic validation error with the same bytes.

If the transaction only makes sense while some state still holds — a price, a block window, a storage slot — use conditional submission instead of racing a replacement. It separates two failures that look alike: a malformed options object comes back immediately as -32602 invalid conditional options, while conditions that no longer hold are "not returned as an error at all" — the transaction just never gets a receipt, and you stop waiting after your own blockNumberMax or timestampMax.

The submission budget on Triport

Submissions and reads draw on separate budgets, so a busy read loop does not starve sends. Per the plan matrix, as published on the Robinhood Chain RPC endpoint page and in the method references:

Both eth_sendRawTransaction and eth_sendRawTransactionConditional count against the send budget; eth_estimateGas, eth_gasPrice and eth_feeHistory count as reads. A bot that resubmits on every tick spends its send budget on transactions that cannot move up the queue — one more reason for submit-once.

When this is the wrong approach

• You submit to several chains from one fee module. Keep the zero-tip rule specific to Robinhood Chain. On Ethereum and on chains that sort by priority fee the same rule will leave you stuck behind every bidder.
• You need a transaction to land in a particular block. Neither fees nor arrival order guarantee a block. Use conditional bounds to make it fail safely outside the window, and accept that inclusion is the sequencer's decision.
• Your problem is cost, not order. If fees matter at scale, the lever is calldata size, not the fee fields. Measure gas per call before tuning anything else.

Sources

1. Robinhood Chain, Differences from Ethereum — https://docs.robinhood.com/chain/differences-from-ethereum/, read 2026-10-13 (first-come, first-served by sequencer arrival; "Priority gas auctions do not exist here"; ArbGasInfo for gas pricing).
2. Robinhood Chain, Gas & Fees — https://docs.robinhood.com/chain/gas-and-fees/, read 2026-10-13 (L2 execution fee and L1 data fee, bundled into gas; eth_estimateGas accounts for both; reduce calldata).
3. Robinhood Chain, Transaction Finality — https://docs.robinhood.com/chain/transaction-finality/, read 2026-10-13 (posted to Ethereum; Ethereum finality "~13 minutes after posting"). Protocol Contracts — https://docs.robinhood.com/chain/protocol-contracts/, read 2026-10-13 (ArbGasInfo at 0x…6C, NodeInterface at 0x…C8).
4. Arbitrum, Gas and fees — https://docs.arbitrum.io/how-arbitrum-works/deep-dives/gas-and-fees, read 2026-10-13 (tips ignored unless tip collection is enabled; FCFS without tip collection: the sender pays the basefee; poster fee in L2 gas units; eth_estimateGas covers the full fee and changes over time; gas price floor via getMinimumGasPrice).
5. Arbitrum, NodeInterface — https://docs.arbitrum.io/build-decentralized-apps/nodeinterface/reference, read 2026-10-13, and the NodeInterface.sol interface in the OffchainLabs nitro-contracts repository (return order of gasEstimateComponents: gasEstimate, gasEstimateForL1, baseFee, l1BaseFeeEstimate).
6. RPC responses captured from Robinhood Chain's official public RPC on 2026-10-13, 12:43–12:47 UTC: eth_gasPrice 0x1384950; eth_maxPriorityFeePerGas 0x0; eth_feeHistory as shown; ArbGasInfo getMinimumGasPrice 0x1312d00, getL1BaseFeeEstimate 0x0; eth_estimateGas 0x52e9; NodeInterface gasEstimateComponents 0x52e9 / 0x0 / 0x1334fe0 / 0x0.
7. Triport, fast submission, conditional submission, eth_maxPriorityFeePerGas and wallet backend guide. Send and read rates from the plan matrix as published in the Robinhood Chain method references (sustained and short-burst RPS per plan).