No priority auction, no way to pay for position

This page lists what does not exist on Robinhood Chain, what "atomic" means when you cannot group transactions, and what would change if any of that stopped being true. Facts were checked on 2026-09-16. The source of record is STATUS.md in the BLCK repo.

What does not exist

No priority gas auction. The official docs (Differences from Ethereum) say it directly: "Priority gas auctions do not exist here; consequently, increasing your fee will not shift your transaction ahead of others already in the queue."

Priority fee is ignored for ordering. eth_maxPriorityFeePerGas returns 0. You can set a priority fee. It does nothing to your position.

No protocol-level grouping and no payment for placement. The docs describe one ordering rule, arrival time. The only submission method BLCK found is eth_sendRawTransaction on the sequencer endpoint, one signed transaction per call; the timeboost_ and auctioneer_ namespaces are absent. BLCK found no grouped-submission method. There is no payment to the sequencer, or to anyone else, that the protocol honors for placement. The only other way in is the L1 delayed inbox, on a 4-day timer (see 01).

No public mempool. txpool_content, txpool_status, and eth_newPendingTransactionFilter return -32601 on both networks. No public observer sees your transaction before the sequencer orders it, and you see nobody else's. Whatever RPC you submit through sees it first, and so does the sequencer operator.

No way to buy position. Put together: the only thing that determines where you land is when you arrive. No fee, no payment, no intermediary changes that at the protocol level.

What "atomic" means here

If you cannot group transactions, atomicity has to live inside one transaction.

The unit of atomicity on Robinhood Chain is a single contract call. One transaction, one to, one calldata, executing the whole strategy: read the state it needs, swap on venue A, swap on venue B, check the result, revert everything if the check fails. Either every step lands or none of it does. Gas for the work up to the revert is still paid.

Two of your own transactions are a different thing entirely. Nonce ordering guarantees your nonce n is included before your nonce n plus 1. It does not guarantee they are adjacent. Anyone whose transaction reaches the sequencer between yours lands between yours. On a chain that orders by arrival with roughly 100 ms blocks, "between yours" is a real window, not a corner case.

So the rule is short. If two operations must happen together or not at all, they are one call. If step two depends on step one having succeeded with nobody in between, they are one call. The ordering between two of your own transactions is guaranteed only when they are the same transaction.

BLCK's atomic executor (Milestone 3) is this pattern as a Solidity contract with Foundry tests. It is exercised against a fork of mainnet state, so the tests read the real Uniswap v2, v3, and v4 pools without sending anything.

What you give up compared with grouped submission on other chains: you cannot combine transactions from different signers into one unit, and you cannot wrap someone else's transaction with yours. Your atomic unit is only ever your own code.

Timeboost: on Arbitrum One, not here

Timeboost is Arbitrum's express lane auction. It is live on Arbitrum One. Express lane rounds were resolving there on 2026-09-15. It is not enabled on Robinhood Chain. Evidence from a raw feed capture of 789 messages: every message carries blockMetadata: null and the string "timeboost" never appears. Receipts have no timeboosted field. The timeboost_ and auctioneer_ RPC namespaces are absent.

The landscape can change. The ArbitrumDAO has passed a Constitutional AIP to move Arbitrum One to priority gas auctions plus a paid "Fast Feed". Nothing equivalent has been announced for Robinhood Chain, and the docs still say fees cannot buy position (Q3 in STATUS.md). But the parent ecosystem is moving toward paid ordering, and the chain runs the same software.

What BLCK would do if that changed

Say Robinhood enabled Timeboost, or a priority gas auction, tomorrow. Here is what would and would not change.

What stays:

• Arrival time still decides everything the auction does not cover. An auction applies to whatever scope its rules define. Outside that scope the sequencer is still FCFS, and inside it there is still a race to submit the bid.
• Latency measurement, feed decoding, local simulation, and single-call atomic execution are all still required. Nobody bids well on a transaction they cannot simulate or land.

What gets added:

• Bid logic: pricing what a position is worth against what it costs.
• Auction monitoring: round timing, winners, clearing prices, whatever the mechanism exposes.
• A submission path that speaks the auction's protocol alongside the plain sequencer endpoint.
• A rewrite of this page. "No way to buy position" becomes "here is what a position costs".

That is why BLCK calls the discipline sequencer-edge engineering rather than FCFS engineering. The edge is at the sequencer, whatever rule the sequencer applies. An auction layer would be added to the toolkit. It would not replace it.

Third-party private submission layers

At least one exists. Ordo (ordofi.network) runs a private RPC with sealed-bid 200 ms backrun auctions and a searcher SDK. rpc.ordofi.network is the host BLCK saw in public RPC lists; TODO (owner): confirm the private auction host against app.ordofi.network/docs. Ordo is a third party with no disclosed agreement with Robinhood. It is not the sequencer, and the sequencer remains FCFS regardless of what happens inside Ordo's auction.

What that means in practice:

• Ordo's ordering promises are Ordo's, enforced by Ordo, not by the protocol. Anything you route through a third-party RPC is visible to that operator before it reaches the sequencer, and its forwarding behavior is a promise you cannot verify on chain.
• Counterparty trust is part of the trade. You are trusting an intermediary with the transaction and with the information in it.
• There is no official private submission path from Robinhood or from Alchemy (Q14). Ordo is the one BLCK has documented. Others may exist.

BLCK does not depend on any of these layers. Everything in the toolkit works against the public sequencer endpoint and the public feed. If a private layer proves out and you choose to use it, it plugs in as another submission path, and you carry the trust decision yourself.