Skip to main content

Pricing Preconfirmations

· 4 min read

This post assumes familiarity with preconfirmations. If you aren't familiar here's a few resources:

This article/research is in active development and changing.

Open Questions in Preconfirmations​

  1. What will be the pricing of a preconfirmation?
  2. Will one preconfirmation relay be dominant or will multiple?
  3. How should a wallet send a preconfirmation request?

Pricing a Preconf​

There are two types of preconfirmations: Just-In-Time, which is buying space in the current block (less than 12 seconds from now) and Ahead-Of-Time, which is buying space in a future block (>12s from now). We will cover Just-In-Time.

The validator has a monopoly on transaction inclusion, so they will attempt to max rewards per block. When the validator issues a preconfirmation, their gain is:

Profit_To_Validator = Preconf_Fee + MEV_Extractable_From_Preconfirmed_Tx  - MEV_Extractable_From_Excluded_Transaction

Thus the validator can maximize profits by excluding transactions that were not mev-extractable and replacing them with preconfirmationed transactions.

We believe the amount of non-mev-extractable transactions per block will depend mainly on the number of waiting transactions in the mempool. There needs to be a data science/ML pricing model on the proposer or relay side, that handles pricing of a preconfirmation.

Pricing Model​

We believe the inputs to this model would be (1) number of waiting transactions in the mempool (2) source of incoming transactions, dex transactions would be more valuable for MEV vs nft mints. Other variables could be considered like (3) time of day (4) impending high traffic events, and more.

To make money, the preconfirmation price should be higher than the lowest mev-extractable transaction

Valuable Use Case Only Preconfirmations​

A proposer can either give a preconfirmation cheaply to many people or at a high price to only a few.

For valuable use case preconfirmations, the user only sends a preconfirmation when there is a critical event for which they need inclusion rights. For example, for an upcoming hot NFT mint, the user would send out a preconfirmation. These use cases would be fewer in between and the bidder for these types of preconfirmations would pay a premium. If you're able to buy a bored ape during mint time, and then sell in the next block, you could guarantee yourself a strong profit.

For everyday-use preconfirmations, the fee would be so low that users send most of their transactions preconfirmed. Preconfirmations would be the default path for sending most transactions on Ethereum for convenience reasons.

While we'd prefer for everyone to experience instant confirmations while using Ethereum, validators need to price carefully to ensure they are profitable.

Validator Operator Behavior

If you are a node operator, your best outcome is done by:

  1. integrating multiple preconfirmation protocols so that the relay doesn't have monopoly power. This is also positive to decentralization, since the relay could be censoring.
  2. charge a uniform price across preconfirmations via the pricing model (or accept the relay that offers the highest). You need to keep track of profits over time (or run your own model) to confirm that the relay bid is higher than your opportunity cost. A bad preconfirmation protocol regularly prices the preconfirmation at below your opportunity cost, causing you to lose money over time.

It would be preferable for ethereum to encourage everyday-use preconfirmations to allow the average user to experience instant confirmation.

For the initial rollout of preconfirmations, we suggest that the validator operator price at a bit higher than expected, measure per block earnings then slowly reduce the price to meet demand, constantly checking to ensure the preconfirmation integration is net profitable.

How should a wallet send a preconfirmation request?​

We believe the best UX is for the user to be provided a price for a preconfirmation upfront (instead of having to bid and await acceptance). User would check a box on their wallet and receive a preconf for gas + preconf_fee. The wallet provider should provide updated fees from a few preconfirmation relays, taking the fee that is cheapest.

Multi-Relay Integration​

As preconfirmations become costlier the less space is in the block, every preconfirmation relay needs to know how many preconfirmations the validator has given out (via the other relays). Thus the validator should report to each preconfirmation protocol the number of total preconfirmations that have been given out.