While this write-up explores potential solutions, some aspects remain open for debate or depend on further clarification. A dedicated section at the end, ‘Caveats and Open Questions,’ outlines these points in more detail.

Starknet’s claim of being the first network to settle simultaneously on Bitcoin and Ethereum has sparked an interesting debate. The concept is ambitious, but it raises fundamental questions about the practicalities of managing finality and reorgs across two vastly different blockchain ecosystems.

This discussion, prompted by a critical but valid perspective from @toghrulmaharram, highlights the complexity of ensuring consistency in settlement when dealing with two chains with distinct consensus mechanisms. While skepticism is warranted, it is also an opportunity to explore potential solutions. This write-up aims to clarify key points, address concerns, and examine the feasibility of Starknet’s approach. These are not definitive answers, but rather an attempt to navigate the intricacies of this technical challenge.

Starknet is suggesting that it can finalize its Layer 2 (L2) state on both Bitcoin and Ethereum at the same time. This would mean that the Starknet state root (which represents the rollup’s latest valid state) is committed to both Bitcoin and Ethereum, and users could rely on either chain as the authoritative source of truth.

However, the skepticism in the Twitter discussion is about how that would work in practice given the realities of blockchain finality and reorgs.

A reorg happens when a blockchain temporarily builds on one chain of blocks, but then a longer chain appears, invalidating some previously confirmed transactions.

• Bitcoin’s reorg behavior: Bitcoin’s longest-chain rule means that transactions in a block can be undone if a longer competing chain emerges.

• Ethereum’s reorg behavior: Ethereum also experiences reorgs, but due to its shorter block times and LMD-GHOST fork-choice rule, it tends to stabilize faster than Bitcoin.

Now, if Starknet posts its state root to both Bitcoin and Ethereum at a given block height and then one of those chains experiences a reorg, the new "correct" version of the chain might not contain the same Starknet state root. This could result in:

• Two conflicting views of the Starknet state, one on Bitcoin and one on Ethereum.

• If users or bridges rely on one chain while the other has a reorg, they might have an inconsistent understanding of Starknet’s finality.

When they say "one of the two must be driving," they mean that one of the chains needs to be the primary source of truth. If Bitcoin and Ethereum both attempt to serve as authoritative sources, but Bitcoin undergoes a deep reorg and Starknet has already posted its state root there, it could create conflicts.

For example:

• If Bitcoin is "driving," Starknet might say, "We only finalize our state when it's confirmed on Bitcoin and then propagate that finality to Ethereum."

• If Ethereum is "driving," the opposite happens: Starknet only trusts Ethereum’s finality and later posts to Bitcoin, treating it more like an archival layer.

Without a single chain acting as the final arbiter, there’s a risk that two different versions of Starknet’s state exist at the same time.

This is where the conversation in the tweets gets interesting. The replies are asking, “Okay, so if Bitcoin or Ethereum reorgs, what happens to Starknet’s state?”

• If Ethereum reorgs, it’s generally not a big deal because Ethereum finality stabilizes relatively quickly.

If Bitcoin reorgs, especially a deep one, Starknet would need to decide whether to:

• Re-post its state root on the new Bitcoin chain.

• Ignore Bitcoin’s reorg if Ethereum already considers the state finalized.

• Deal with potential divergence in bridges relying on the two chains.

That last point—divergence—is what Toghrul is emphasizing when he says “a reorg can result in the divergence of views of the two bridges.” In other words, cross-chain systems interacting with Starknet might see different valid states depending on whether they look at Bitcoin or Ethereum.

Even if Starknet can technically post its state root to both chains, the question remains: How does it guarantee consistency between them if reorgs happen?

• Does it wait for deep confirmations (which adds latency)?

• Does it reorg its own state if Bitcoin does?

• How does it handle smart contract interactions that assume finality?

This is why the skeptical comments suggest that “one of the chains has to be driving,” because relying on two L1s with independent finality mechanisms could introduce hard-to-resolve conflicts.

Since Starknet derives its security from its underlying L1(s), if an L1 reorg wipes out a previously posted state root, Starknet must reconcile this with its own state history. Otherwise, users could experience state inconsistencies, such as transactions referencing deposits that no longer exist due to an L1 rollback.

For example, if a user deposits 1 ETH into Starknet via an Ethereum transaction, and then Ethereum undergoes a deep reorg that removes that deposit, Starknet must either:

1. Revert the deposit and all subsequent transactions that depended on it, or

2. Find a way to reprocess transactions so that they align with the new L1 history.

Ignoring reorgs and continuing to post state roots without adjustments would lead to two conflicting Starknet histories, which could break bridges and cross-chain interactions.

After giving it some thought, this is where I believe the team at Starknet might be able to address these issues. I have no insider knowledge—this is purely speculation. The Starknet Operating System (SNOS) plays a pivotal role in managing transaction execution and state transitions within Starknet. Its design incorporates several patterns and mechanisms that could mitigate finality and reorg challenges, particularly when integrating with multiple Layer 1 (L1) blockchains like Bitcoin and Ethereum.

SNOS (Starknet Operating System) introduces new design patterns that may help mitigate these finality and reorg issues:

1. Decoupled State Roots for Bitcoin & Ethereum

   • Instead of relying on one single state root across both chains, SNOS could maintain separate views of Starknet’s state for Bitcoin and Ethereum.

   • If Bitcoin reorgs, only the Bitcoin state root needs to be reverted, leaving Ethereum unaffected.

2. Proof Trains for Faster Finality

   • SNOS might enable more frequent proof submissions to both Bitcoin and Ethereum.

   • If proofs are published frequently, Starknet can minimize the impact of L1 reorgs by quickly settling a new valid state.

3. Flexible Reorg Handling via Syscalls

   • SNOS introduces system calls (syscalls) that could allow contracts to query and adapt based on finality status.

   • Applications could wait for deep confirmations before assuming L1 finality, reducing the risk of unexpected rollbacks.

After executing transactions, SNOS generates a cryptographic proof attesting to the validity of the new state. This proof is then submitted to the L1 blockchain for verification. By anchoring Starknet’s state to an L1, SNOS ensures that the system can detect and respond to L1 reorgs, maintaining consistency across layers.

In the event of an L1 reorg, SNOS’s design allows it to revert and reprocess transactions as needed. Transactions affected by an L1 reorg can be marked as REVERTED, and mechanisms are in place to resubmit or re-execute these transactions to align with the new L1 state. This adaptability ensures that Starknet remains consistent with its underlying L1, mitigating potential issues arising from reorgs.

You might be asking yourself (as I was): Why does Starknet need to revert and reprocess transactions in response to an L1 reorg? Why not just continue and post a new state root? The answer depends on how Starknet treats finality and what role L1 plays in securing the L2 state.

Starknet is a rollup, which means it derives its security from its L1(s) (Ethereum, and now potentially Bitcoin). This means that:

• L2 transactions are processed by Starknet off-chain, but their final state is eventually posted to L1 for verification and finality.

• The validity proof (STARK proof) ensures that the state transition is correct.

• L1 acts as the source of truth for the rollup's latest accepted state.

Now, if Starknet has already posted a state root to L1, and that L1 undergoes a reorg, the previously posted state root might be wiped from the canonical chain.

• If that happens, Starknet’s last “final” state on L1 is no longer valid (at least according to L1).

• If any transactions on Starknet depended on that now-reverted L1 state, they might need to be reverted and reprocessed to maintain integrity with the new L1 history.

🔹 Example of why reversion is necessary:

• Suppose Alice deposits 1 ETH to Starknet via an Ethereum L1 transaction.

• Starknet processes the deposit and updates its L2 state.

• The Starknet state root reflecting Alice's deposit is posted on Ethereum.

• Ethereum reorgs, and Alice’s deposit is now missing from L1.

• Starknet now has a problem: It acknowledged Alice's deposit, but according to Ethereum’s new canonical chain, that deposit never happened.

• If Starknet continued without reverting, it would have an invalid state where Alice has 1 ETH that doesn’t exist on L1.

• To fix this, Starknet needs to roll back Alice’s deposit and reprocess L2 transactions in a way that aligns with Ethereum’s new state.

This kind of rollback behavior ensures that Starknet always maintains consistency with L1, preventing users from seeing an invalid state.

Technically, it could, but that would introduce state divergence and weaken security assumptions. If Starknet ignored the L1 reorg and just continued building new state roots:

• There would be two conflicting versions of Starknet’s history—one that aligns with the old L1 state and one that aligns with the new L1 state.

• This could break bridges and cross-chain interactions because users might be referencing an old state that no longer exists on L1.

• Any transactions depending on the old L1 state root would now be invalid or inconsistent.

Because Starknet is trying to settle on two L1s (Ethereum and Bitcoin), this problem is even more complicated:

• If Starknet posts a state root on Ethereum first, but Bitcoin reorgs later, should Starknet revert the Ethereum state too?

• If Starknet posts on Bitcoin first, but Ethereum reorgs, does it prioritize one chain over the other

• What happens if Ethereum and Bitcoin both reorg differently?

If Starknet just continued without handling these reorgs properly, it could create a scenario where Starknet’s state is no longer fully trustable, especially for bridges and applications that depend on it.

Starknet’s ambition to settle simultaneously on both Bitcoin and Ethereum presents a groundbreaking yet technically challenging proposition. The core issue revolves around how to handle finality and reorgs across two blockchains with fundamentally different consensus mechanisms—Ethereum’s probabilistic-but-eventual finality through Proof-of-Stake and Bitcoin’s longest-chain rule with no formal finality. The discussion has shown that these challenges are not trivial and require thoughtful solutions to avoid inconsistent state transitions or divergence between the two chains.

The introduction of SNOS (Starknet Operating System) may provide valuable tools for mitigating these challenges, such as decoupled state roots, proof trains for faster finality, and syscalls that allow contracts to react to L1 state changes dynamically. However, key questions remain, particularly regarding how Starknet will ultimately determine which chain drives finality, how it will respond to deep Bitcoin reorgs, and whether it will implement full transaction rollback or an alternative mechanism.

Despite these open questions, the broader blockchain community has consistently demonstrated a capacity for innovation when faced with technical hurdles. Starknet’s approach, while ambitious, is built on a foundation of scalable cryptographic proofs and decentralized settlement, and the team has a strong track record of pushing the boundaries of rollup technology.

As research continues and real-world testing of Bitcoin settlement progresses, we can expect refinements to these mechanisms. Whether through deeper confirmations, hybrid settlement models, or new cryptographic techniques, there is a strong reason to believe that solutions to these challenges will emerge. The skepticism surrounding simultaneous settlement is valid, but it is also an opportunity—to further advance interoperability, security, and the future of multi-chain rollups.

If Starknet succeeds, it will mark a significant milestone in blockchain scalability, proving that rollups can exist not just within a single L1 ecosystem, but across multiple chains with independent consensus models. The conversation on how to achieve this is just beginning, but the potential impact of such a breakthrough makes it a challenge worth solving.

1. SNOS Rollback Mechanism Is Not Fully Defined

   • While SNOS could allow transactions to be marked as REVERTED and reprocessed, the specific criteria Starknet will use to determine when and how reversion happens is not yet fully outlined.

   • Future developments might clarify whether Starknet will fully revert transactions after an L1 reorg or take a more selective approach.

2. Potential Mitigations for Bitcoin Reorgs

• Bitcoin’s lack of finality means that Starknet must either accept longer confirmation times or implement alternative strategies.

• Some potential approaches include:

  • Waiting for deeper confirmations before considering Bitcoin state as final.

  • Utilizing additional off-chain validity mechanisms similar to DLCs or Ark to ensure a smoother rollback process.

  • The specific method Starknet will use remains to be determined.

1. Ethereum’s Finality and Reorgs

• Ethereum’s Finality Checkpoints (via Proof-of-Stake) make deep reorgs rare, but the initial state is still probabilistic until finalization occurs after two epochs (~12.8 minutes).

• This means that Ethereum transactions are not instantly irreversible, and short-term reorgs could still pose a challenge if Starknet posts state roots prematurely.

1. Interaction Between Bitcoin and Ethereum Finality

• The write-up suggests that one chain should “drive” finality, but it is possible that Starknet could instead rely on a hybrid model that waits for both chains to confirm state before considering a transaction fully settled.

• If this hybrid model is chosen, it would increase finality time but could enhance consistency between Bitcoin and Ethereum settlements.

Sources:

• Starknet Documentation on SN Operating System: https://docs.starknet.io/architecture-and-concepts/network-architecture/os/

• Starkware Blog on General Computation on Bitcoin: https://starkware.co/blog/general-computation-on-bitcoin/

While this write-up explores potential solutions, some aspects remain open for debate or depend on further clarification. A dedicated section at the end, ‘Caveats and Open Questions,’ outlines these points in more detail.

Starknet’s claim of being the first network to settle simultaneously on Bitcoin and Ethereum has sparked an interesting debate. The concept is ambitious, but it raises fundamental questions about the practicalities of managing finality and reorgs across two vastly different blockchain ecosystems.

This discussion, prompted by a critical but valid perspective from @toghrulmaharram, highlights the complexity of ensuring consistency in settlement when dealing with two chains with distinct consensus mechanisms. While skepticism is warranted, it is also an opportunity to explore potential solutions. This write-up aims to clarify key points, address concerns, and examine the feasibility of Starknet’s approach. These are not definitive answers, but rather an attempt to navigate the intricacies of this technical challenge.

Starknet is suggesting that it can finalize its Layer 2 (L2) state on both Bitcoin and Ethereum at the same time. This would mean that the Starknet state root (which represents the rollup’s latest valid state) is committed to both Bitcoin and Ethereum, and users could rely on either chain as the authoritative source of truth.

However, the skepticism in the Twitter discussion is about how that would work in practice given the realities of blockchain finality and reorgs.

A reorg happens when a blockchain temporarily builds on one chain of blocks, but then a longer chain appears, invalidating some previously confirmed transactions.

• Bitcoin’s reorg behavior: Bitcoin’s longest-chain rule means that transactions in a block can be undone if a longer competing chain emerges.

• Ethereum’s reorg behavior: Ethereum also experiences reorgs, but due to its shorter block times and LMD-GHOST fork-choice rule, it tends to stabilize faster than Bitcoin.

Now, if Starknet posts its state root to both Bitcoin and Ethereum at a given block height and then one of those chains experiences a reorg, the new "correct" version of the chain might not contain the same Starknet state root. This could result in:

• Two conflicting views of the Starknet state, one on Bitcoin and one on Ethereum.

• If users or bridges rely on one chain while the other has a reorg, they might have an inconsistent understanding of Starknet’s finality.

When they say "one of the two must be driving," they mean that one of the chains needs to be the primary source of truth. If Bitcoin and Ethereum both attempt to serve as authoritative sources, but Bitcoin undergoes a deep reorg and Starknet has already posted its state root there, it could create conflicts.

For example:

• If Bitcoin is "driving," Starknet might say, "We only finalize our state when it's confirmed on Bitcoin and then propagate that finality to Ethereum."

• If Ethereum is "driving," the opposite happens: Starknet only trusts Ethereum’s finality and later posts to Bitcoin, treating it more like an archival layer.

Without a single chain acting as the final arbiter, there’s a risk that two different versions of Starknet’s state exist at the same time.

This is where the conversation in the tweets gets interesting. The replies are asking, “Okay, so if Bitcoin or Ethereum reorgs, what happens to Starknet’s state?”

• If Ethereum reorgs, it’s generally not a big deal because Ethereum finality stabilizes relatively quickly.

If Bitcoin reorgs, especially a deep one, Starknet would need to decide whether to:

• Re-post its state root on the new Bitcoin chain.

• Ignore Bitcoin’s reorg if Ethereum already considers the state finalized.

• Deal with potential divergence in bridges relying on the two chains.

That last point—divergence—is what Toghrul is emphasizing when he says “a reorg can result in the divergence of views of the two bridges.” In other words, cross-chain systems interacting with Starknet might see different valid states depending on whether they look at Bitcoin or Ethereum.

Even if Starknet can technically post its state root to both chains, the question remains: How does it guarantee consistency between them if reorgs happen?

• Does it wait for deep confirmations (which adds latency)?

• Does it reorg its own state if Bitcoin does?

• How does it handle smart contract interactions that assume finality?

This is why the skeptical comments suggest that “one of the chains has to be driving,” because relying on two L1s with independent finality mechanisms could introduce hard-to-resolve conflicts.

Since Starknet derives its security from its underlying L1(s), if an L1 reorg wipes out a previously posted state root, Starknet must reconcile this with its own state history. Otherwise, users could experience state inconsistencies, such as transactions referencing deposits that no longer exist due to an L1 rollback.

For example, if a user deposits 1 ETH into Starknet via an Ethereum transaction, and then Ethereum undergoes a deep reorg that removes that deposit, Starknet must either:

1. Revert the deposit and all subsequent transactions that depended on it, or

2. Find a way to reprocess transactions so that they align with the new L1 history.

Ignoring reorgs and continuing to post state roots without adjustments would lead to two conflicting Starknet histories, which could break bridges and cross-chain interactions.

After giving it some thought, this is where I believe the team at Starknet might be able to address these issues. I have no insider knowledge—this is purely speculation. The Starknet Operating System (SNOS) plays a pivotal role in managing transaction execution and state transitions within Starknet. Its design incorporates several patterns and mechanisms that could mitigate finality and reorg challenges, particularly when integrating with multiple Layer 1 (L1) blockchains like Bitcoin and Ethereum.

SNOS (Starknet Operating System) introduces new design patterns that may help mitigate these finality and reorg issues:

1. Decoupled State Roots for Bitcoin & Ethereum

   • Instead of relying on one single state root across both chains, SNOS could maintain separate views of Starknet’s state for Bitcoin and Ethereum.

   • If Bitcoin reorgs, only the Bitcoin state root needs to be reverted, leaving Ethereum unaffected.

2. Proof Trains for Faster Finality

   • SNOS might enable more frequent proof submissions to both Bitcoin and Ethereum.

   • If proofs are published frequently, Starknet can minimize the impact of L1 reorgs by quickly settling a new valid state.

3. Flexible Reorg Handling via Syscalls

   • SNOS introduces system calls (syscalls) that could allow contracts to query and adapt based on finality status.

   • Applications could wait for deep confirmations before assuming L1 finality, reducing the risk of unexpected rollbacks.

After executing transactions, SNOS generates a cryptographic proof attesting to the validity of the new state. This proof is then submitted to the L1 blockchain for verification. By anchoring Starknet’s state to an L1, SNOS ensures that the system can detect and respond to L1 reorgs, maintaining consistency across layers.

In the event of an L1 reorg, SNOS’s design allows it to revert and reprocess transactions as needed. Transactions affected by an L1 reorg can be marked as REVERTED, and mechanisms are in place to resubmit or re-execute these transactions to align with the new L1 state. This adaptability ensures that Starknet remains consistent with its underlying L1, mitigating potential issues arising from reorgs.

You might be asking yourself (as I was): Why does Starknet need to revert and reprocess transactions in response to an L1 reorg? Why not just continue and post a new state root? The answer depends on how Starknet treats finality and what role L1 plays in securing the L2 state.

Starknet is a rollup, which means it derives its security from its L1(s) (Ethereum, and now potentially Bitcoin). This means that:

• L2 transactions are processed by Starknet off-chain, but their final state is eventually posted to L1 for verification and finality.

• The validity proof (STARK proof) ensures that the state transition is correct.

• L1 acts as the source of truth for the rollup's latest accepted state.

Now, if Starknet has already posted a state root to L1, and that L1 undergoes a reorg, the previously posted state root might be wiped from the canonical chain.

• If that happens, Starknet’s last “final” state on L1 is no longer valid (at least according to L1).

• If any transactions on Starknet depended on that now-reverted L1 state, they might need to be reverted and reprocessed to maintain integrity with the new L1 history.

🔹 Example of why reversion is necessary:

• Suppose Alice deposits 1 ETH to Starknet via an Ethereum L1 transaction.

• Starknet processes the deposit and updates its L2 state.

• The Starknet state root reflecting Alice's deposit is posted on Ethereum.

• Ethereum reorgs, and Alice’s deposit is now missing from L1.

• Starknet now has a problem: It acknowledged Alice's deposit, but according to Ethereum’s new canonical chain, that deposit never happened.

• If Starknet continued without reverting, it would have an invalid state where Alice has 1 ETH that doesn’t exist on L1.

• To fix this, Starknet needs to roll back Alice’s deposit and reprocess L2 transactions in a way that aligns with Ethereum’s new state.

This kind of rollback behavior ensures that Starknet always maintains consistency with L1, preventing users from seeing an invalid state.

Technically, it could, but that would introduce state divergence and weaken security assumptions. If Starknet ignored the L1 reorg and just continued building new state roots:

• There would be two conflicting versions of Starknet’s history—one that aligns with the old L1 state and one that aligns with the new L1 state.

• This could break bridges and cross-chain interactions because users might be referencing an old state that no longer exists on L1.

• Any transactions depending on the old L1 state root would now be invalid or inconsistent.

Because Starknet is trying to settle on two L1s (Ethereum and Bitcoin), this problem is even more complicated:

• If Starknet posts a state root on Ethereum first, but Bitcoin reorgs later, should Starknet revert the Ethereum state too?

• If Starknet posts on Bitcoin first, but Ethereum reorgs, does it prioritize one chain over the other

• What happens if Ethereum and Bitcoin both reorg differently?

If Starknet just continued without handling these reorgs properly, it could create a scenario where Starknet’s state is no longer fully trustable, especially for bridges and applications that depend on it.

Starknet’s ambition to settle simultaneously on both Bitcoin and Ethereum presents a groundbreaking yet technically challenging proposition. The core issue revolves around how to handle finality and reorgs across two blockchains with fundamentally different consensus mechanisms—Ethereum’s probabilistic-but-eventual finality through Proof-of-Stake and Bitcoin’s longest-chain rule with no formal finality. The discussion has shown that these challenges are not trivial and require thoughtful solutions to avoid inconsistent state transitions or divergence between the two chains.

The introduction of SNOS (Starknet Operating System) may provide valuable tools for mitigating these challenges, such as decoupled state roots, proof trains for faster finality, and syscalls that allow contracts to react to L1 state changes dynamically. However, key questions remain, particularly regarding how Starknet will ultimately determine which chain drives finality, how it will respond to deep Bitcoin reorgs, and whether it will implement full transaction rollback or an alternative mechanism.

Despite these open questions, the broader blockchain community has consistently demonstrated a capacity for innovation when faced with technical hurdles. Starknet’s approach, while ambitious, is built on a foundation of scalable cryptographic proofs and decentralized settlement, and the team has a strong track record of pushing the boundaries of rollup technology.

As research continues and real-world testing of Bitcoin settlement progresses, we can expect refinements to these mechanisms. Whether through deeper confirmations, hybrid settlement models, or new cryptographic techniques, there is a strong reason to believe that solutions to these challenges will emerge. The skepticism surrounding simultaneous settlement is valid, but it is also an opportunity—to further advance interoperability, security, and the future of multi-chain rollups.

If Starknet succeeds, it will mark a significant milestone in blockchain scalability, proving that rollups can exist not just within a single L1 ecosystem, but across multiple chains with independent consensus models. The conversation on how to achieve this is just beginning, but the potential impact of such a breakthrough makes it a challenge worth solving.

1. SNOS Rollback Mechanism Is Not Fully Defined

   • While SNOS could allow transactions to be marked as REVERTED and reprocessed, the specific criteria Starknet will use to determine when and how reversion happens is not yet fully outlined.

   • Future developments might clarify whether Starknet will fully revert transactions after an L1 reorg or take a more selective approach.

2. Potential Mitigations for Bitcoin Reorgs

• Bitcoin’s lack of finality means that Starknet must either accept longer confirmation times or implement alternative strategies.

• Some potential approaches include:

  • Waiting for deeper confirmations before considering Bitcoin state as final.

  • Utilizing additional off-chain validity mechanisms similar to DLCs or Ark to ensure a smoother rollback process.

  • The specific method Starknet will use remains to be determined.

1. Ethereum’s Finality and Reorgs

• Ethereum’s Finality Checkpoints (via Proof-of-Stake) make deep reorgs rare, but the initial state is still probabilistic until finalization occurs after two epochs (~12.8 minutes).

• This means that Ethereum transactions are not instantly irreversible, and short-term reorgs could still pose a challenge if Starknet posts state roots prematurely.

1. Interaction Between Bitcoin and Ethereum Finality

• The write-up suggests that one chain should “drive” finality, but it is possible that Starknet could instead rely on a hybrid model that waits for both chains to confirm state before considering a transaction fully settled.

• If this hybrid model is chosen, it would increase finality time but could enhance consistency between Bitcoin and Ethereum settlements.

Sources:

• Starknet Documentation on SN Operating System: https://docs.starknet.io/architecture-and-concepts/network-architecture/os/

• Starkware Blog on General Computation on Bitcoin: https://starkware.co/blog/general-computation-on-bitcoin/