PoX-4 Draft #64
PoX-4 Draft #64
Conversation
|
|
There was a problem hiding this comment.
Sorry to butcher this review. I think we're learning how much we don't know about Nakamoto PoX. I suggest that we're brushing up these docs and moving them as a sub-section of the 0.1 release docs instead of here as part of the final release. We can then collaborate more closely to document how the 1.0 contracts will look.
|
|
||
| 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). |
There was a problem hiding this comment.
The fourth version of this, PoX-4, introduces the logic necessary for a decentralized two-way Bitcoin-peg (sBTC).
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...".
| **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. |
There was a problem hiding this comment.
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 ...) |
There was a problem hiding this comment.
Could this be a mermaid chart?
| Observer -> (prove-rewards-were-disbursed ...) | ||
|
|
||
| **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.
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.
| # 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? |
There was a problem hiding this comment.
We can save this page as a follow-up, alternatively reformulate it. We need to work this in with the rest of the documentation.
|
Is this still valid? This PR feels stale. |
Below are notes for the upcoming PoX-4 updates & all the user-types & life-cycles involved with the changes.
Specifically this PR includes a detailed overlook into which users call which functions during the five following windows:
A tiny amount of details are undefined / up for change as this is what we currently believe will fold into PoX-4, we've yet to finalize & sign-off on that design.