The Offchain Labs research team has a specific proposed design in mind for adding Timeboost to the current centralized sequencer design. This would allow Arbitrum chains to prevent front-running, while capturing the value of benign MEV types like arbitrage.
The design has two parts: a change to the sequencer’s transaction ordering policy, and a new transaction type.
The sequencer’s ordering policy would go in rounds, with each round containing these steps:
- the sequencer waits for a fixed period (tentatively: 0.5 seconds), collecting all transactions that arrive before the end of the period
- the sequencer sorts the collected transactions into decreasing order by bid, breaking ties by a deterministic rule,
- the sequencer builds a block from the sorted transaction list and emits that block into its output feed,
- the round ends and the next round starts
The new transaction type is identical to a standard user-signed transaction, with the only differences being (1) a different transaction type label, and (2) how transaction fees are collected by the chain. For the new transaction type, the chain would collect the priority fee (“tip”) per gas unit as in Ethereum. (By contrast, standard transaction types don’t pay the priority fee on Arbitrum chains.) So the new transaction type would pay a gas price equal to the current Arbitrum-chain base fee plus the transaction’s priority fee.
A transaction’s bid, for sorting purposes, is (1) its priority fee, if it is the new transaction type, or (2) zero, for other transaction types. So a transaction can get earlier placement within its block by paying a higher priority fee. This implements a sealed-bid, all-pay, priority gas auction for position within the block.
In this design, the sequencer does not collect any “MEV fees”. Instead, transactions bid for position by offering to pay a priority fee for each gas unit they use. The resulting fees are collected by the chain, as part of its normal gas fee collection mechanism.
The priority fees would be collected by the chain and paid to an address specified by chain governance. In the case of DAO-governed chains, this address would be specified by the DAO.
For most chains, the fees would be paid to a smart contract which would split up the fee revenue as specified by chain governance. Most likely this would mean the largest share of priority fee revenue would go to the chain owner (e.g., the DAO) with perhaps a small slice going to the sequencer operator(s).
I gave a more detailed talk about this design and why I think it makes sense, at the Stanford MEV Workshop. Video is available here.
(One obvious design alternative is to not introduce a new transaction type, and just use the existing transaction type, which already has a priority fee field. The alternative would involve collecting the priority fee for existing transactions, which would be a change from the current policy of ignoring the priority fee field and treating all transactions as if they submitted a priority fee of zero.
The drawback of this alternative is many current transactions include a priority fee, typically a few gwei, because that is the default in some wallets–so that collecting the priority fee would cause many users to inadvertently pay much more for gas (adding, say, a 2 gwei tip on top of the 0.1 gwei base fee, a 21x increase in fee). By creating a new transaction type, and continuing to treat all legacy transaction types as having priority fee zero, we would protect users from this issue.)