The Satoshi Upgrades: Self Custodial sBTC.

Overview of Technical Advancements:

Self-custodial minting: A programmable Bitcoin asset would ideally require that any transaction that could move a Bitcoin holder's underlying $BTC must be signed by them, thereby eliminating any custodial risk. As we’ll show later, using a combination of zero-knowledge proofs, HTLCs and the fact that Stacks nodes have access to Bitcoin state (and therefore can independently verify the existence of any given Bitcoin transaction), it is indeed possible to design this into sBTC.

Extra care must be taken when transfers happen to other users or into a smart contract – when transferring to another Stacks user, the custody of the underlying $BTC needs to be updated accordingly; while when deploying to a smart contract, ownership moves to a decentralized signer set by default. A new data structure, called the Redemption DAG, is used to manage and track all these state changes on the Stacks Layer 2.

Post-conditions on the underlying Bitcoin: When self-custodial sBTC is transferred into a smart contract the default is that the underlying $BTC is held by the sBTC signer set. While this is adequate for many situations today, certain use-cases might desire more control over the underlying $BTC and we can enable this. The high-level idea is that just like there are post-conditions for Stacks transactions, we can introduce post-conditions that govern the custody of the underlying Bitcoin. For instance, a lending application could specify (in their Clarity contract) that upon liquidation, the $BTC will be released to a particular Bitcoin address. This is only possible because Stacks has full access to Bitcoin state and is tightly integrated with the Bitcoin Layer 1.