sBTC Deposit - Diagram and Flow

[8marz8]

Separate discussion topic to consider possible Deposit/Peg-In/Mint flows and settle on a near-final diagram that captures our HLD decision for sBTC V1.

Deposit Diagram For API-Only Ingress

Deposit Flow For API-Only Ingress

1. Deposit request: A bitcoin holder creates a transaction on Bitcoin.
   • The deposit transaction contains a UTXO (deposit UTXO) spendable by sBTC Signers, with an OP_DROP payload.
   • The payload contains the recipient address of the sBTC among other relevant info for the deposit.
     • The relevant info could contain fee suggestion or max_fee
2. Proof of deposit: The bitcoin holder submits a proof of deposit on Stacks by invoking the Signer API
3. Deposit accept:
   • Deposit redeem: The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO.
   • Mint: The sBTC Signers finalize the deposit acceptance by calling the mint function in .sbtc to mint the sBTC.

This flow only requires one contract call to mint sBTC:
(Note: the parameters and description is not finalized/accurate)

Function name	Parameters	Description
mint	(amount, destination, deposit-txid, burn-chain-height, merkle-proof, tx-index, block-header)	This function takes in some information that is all read directly from the provided Bitcoin transaction. It includes the Stacks principal to mint the sBTC to, and all of the required Bitcoin transaction information required to verify it.

---

Original draft diagram Link -> https://www.figma.com/file/wWLNDHKYQJjcNAlIyDHDwn/sBTC-Peg-In?type=whiteboard&node-id=0%3A1&t=kHawzKr0zVbPkskV-1

[netrome]

Nit: Can we call it "deposit" flow instead of "peg-in" to be consistent with naming?

[AshtonStephens]

1. Consensus level challenges to enforce that signers include deposits can only be included in sBTC v2 because there will be no changes to the stacks-core for the core Nakamoto signers.
2. The sBTC Signers will be the sole gatekeeper to accepting or rejecting sBTC transactions, and the challenge will still be present but not enforced

[AshtonStephens]

Question:

• Does the clarity contract need to reveal the stacking transactions

[8marz8]

Question:
Can we confirm the API layer name? (Revealer or Signer API)?
Also, will this be part of the Signer binary, or will it be a separate one? (I can adjust the diagram accordingly and potentially conclude the other discussion topic on Revealer API)

[netrome]

I like to call it Signer API.

I'm open to other suggestions, but would prefer to refrain from the term "Revealer API", because it comes from the previous commit-reveal documentation where the Revealer was seen as a separate role from Signers.

[AshtonStephens]

Proof of deposit -> The information the signer will need to spend a deposit UTXO.

[AshtonStephens]

Mint call will have the same signature requirements expanded upon in #16