-
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
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
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. | ||
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
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...".