Thread by @cemozer_

TEMPO SHOULD BE AN L1: CONFESSIONS OF AN L2 BUILDER

For payments, having the shortest possible time-to-finality is critical; because until a transaction is finalized (i.e., it can no longer be reversed), it cannot reliably facilitate an exchange.

Let’s explore why.

Alice gives Bob a Labubu in return for 10 BTC. However, Alice doesn't wait until Bob’s BTC transfer is finalized. Instead, she accepts it as soon as the transaction is included in the latest Bitcoin block.

If Bob then publishes another transaction with a higher fee that drains his account, and the Bitcoin network undergoes a re-org, Alice risks never receiving the funds for the Labubu.

This is the well-known double-spend problem, and it's the reason exchanges wait a considerable time before accepting deposits from Bitcoin, Ethereum, or any of its L2s.

Bitcoin, due to its longest-chain rule, is considered final after 6 blocks (around 60 minutes). Ethereum, because of its complex Casper the Friendly Finality Gadget, typically achieves finality in approximately 15 minutes.

Returning to rollups, a rollup transaction can only be considered final once the rollup batch containing the transaction is included in a finalized L1 block.

Since almost all rollups today settle on Ethereum, their time-to-finality is constrained by Ethereum’s 15-minute finality window.

However, to support real-world payments, a blockchain needs significantly shorter time-to-finality. Because if you’re selling physical goods or services that you can’t take back, fast finality is a must.

This is the core reason why Tempo needs to be an L1. Or more specifically, why it can't be built as an Ethereum L2 today.

The question is: can we do better?

Indeed, we can. A well-designed rollup doesn't need to be settled or deployed on Ethereum. It can instead be deployed directly on a sub-second finality L1, achieving finality as quickly as that L1 finalizes.

This isn't possible with Ethereum-based rollup stacks like Arbitrum Orbit or OP Stack, as they rely on Ethereum for settlement (i.e. processing of forced transactions, attestations, challenges, and proofs) even if they publish data elsewhere. So an Arbitrum Orbit or OP Stack chain that publishes data to Celestia still inherits Ethereum’s quite long time-to-finality.

However, that's not a hard requirement for rollups. A rollup can be "self-settled."

In other words, it can handle its proofs and challenges internally and manage the slashing and incentives for relevant participants within its own state machine. This approach means the rollup is entirely secured by the L1 on which it publishes its data, without requiring any smart contracts on Ethereum.

This is precisely how Sovereign SDK rollups function today. The rollup manages its own security accounting (settlement), and its sequencers publish transactions to the L1 as swiftly as possible, providing users with the fastest achievable finality.

With Sovereign SDK rollups deployed on Celestia, users currently experience finality in about 6 seconds. With upcoming upgrades to Celestia's consensus mechanism, this will soon decrease to approximately 300 ms.

If you’re curious about how such a system works in practice, check out our docs below: docs.sovereign.xyz/7-1-transactio…