Technical Specifications
Consensus
Proof of Transfer (PoX) as described in SIP-007
Network will transition to Proof of Burn (PoB) as described in SIP-001 after 10 years. Learn more about Proof-of-Burn in SIP-001.
Threat model
51% of malicious Bitcoin mining power can reorg the Stacks chain or perform a double-spend attack
Chain can halt if Stackers cannot meet 70% consensus on block validity
Different actors and their roles
Stacks Miners package transactions into blocks and propose them to stackers
Stacks Holders may alter the calculation of block limits (subject to a miner veto) and may vote to disable Proof-of-Transfer rewards for a reward cycle.
Stackers validate and append blocks to the chain and validate sBTC deposit and withdrawal transactions
Proof of Transfer Mining
Coinbase reward schedule:
1000 STX/block for first 4 years
500 STX/block for following 4 years
250 STX/block for subsequent 4 years
125 STX/block in perpetuity after that
Coinbase rewards accumulate for "missed sortitions": If a Bitcoin block has no sortition (at height N), then any Stacks block mined in a subsequent sortition that builds off of any Stacks chain tip that existed at the penultimate sortition (at height N-1) may claim its coinbase. This encourages miners to keep mining even if Bitcoin fees are high.
Initial mining bonus: This is a special case of the above to incentivize early miners. Coinbase for all burnchain blocks between the first burn block height (to be chosen by independent miners as part of the Stacks 2.0 launch) and the first sortition winner accumulate and are distributed to miners over a fixed window (to be determined). For instance, say burn block height is 10,000 and first sortition is at block 10500 and distribution window is 100 blocks, then coinbase for the first 500 blocks (10,500 - 10,000) will be distributed evenly to miners who win sortition over the subsequent 100 blocks.
Reward maturity window: 100 blocks, meaning leaders will earn the coinbase reward 100 blocks after the block they successfully mine.
Block interval: Stacks blockchain produces fast blocks roughly every 10 seconds with a miner tenure change occurring every Bitcoin block
BTC commitment: Miners must commit at least 11,000 satoshis (5,500 sats / UTXO output); 2 outputs / block) to avoid "dust."
For more details, see Block Production.
Stacking
Stacking works in 2 phases
Prepare phase: In this phase an "anchor block" is chosen. The qualifying set of addresses ("reward set") is determined based on the snapshot of the chain at the anchor block. Length of prepare phase is 100 blocks. Stacking commitments need to be confirmed before this phase starts
Reward phase: In this phase miner BTC commitments are distributed amongst the reward set. Reward cycle length is 2000 BTC blocks (~2 weeks).
Two reward addresses / block, for a total of 4000 addresses every reward cycle. The addresses are chosen using a VRF (verifiable random function), so each node can deterministically arrive at the same reward addresses for a given block.
Stacking threshold: 0.025% of the participating amount of STX when participation is between 25% and 100% and when participation is below 25%, the threshold level is always 0.00625 of the liquid supply of STX.
Delegation: An STX address can designate another address to participate in Stacking on its behalf. Relevant section in SIP-007.
Pooling: STX holders that individually do not meet the Stacking threshold can pool together their holdings to participate in Stacking. To do this, STX holders must set the (optional) reward address to the "delegate address." For more details, see this reference.
Legacy, SegWit, Native Segwit, and Taproot addresses are supported
Accounts and Addresses
Transactions in the Stacks blockchain originate from, are paid for by, and execute under the authority of accounts
An account is fully specified by its address + nonce + assets
Address contains 2 or 3 fields: 1 byte version, 20 byte public key hash (RIPEMD160(SHA256(input))), optional name (variable length, max 128 bytes)
Two types of accounts: standard accounts are owned by one or more private keys; contract accounts are materialized when a smart-contract is instantiated (specified by the optional name field above)
Nonce counts number of times an account has authorized a transaction. Starts at 0, valid authorization must include the next nonce value.
Assets are a map of all asset types -- STX, any on-chain assets specified by a Clarity contract (for example NFTs) -- to quantities owned by that account.
Accounts need not be explicit "created" or registered; all accounts implicitly exist and are instantiated on first-use.
Transactions
Transaction types: coinbase, token-transfer, contract-deploy, contract-call, tenure-change.
Only standard accounts (not contracts) can pay transaction fees.
Transaction execution is governed by 3 accounts (may or may not be distinct)
originating account is the account that creates, authorizes and sends the transaction
paying account is the account that is billed by the leader for the cost of validating and executing the transaction
sending account is the account that identifies who is currently executing the transaction: this can change as a transaction executes via the
as-contractClarity function
Transactions can be batched or streamed into blocks. The behavior can be controlled by the anchor mode of a transaction. With streaming (microblocks), a faster confirmation time is possible.
Two types of authorizations: standard authorization is where originating account is the same as paying account. Sponsored authorization is where originating account and paying account are distinct. For instance, developers or service providers could pay for users to call their smart-contracts.
For sponsored authorization, first a user signs with the originating account and then a sponsor signs with the paying account.
Mempool limit for concurrent pending transactions is 25 per account
Pending mempool transactions will be garbage-collected 256 blocks after receipt. With 10 minutes target block time, this would equal ~42 hours
All transactions impacting account balance are atomic, a transfer operation can not increment one account’s balance without decrementing another’s. However, transactions that perform multiple account actions (for example, transferring from multiple accounts) may partially complete.
Transactions can include a memo string (max 34 bytes)
Last updated