-
Notifications
You must be signed in to change notification settings - Fork 8
PoX-4 Draft #64
base: main
Are you sure you want to change the base?
PoX-4 Draft #64
Changes from all commits
a9b25bf
4771675
2e8cb3a
32d1180
943b281
80433e3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| # Clarity Contracts |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,57 @@ | ||
| # The PoX Contract | ||
| Explanation of the PoX contracts and it's public functions. It should be clear which functions a user would interact with, which ones are used by stackers, and which ones that are called as part of Stacks consensus (sBTC mint/burn). | ||
| The PoX contract, PoX-4, is the crux of stacking & therefore the general consensus between Bitcoin & Stacks. Miners on Bitcoin mine STX blocks by sending Bitcoin to a weighted lottery every block; on the Stacks side, users can "stack" their STX, every two weeks, for receive a part of the Bitcoin mining rewards. | ||
|
|
||
| TODO: [#9](https://github.com/stacks-network/sbtc-docs/issues/9) | ||
| The fourth version of this, PoX-4, introduces the logic necessary for a decentralized two-way Bitcoin-peg (sBTC). Specifically, it introduces the mechanics necessary for stackers to now evolve into signers: instead of stacking & passively receiving mining rewards, signers are now incentivized to help process (by signing) peg-ins(deposits), peg-outs(withdraws) & peg-transfers (handoffs). | ||
|
|
||
| PoX-2 documentation lives [here](https://docs.stacks.co/docs/clarity/noteworthy-contracts/stacking-contract). Below we introduce the likely *new* public functions that'll fold into PoX-4. First, though, we'll review the user types before hopping into the PoX-4 lifecycle which lasts ~2100 blocks & is split over five windows. | ||
|
|
||
|
|
||
| # User Types | ||
| **Observer** | ||
| Any active principal in the Stacks network, regardless of whether they hold STX or sBTC. They're not incentivized to *sign* anything, but, they are incentivized to throw a flag (aka start a penalty) if they see an issue with the protocol. Both Current & Registered Signers (below) are subsets of an Observer. | ||
|
|
||
| **Pre-Registered Signer** | ||
| For the developer release, a pre-registered stacker is an observer that wants to become a signer for at least one future cycle. | ||
|
|
||
| **Registered Signer** | ||
| For the developer release, this is a stacker that is now registered to be a signer (for the next cycle); they're either a pre-registered stacker or a current-signer. | ||
|
|
||
| **Voted Signer** | ||
| For the developer release, this is a registered signer that has now voted for a threshold wallet candidate (for the next cycle). | ||
|
|
||
| **Current Signer** | ||
| This is a principal that is a signer for the current PoX cycle. The previous cycle they registered & voted. This current cycle, as a current signer, they can also register & vote for the *next* cycle. | ||
|
|
||
|
|
||
| # PoX Lifecycle & Functions | ||
| Below we'll review the PoX lifecycle along with what public functions are avaiable to which user type. | ||
|
|
||
| **Disbursement [x]** | ||
| The disbursement window is the first window yet also acts as the final window of the **previous** cycle. This is when the PoX rewards from the *previous* cycle are disbursed to the previous signers. Since these rewards are disbursed in Bitcoin, someone [either Observer or any of the Signer user types] needs to verify the disbursements on Stacks. | ||
|
Comment on lines
+29
to
+30
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe we won't have a disbursement window in Nakamoto, as opposed to the developer release. Instead, PoX rewards are on a consensus level distributed to the signers directly as part of the block production operations. |
||
|
|
||
| Observer -> (penalty-pox-reward-disbursement ...) | ||
| Observer -> (prove-rewards-were-disbursed ...) | ||
|
Comment on lines
+32
to
+33
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could this be a mermaid chart? |
||
|
|
||
| **Registration [1600 - x blocks]** | ||
| Once disbursement has been proven on Stacks, the registration window opens (it's worth noting that this is the only window with a dynamic start height). This is the window when either pre-registered signers or current signers register to be a signer for the next cycle. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need to figure out how registration connects with the Nakamoto consensus rules. I assume this is also different in 1.0 as opposed to 0.1. |
||
|
|
||
| Pre-registered Signer -> (signer-register ...) | ||
| Current Signer -> (signer-register ...) | ||
|
|
||
| **Vote [300 blocks]** | ||
| After, registered signers can vote for the next cycle sBTC threshold/peg-wallet. The goal here is for registered signers to reach a 70% consensus on a candidate. | ||
|
|
||
| Observer -> (penalty-pox-reward-disbursement ...) | ||
| Registered Signer -> (vote-for-threshold-wallet-candidate ...) | ||
|
|
||
| **Transfer [100 blocks]** | ||
| Once the vote windows is over, a new threshold/peg wallet should've been - this is now the window when the current signers can transfer the pegged-sBTC balance to the new threshold wallet (aka passing on the responsibility). | ||
|
|
||
| Observer -> (penalty-pox-transfer ...) | ||
| Observer -> (balance-was-transferred ...) | ||
|
|
||
| **Penalize [100 blocks]** | ||
| The final window before the new cycle starts with the disbursement window; the main role here is for any observer to throw a flag (aka start a penalty) if they see an issue with the protocol. | ||
|
|
||
| Observer -> (penalty-balance-transfer ...) | ||
| Observer -> (penalty-unhandled-request ...) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| # The sBTC Token | ||
| The sBTC Token is defined as a [SIP-010 fungible token contract](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). | ||
|
|
||
| Content for this page: | ||
| - Tokenomics: How many tokens can be minted? Who can mint and burn the token? | ||
|
Comment on lines
+1
to
+5
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can save this page as a follow-up, alternatively reformulate it. We need to work this in with the rest of the documentation. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels a bit detached from the rest of the docs. We have already introduced sBTC here. I'd suggest something in the spirit of: "sBTC introduced the the forth version of PoX. In PoX-4 we introduce mechanics necessary for...".