This blog is now an archive. Find content from Hiro here and Stacks news and announcements here.

Highlights: Full Proof of Transfer Whitepaper Released

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.

This post summarizes the key changes to the original design, while SIP-007 remains the canonical specification. You can read the new paper at

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:

  1. Delegate Funds: Initiates the representee-delegate relationship
  2. 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:

  1. Indicating to the network how many STX should be locked up, and for how many reward cycles.
  2. Indicate support for a particular chain tip.
  3. 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).



Important disclaimer

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.

Forward-looking statements

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.

Diwaker Gupta

Diwaker Gupta

Diwaker joined Blockstack after Dropbox, where he spent 4 years in a variety of leadership roles across Engineering. Most recently, he led engineering for Intelligence at Dropbox — a group of 30+ engineers, PMs and designers — encompassing Search Infrastructure, Search Quality, Machine Learning, ML Platform and new product initiatives. During his tenure at Dropbox, Diwaker oversaw major infrastructure initiatives and product launches, including a new search engine for Dropbox.