PoX-5 DocsQuestionnaire Flow
Draft decision flow for matching BTC, sBTC, and STX participants to useful PoX-5 guidance.
This page drafts a questionnaire for users who want to lock BTC, sBTC, or STX and understand which PoX-5 participation path fits them. The goal is not to recommend a product yet; it is to identify the user's context, route them to the right path, and show the most relevant tidbits.
Questionnaire
These questions are filters for the tidbit library. Use multi-select on position and access when comparing paths; migration supports multiple selections if you bridged journeys. pool is single-choice because it distinguishes native direct bonds and sBTC pool bonds (both 12-cycle bond terms) versus ordinary STX stacking pools. Omitting filters leaves blanks that may not satisfy conditional tidbits until you answer. Use Reset answers to clear.
1. Which participation path are you considering?
Bitcoin Staking defines three paths (see Waterfall whitepaper, section 5): a native BTC commitment paired with STX, an sBTC commitment paired with STX (in PoX-5, the sBTC path runs through whitelisted pools), or STX-only staking without a Bitcoin commitment. Bonds use a ~25,200 Bitcoin-block (~6 month) horizon with weekly distributions; STX-only follows the usual ~2,100-block (~2 week) signer cycles. Select multiple if you are comparing.
2. What PoX-5 bond or pool access do you have?
Direct native BTC protocol bonds target whitelisted institutional allocations (no pool intermediary). Roughly ~10% of Tranche 1 is reserved for retail-style access through about 1-3 whitelisted sBTC pool operators and their envelopes. STX-only staking needs no BTC-capacity whitelist. staking.stacks.co v1 emphasizes the native bond surface for whitelist partners.
3. How does a pool factor into your plan?
“Pool” names three different ideas: Native BTC + STX bonds have no pool intermediary (self-custodial L1 timelock + L2 lock). The sBTC protocol bond in v1 runs through about 1-3 whitelisted operators sharing the community slice of Tranche 1; the primary app offers a read-only directory and deep-links out to each operator for enrollment and custody. A 12-cycle bond locks sBTC + STX in the pool contract — not composable during the bond (unlike dual-stacking-era flexibility). STX-only can still use solo vs pooled stacking on the usual ~2-week signer cadence for T3; that ordinary pooling is not the 12-cycle sBTC bond pool.
4. How will locked STX be associated with a Stacks signer?
Every staker who locks STX — protocol bond or STX-only — must be tied to a signer for Nakamoto validation; signing weight is a function of locked STX, not BTC (whitepaper sections 5.2-5.3). You choose at enrollment and can change before a cycle prepare phase (cooldown removal in PoX-5 helps). Participant-app sketch: bond enrollment pulls from a whitelist signer list; STX-only uses an operator directory. Reward routing stays separate from this choice.
5. Existing PoX-4 staking or adjacent product enrollment?
Bitcoin Staking activates via SIP with a sharp cutover: PoX-4 stacking locks release at the fork (not backward compatible), participants re-enroll by path; launch scope cites ~1 BTC cycle lead time before first bond D0 plus a committed-STX threshold (e.g. 50M STX) staged with governance guidance. Bootstrap improvements include removing the stacking cooldown.
6. Are you shipping integrations on the PoX-5 stack?
Skips purely end-user journeys. Participant architecture today spans a Next.js surface, wallet adapters, indexer/API read models (period parameters, positions, payout/pause), PoX-5 contract calls on L2, L1 script construction via partner SDK helpers, multisig/program tooling where applicable, plus the Early Exit coordinator path documented for native bonds.