Originally posted on HackMD.

Flame is an Astria-based EVM rollup that serves as TIA’s DeFi hub. The top of the block (ToB) in a DeFi-enabled rollup is particularly valuable because it provides an execution guarantee. As the amount of liquidity on Flame increases, the volume of MEV opportunities will grow, thereby increasing the value of Flame’s blockspace. With an increased demand for ToB execution, an auction is the efficient mechanism for allocating this privilege to a bidder, accumulating revenue for the Flame ecosystem.

Flame leverages Astria's lazy sequencer and sequencing rules to construct an auction for only the top-of-block bundle slot. As lazy sequencing separates inclusion from execution, Flame’s trusted Auctioneer simply needs to allocate, sign and include the auction-winning bundle in the sequencing-layer block. Flame’s execution enforces a sequencing rule that places the Auctioneer’s signed Allocation deterministically at the top of the block it was successfully included in. This provides bidders with a dedicated submission path that offers two key benefits:

1. Bidders submit their bundles directly to the trusted Auctioneer's node, keeping their traffic separate from regular (i.e. MetaMask) users who submit transactions via the rollup’s mempool. This contains congestions and prevents the adverse effects on regular users during periods of high market activity, such as spikes in gas costs.

   
   

2. The auctioneer runs a sealed-bid first-price auction that allocates the top-of-block slot to the highest bidder. This ensures that only the winning bidder's bundle is posted and only they pay for their transactions.

   
   

   1. Unlike priority fees, which charge all bidders regardless of winning, this system only charges the winning bidder.

   2. Bids are sent by bidders directly to the Auctioneer’s node, and do not go through a public mempool. Bidders cannot see other submitted bids nor the corresponding payloads.

      
      

Flame implements a Top-of-Block Bundle Sequencing Rule which appoints an Auctioneer that runs an auction for a ToB bundle, accepting bundles and bids from users.

Flame’s Auctioneer runs a first-price auction, providing bidders with an RPC to submit their bundles and associated bids.

At the end of the auction window in a given block, the Auctioneer signs and submits an Allocation containing the winning bundle, which will be used by the ToB sequencing rule to place the constituent transactions at the top of the block.

Blocks sequenced on Astria enjoy single-slot finality, so as soon as an allocation is sequenced into the block, Flame will execute the Allocation first in the corresponding block.

Top-of-Block Bundle Sequencing Rule

Rollups built on top of Astria’s lazy sequencer architecture construct their block by separating inclusion of transaction data in the decentralized sequencer network and execution of the included data by rollup nodes.

Transaction data in included in Flame’s namespace on the Astria sequencing layer are fed into Flame’s execution nodes. Execution must be deterministic in order for the rollup to produce blocks safely:

1. Derivation function

   The first step when receiving a finalized block is validation of the sequencer or DA layer block finality, Merkle verification of the rollup blob data in the finalized block, and feeding the block data for execution in the Rollup node.

   This step is implemented in Astria’s conductor sidecar, which runs alongside the execution node flame-geth. The conductor drives execution in flame-geth using the Execution API’s ExecuteBlock method.

   
   

2. Deserialization

   Upon receiving the opaque bytes sequenced by Astria, Flame deserializes the transaction data into one of:

   1. Regular EVM transaction

   2. Deposits from the Astria bridge protocol.

   3. An Allocation signed by the trusted Auctioneer.

      
      

3. Sequencing Rules

   Once the transaction data has been decoded into Flame transactions, sequencing rules are applied.

   
   

   Flame’s auction relies on a deterministic Top-of-Block Bundle Sequencing Rule defined by its execution nodes. It encodes a known Auctioneer actor which is trusted to run a first-price auction and include the resulting Allocations in Astria’s sequencing layer. When an Allocation is included in a block, the execution nodes receive it with the rest of the transaction data and enforce the following sequencing logic:

   
   

   1. Verify the Allocation was signed by the trusted Auctioneer, and that the parent block hash matches the current parent block hash.

      • The parent block hash check is used to provide the Auctioneer with the guarantee that the payload will only execute as ToB for the given block, ensuring that bids can only execute in the block against which they were checked for validity by the Auctioneer.

        
        

   2. Unbundle the Allocation into its constituent transactions and place those at the top of the list of transactions to execute in the current block.

      
      

4. Execution

   After executing all the sequencing rules used by Flame, the execution nodes will have the resulting ordered list of EVM transactions to feed into the state transition function, which will produce this block’s state and header.

   
   

5. Header finalization

   Since both Astria’s sequencing layer and Celestia’s data availability layers enjoy single-slot finality, managing fork choice rules and header finalization is pretty straightforward: as long as the previous steps are executed deterministically, data that has been finalized will always produce the same block when executed.

   
   

   The details for managing and updating the commitment state of executed block headers is driven by Astria’s conductor sidecar, using the Execution API’s UpdateCommitmentState method.

   
   

This allows Flame to appoint an Auctioneer that would run an auction for a top-of-block bundle. The appointed Auctioneer will sign and submit an Allocation for the bundle slot to the auction winner. Flame’s Auctioneer will run a first-price auction, providing bidders with an RPC to submit their bundles and associated bids.

Note: In V1, the Auctioneer will only support bundle and bid submission via eth_sendTransaction, as explained below.

Bid Submission

Bids in the auction are submitted to the Auctioneer’s dedicated Flame node.

For V1, bidders will use the following:

Bid Interface: eth_sendRawTransaction/eth_sendTransaction

Bid Structure: A regular Eth EIP-1559 transaction

Bid Value Indication (payment rule?): The tip of the EIP-1559 transaction

The auctioneer’s rollup node checks submitted bids against the optimistically executed block to ensure that the bidders’ can pay their bid.

• Flame testnet docs

• Metamask eth_sendTransaction docs

  
  

Auction Details

Flame’s Auctioneer runs a first price auction for a bundle, restricted to a slot.

Bundles/bids submitted to the Auctioneer are simulated against the latest block to calculate the bid paid to the Auctioneer.

The Auctioneer optimistically executes blocks even before they have finality on the Astria sequencer, allowing it to accept and simulate bids for a given slot as soon as possible. The same functionality can be used by bidders to optimistically execute on their local rollup node earlier as well.

Timeline

The auction timeline is important for understanding when bids can be submitted. The Auctioneer conducts an auction every block. Block times in CometBFT-based systems are set by the timeoutCommit configuration, which determines how long validators will wait between marking a block as committed and the next slot’s proposal step.

This determines the deadline for submitting transactions to the Astria sequencer (i.e. for the winning Allocation to be sequenced), and thus the deadline for submitting bids into the auction:

Auction start time: After a block is successfully executed optimistically by the Auctioneer.

Auction end time: The Auctioneer will start a timer after the previous block is marked as committed. This timer governs when the auction will end and the Allocation will be submitted for sequencing. Bids can be submitted for a given block until the timer expires.

Once the auction ends, the Auctioneer will submit the winning Allocation and the auction closes until the next slot.

After the Astria sequencing layer finalizes the block and it is executed, the auction-winning bid will be observable by all Flame nodes as the sequenced Allocation, which will then be executed.

Auction State Machine

An auction for a given block advances through the following states:

1. When a new optimistic is received, it is forwarded to the Flame node for execution. The auction is initialized but not yet open for bid submission.

2. After successfully executing the optimistic block, the auction will start processing incoming bids that have been checked against the latest state for validity and sufficient balance.

   
   

Note: While multiple rounds of voting in a single CometBFT block are rare, the optimistic execution protocol handles such “reorgs”.

3. After receiving a commitment for the block that was optimistically executed, the auction will set a timer for latency_margin(denominated in milliseconds).

   
   

4. Once the timer expires, the auction will choose a winner based on its AllocationRule and submit it to the sequencer.

   
   

Aborting an Auction

While CometBFT provides single slot finality, blocks executed optimistically have not yet been finalized and thus may be “reorged” due to multiple rounds of voting within the same slot. We assume that most proposals are adopted in cometBFT, allowing us to buy an additional few hundred milliseconds for before they are finalized.

Optimistic reorgs are managed by aborting a running auction before receiving a block commitment and starting the auction timer. This will cause the auction to return early without submitting a winner in order to avoid a failure in processing an invalid bid. After the auction is aborted a new one will be created for the newly arrived optimistic block.