sBTC Deposit and Withdrawal flows - Overview and Nomenclature

[netrome]

Purpose

Consolidate the current ideas revolving the deposit and withdrawal flows into a simple coherent view with consistent naming of the associated transactions.

Glossary

Term	Description
Bitcoin holder	A person or system holding BTC, interested in acquiring sBTC
sBTCholder	A person or system holding sBTC, interested in turning it back into BTC
sBTC UTXO	Single UTXO holding the entire sBTC balance
.sbtc contract	A smart contract (or a collection of contracts) defining the sBTC token and functions related to it
sBTC Signers	A set of signers registered in the .sbtc contract, capable of spending the sBTC UTXO

High level flows

Deposit

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.
2. Proof of deposit: The bitcoin holder submits a proof of deposit on Stacks by calling the deposit-request function in the .sbtc contract.
   • The deposit-request function records the existence of the deposit request transaction and validates its content.
   • This step could be skipped by supplying the equivalent information directly to the sBTC Signers off-chain.
3. Deposit accept: The sBTC Signers accept the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO.
   • This is accompanied by a call to a deposit-accept function in the .sbtc contract which records the signer votes and other relevant information.
4. Mint: The stacks node reads the deposit accept transaction and calls the mint function in .sbtc to mint the sBTC.
   • In a non-consensus breaking version, the sBTC Signers could call this function.

Withdrawal

1. Withdrawal request: An sBTC holder calls the withdraw-request function in the .sbtc contract.
   • This burns the requested sBTC.
2. Withdrawal accept: The sBTC signers create a transaction on Bitcoin which returns the requested amount to the designated address.
   • This is accompanied by a call to a withdrawal-accept function in the .sbtc equivalent to deposit-accept.

Rejection

Both deposits and withdrawals may be rejected. In this scenario the Deposit accept or Withdrawal accept bitcoin transactions are replaced by contract calls to functions named deposit-reject or withdrawal-reject, which record the decision to reject the deposit or withdrawal. In addition, withdrawal-reject will mint the same amount of sBTC which was burned in the withdraw-request contract call.

Differences with current SIP

While I have mainly introduced names for transactions which didn't have names in the current SIP, the following two transactions have gotten new names in this proposal:

Old name	New name
"Stacker authorization transaction"	deposit-accept
"Challenge transaction"	deposit-request

Discussion topics

• Do these flows summarize everyone's general conception around how deposits/withdrawals work or are we missing anything significant here?
• Any naming suggestions for the "sBTC UTXO". Should we call it "sBTC treasury UTXO"? Do we have other ideas?

[hstove]

I like the term "deposit accept" to cover the entire flow of signers consuming the UTXO and calling deposit-accept in the contract. The only suggestion I have here is to call the action of consuming the deposit UTXO (which is also a good term) either "redeeming" or "consuming" a deposit. I'm not very partial towards that exact language, but I would like a concrete term for the act of collecting and consuming the deposit UTXOs.

[jferrant]

Yeah feel like there should be a "burn" equivalent to "mint" call which should be called "redeem" since you are not actually getting nothing in return but getting back BTC

[8marz8]

withdrawal-reject will mint the same amount of sBTC which was burned in the withdraw-request contract call.

I might be missing something here...I don't understand why another round of minting is needed.
Shouldn't the signers decide to approve or reject the withdrawal request before burning the sBTC? So in case of rejection, they don't have to mint sBTC again.

[hstove]

They're both functionally the same. If we don't burn right away, the sBTC contract just holds the sBTC, in which case a rejection would transfer the sBTC back. If we do burn, the contract mints the sBTC.

I can see an argument for both sides. If we don't burn, the balance held by this contract represent the amount of "pending" withdraws.

[hstove]

Separate point: if we do a mint/burn approach, then the contract handling withdraws needs mint permissions on the sBTC token, which adds complexity around inter-contract permissions. This assumes these are two separate contracts. If the sBTC token is only transferred back and forth, this permission problem is eliminated.

[netrome]

I like the idea of transferring the sBTC to the contract instead of eagerly burning it the way it is phrased here.

[netrome]

Based on feedback, I will update the description with the following changes unless anyone is opposed:

1. Introduce the notion "redeeming a deposit" to denote the act of consuming a deposit UTXO
2. Replace burning and re-minting of sBTC in the withdraw flow with transferring the sBTC to the .sbtc contract and redeeming it if the request is rejected. This also includes an extra step where the sBTC is burned once the withdraw accept transaction is mined on Bitcoin.

[8marz8]

I made some changes to the deposit flow here
Maybe we can keep the flows in this discussion topic and the separate deposit/withdrawal topics consistent (after we have a finalized version)

[netrome]

Good idea. Actually, I think we can close this discussion now, since everything here is covered by the more detailed deposit and withdrawal flow discussions. So we don't have to keep two separate descriptions of the same flows in sync.

[netrome]

Closing this discussion in favor of the more detailed descriptions of the deposit and withdrawal flows.