In February, we introduced Proof of Transfer, a novel mining mechanism that uses the proof-of-work consensus mechanism of an established blockchain to bootstrap and secure new blockchains. Since the draft whitepaper (v.02) was released, developers throughout the ecosystem have been working toward adding Proof of Transfer to the Stacks 2.0 Testnet. As work has progressed and we’ve gathered feedback and new information, there have been a few important design decisions and updates to the PoX mechanism.
Participation-based reward threshold
The original whitepaper proposed a minimum threshold to participate in Stacking — 0.02% of the total unlocked supply of STX. Presently, this maps to approx. 94K STX, which understandably (though deliberately) is a high threshold for many STX holders.
The 0.02% requirement now only applies if 100% of the unlocked STX are participating in Stacking. At lower participation levels, the protocol defines two lower thresholds. If fewer than 25% of unlocked STX are participating, the threshold falls to 0.005% (1/20,000th) of total unlocked supply. Between 25% and 100% participation, the reward threshold adjusts to fill in as many reward slots as possible. So the threshold T is roughly 1/5,000th of the unlocked supply and a wallet controlling W STX can include W/T addresses in the reward set.
Native support for Delegation
The process of delegation allows a Stacks wallet address (the represented address) to designate another address (the delegate address) for participation in Stacking. The Stacking mechanism, proposed in SIP-007, is a scheme that rewards Stacks (STX) holders who participate and add value to the Stacks network. Delegation enables new avenues (e.g. “pools”) for collective participation in Stacking even if individual STX holders do not meet the minimum threshold.
To facilitate this, the protocol introduces two new transaction types:
- Delegate Funds: Initiates the representee-delegate relationship
- Terminate Delegation: Terminates a previously established delegate relationship.
Both types of delegation transactions must be signed by the represented address. These are transactions on the Stacks blockchain and will be implemented via a native smart contract loaded into the blockchain with the Stacks 2.0 genesis block.
Stronger fallbacks for resiliency
To discourage certain types of attacks, we’ve updated the protocol to include a fallback path for Stacking-related transactions. Stacking participants must broadcast signed messages for three purposes:
- Indicating to the network how many STX should be locked up, and for how many reward cycles.
- Indicate support for a particular chain tip.
- Specifying the Bitcoin address for receiving Stacking rewards.
These messages may be broadcast either on the Stacks chain or the Bitcoin chain — this should deter bad actors from attempting to attack transactions on the Stacks chain since the transactions would then use the Bitcoin chain instead, which is arguably the most secure blockchain in the world today (based on resources required to mount a successful attack).
If broadcast on the Stacks chain, these messages must be confirmed on the Stacks chain before the anchor block for the reward period. If broadcast on the Bitcoin chain, they may be broadcast during the prepare phase, but must be included before the prepare phase finishes. You can review the particulars of the reward cycle phases in the whitepaper.
If you’re interested in participating, either as miner or Stacker, we encourage you to play around with the testnet! The current testnet (Phase 1: Neon) implements basic mining functionality, while a full PoX mining implementation with the improvements described above are currently targeted for Phase 3 (Krypton).
Blockstack PBC is not registered, licensed, or supervised as a broker dealer or investment adviser by the Securities and Exchange Commission (SEC), the Financial Industry Regulatory Authority (FINRA), or any other financial regulatory authority or licensed to provide any financial advice or services.
This communication contains forward-looking statements that are based on our beliefs and assumptions and on information currently available to us. In some cases, you can identify forward-looking statements by the following words: “will,” “expect,” “would,” “intend,” “believe,” or other comparable terminology. These statements involve risks, uncertainties, assumptions, and other factors that may cause actual results or performance to be materially different. We cannot assure you that the forward-looking statements will prove to be accurate. These forward-looking statements speak only as of the date hereof. We disclaim any obligation to update these forward-looking statements.