# Pre-confirmation Liveness Slashing Penalties from the Proposer's Perspective

Current designs around pre-confirmations involve a slashing penalty on liveness, that is if a proposer who commited to pre-confirmations misses its proposal, part of its collateral is burned or redistributed to the user that sent the pre-confirmation as a payback.

This post explores the liveness penalty from the point of view of proposers from an economical perspective.

## Sources of Liveness Issues

Liveness issues are complex and can come from different actors or sources, part of them are the result of the proposerâ€™s actions or choices, part of them donâ€™t depend on the proposer. For example:

• proposing a block in time but being reorg by the next proposer,
• failure from the relayer to send the header in time,
• failure from the relayer to propagate the signed header in time and reveal the block to the proposer.

As a result, the decision on whether to opt-in or not from a proposer perspective has to take into account an inherent risk outside of its actions. Using a statistical approach on network history sounds like an easy starting point.

## Economical Minimal Viability

In the last 7 days on the network, about 0.54% of slots were missed, to break-even economically (that is, for an operator to not lose or win anything in the long run), assuming the liveness fault is 1 ETH, the minimal extra-tip of a pre-confirmation would be 0.0054 ETH.

To put it in perspective, the median execution reward in the last 7 days is ~0.048 ETH, so with 1 ETH of collateral, the pre-confirmations would need to be about 10% of the blockâ€™s value with the current network conditions. Using P(miss) as the probability to miss a block, the break-even formula is:

(1 - (P(miss))) * tip = P(miss) * penalty

And so the minimal tip:

tip = {(P(miss) * penalty) \over (1 - P(miss))}

With 1 ETH as a collateral, here is the model for low probabilites of missed block with P(miss) < 0.025:

Zooming out up with P(miss) < 0.5:

## Opt-in if Economically Viable

One idea to make it viable at scale with little effort from proposers would be for the pre-confirmation sidecar on the proposer side to opt-in to pre-confirmations only it if the tip is above whatâ€™s economically sound given the current rate of misses on the network. For example, if in the last 24 hours the average missed block proposal is 0.5%, only commit to pre-confirmations which tip is above 0.005 ETH.

This approach requires the relayer to pass the pre-confirmation tip information to the proposer to decide whether or not to commit to pre-confirmations, or the proposer to send the minimal-tip to the builder so it can provide a block that match it.

The advantage of this approach is if the network is struggling at scale, the risk for a proposer to miss a slot increases, and so it makes sense for proposers to opt-out of pre-confirmations until the situation resolves. Increasing the pre-confirmer bid under such conditions makes sense as more risk is taken.

A disavantage is that the missed block proposal rate is an approximation: it doesnâ€™t account for totally offline validators, or for the extra-cost involved in validating the pre-confirmation on the proposer side which can take time and increase the risks of missing the slot.