'Bitcoin Finality' on Stacks Means Reorg Cost, Not Bitcoin Security - and the Distinction Decides Who Can Take Your Coins
DEEP-DIVE ON THIS CARD. The claim is technically defensible and routinely misread. Worth separating precisely what is inherited from Bitcoin and what is not.
WHAT NAKAMOTO CHANGED.
The Nakamoto release was a hard fork of the Stacks network delivering two headline properties: block times reduced from roughly 10 minutes to between five and ten seconds, and what the project terms 100% Bitcoin finality. Under this design, transaction ordering and reversal are protected by Bitcoin's hash power, and the Stacks chain no longer forks on its own. Once a transaction is confirmed, reversing it is at least as hard as reversing a Bitcoin transaction. Nakamoto also set up sBTC, a programmable BTC asset delivered in a follow-on upgrade.
A note on framing: this is the architecture of the Nakamoto release rather than a new development, so treat 'Stacks enables Bitcoin finality' as a description of an existing property rather than a fresh event. It is also filed on this feed under regulatory, which is a mis-tag - there is no regulatory content here.
WHAT 'BITCOIN FINALITY' DOES AND DOES NOT BUY.
Blockchain security decomposes into at least three separable guarantees, and anchoring buys one of them.
Ordering and immutability - inherited. If reorganising Stacks history requires reorganising Bitcoin history, then an attacker needs Bitcoin-scale hashrate to rewrite settled Stacks transactions. This is the real and substantial claim.
Validity - not inherited. Bitcoin's miners do not execute or verify Stacks smart contracts. Whether a Stacks transaction is legitimate under Stacks' own rules is determined by Stacks' consensus and its signer set. Bitcoin will happily anchor an ordering that contains a transaction exploiting a buggy contract. Anchoring makes a bad state permanent as effectively as a good one.
Custody and peg integrity - not inherited. sBTC is backed by BTC held under a threshold signer arrangement. The safety of that peg depends on the honesty and liveness of those signers, not on Bitcoin's hashrate. Bitcoin's consensus has no view on whether the peg is solvent.
WHY THE DISTINCTION IS PRACTICAL.
Every significant loss in Bitcoin layer-two and bridge systems has come from the second and third categories - contract logic and peg custody - not from chain reorganisation. The MAYAChain incident this month is a clean example: six chained bugs produced claims vastly exceeding reserves, and no amount of anchoring would have prevented it, because the invalid state was validly ordered.
So 'secured by Bitcoin' is accurate about the property least likely to be attacked, and silent about the two properties that actually get attacked.
HOW TO ASSESS IT.
Ask three questions of any Bitcoin layer-two making this claim. Who can produce an invalid state, and what stops them. Who holds the pegged BTC, under what threshold, and what happens if they collude or go offline. And does anchoring cover only ordering, or also validity - it is almost always only ordering.
Fast blocks plus reorg resistance is a real engineering achievement. It is not a transfer of Bitcoin's trust model.
Sources (5)
AI Research
Key Takeaway
Stacks' Nakamoto release cut block times from ~10 minutes to 5-10 seconds and gave transactions what the project calls 100% Bitcoin finality: once confirmed, reversing a Stacks transaction is at least as hard as reversing a Bitcoin transaction, because ordering is anchored to Bitcoin's hash power and the chain no longer forks independently. That is a genuine reorg guarantee. It is not the same as Bitcoin securing your funds - validity and custody remain Stacks' problem.
DEEP-DIVE ON THIS CARD. The claim is technically defensible and routinely misread. Worth separating precisely what is inherited from Bitcoin and what is not.
WHAT NAKAMOTO CHANGED.
The Nakamoto release was a hard fork of the Stacks network delivering two headline properties: block times reduced from roughly 10 minutes to between five and ten seconds, and what the project terms 100% Bitcoin finality. Under this design, transaction ordering and reversal are protected by Bitcoin's hash power, and the Stacks chain no longer forks on its own. Once a transaction is confirmed, reversing it is at least as hard as reversing a Bitcoin transaction. Nakamoto also set up sBTC, a programmable BTC asset delivered in a follow-on upgrade.
A note on framing: this is the architecture of the Nakamoto release rather than a new development, so treat 'Stacks enables Bitcoin finality' as a description of an existing property rather than a fresh event. It is also filed on this feed under regulatory, which is a mis-tag - there is no regulatory content here.
WHAT 'BITCOIN FINALITY' DOES AND DOES NOT BUY.
Blockchain security decomposes into at least three separable guarantees, and anchoring buys one of them.
Ordering and immutability - inherited. If reorganising Stacks history requires reorganising Bitcoin history, then an attacker needs Bitcoin-scale hashrate to rewrite settled Stacks transactions. This is the real and substantial claim.
Validity - not inherited. Bitcoin's miners do not execute or verify Stacks smart contracts. Whether a Stacks transaction is legitimate under Stacks' own rules is determined by Stacks' consensus and its signer set. Bitcoin will happily anchor an ordering that contains a transaction exploiting a buggy contract. Anchoring makes a bad state permanent as effectively as a good one.
Custody and peg integrity - not inherited. sBTC is backed by BTC held under a threshold signer arrangement. The safety of that peg depends on the honesty and liveness of those signers, not on Bitcoin's hashrate. Bitcoin's consensus has no view on whether the peg is solvent.
WHY THE DISTINCTION IS PRACTICAL.
Every significant loss in Bitcoin layer-two and bridge systems has come from the second and third categories - contract logic and peg custody - not from chain reorganisation. The MAYAChain incident this month is a clean example: six chained bugs produced claims vastly exceeding reserves, and no amount of anchoring would have prevented it, because the invalid state was validly ordered.
So 'secured by Bitcoin' is accurate about the property least likely to be attacked, and silent about the two properties that actually get attacked.
HOW TO ASSESS IT.
Ask three questions of any Bitcoin layer-two making this claim. Who can produce an invalid state, and what stops them. Who holds the pegged BTC, under what threshold, and what happens if they collude or go offline. And does anchoring cover only ordering, or also validity - it is almost always only ordering.
Fast blocks plus reorg resistance is a real engineering achievement. It is not a transfer of Bitcoin's trust model.