staking guide
consolidated reference for the crosslink season one staking model. covers the cycle, the privacy tradeoff, the sequencing pattern, and the verification workflow. written for community operators who have been asking these questions in the workshop channel. honest about what the software does and does not do today.
the staking cycle
pow cycle is 150 blocks. the staking window inside that cycle is 70 blocks. during the window you can submit stake delegations. outside the window you cannot. a staking day only becomes active once the first finalized block inside the window lands, which is why a bft stall can delay it past the cycle boundary.
pow block time is roughly 30 seconds per block, so the window is about 35 minutes and the cycle is about 75 minutes. these are targets not guarantees. see /chain-health for live finality gap and signer health.
why bonds are separate
each orchard stake is its own separate on-chain action. staking 100 ctaz in a single window usually means submitting 10 sequential actions of 10 ctaz each, not one action of 100. consolidation into one action would require linking bonds on-chain, which compromises the privacy the design is built to preserve. upstream confirmed this during the workshop.
this is intentional. it is also a real ux friction. the right fix is tooling that generates many transactions more easily, not a consolidation primitive. see the upstream pr stack below for that tooling.
planning a sequence
the /stake/plan page takes a target amount and a bond size, returns the sequence count and pacing estimate for the 70-block window. use it before you open the staking panel so you know how many clicks are coming and whether you have time to finish before the window closes.
verifying you are on the canonical chain before you stake
a surprising amount of crosslink staking friction today traced back to nodes that were on a local sidechain without the operator knowing. staking into a sidechain is staking into nothing. before you stake, paste your current block height and hash into /sync-check and confirm "match" against our canonical node. there is a json api at /api/sync-check/<height>/<hash> if you want to script the check.
checking your own finalizer performance
every pub key on the active roster has a detail page at /finalizer/<pubkey>. it shows grade, rolling window rate, trend, last seen, and a signing pattern sparkline. one caveat surfaced earlier: absence from a given cert does not necessarily mean offline, because fat pointers pack only the quorum minimum signers and low stake finalizers get dropped from that packing more often. trend and last-seen are more reliable health signals than a single cert absence.
live roster at /finalizers, live participation at /finalizers/participation, chain-wide silent finalizer flag at /chain-health.
reading the chain graph
the /chain-graph page shows recent pow blocks on the left column and observed pos certs on the right column, with bezier curves connecting each pos cert to the pow block it finalizes. server rendered svg, no javascript. closest browser equivalent to the in-gui debug view. tip at bottom on both columns.
upstream tooling
the wallet crate helper for batching is at stake_orchard_to_finalizer_batch, added in pr #18 on the crosslink monolith s1_dev branch. the corresponding command line binary is in pr #20. both build clean under cargo check. once the stack lands upstream the batching friction becomes a one shot cli call rather than a sequence of gui clicks.
what this page does not cover
tax treatment of staking rewards depends on jurisdiction. community members have raised the complexity of tracking rewards across many bonds for tax purposes. this is a real concern, not one this page tries to answer. talk to a local accountant.
related: /why for the explorer design notes, /stake for delegation instructions, /params for protocol parameters, /chain-graph for visualization.