Staking Guide
How Shekyl staker rewards are designed, why claims are used instead of direct coinbase fan-out, and how rollout is phased for safe activation.
Core Decision
Claim-Based Reward Disbursement
Shekyl uses a claim-based model for staker rewards rather than direct coinbase fan-out. Rewards accrue to a deterministic accounting pool, then eligible stakers claim with explicit transactions.
Why Claim-Based
Keeps coinbase transactions compact and deterministic
Avoids variable-size miner transaction growth tied to staker-set size
Decouples payout cadence from block template construction
Improves compatibility during hardfork rollout
Economic Flow
Per-Block Accounting
Consensus computes staker emission share plus staker fee-pool allocation from adaptive burn components.
Accrual Pool
Computed reward amounts accrue to a global staker reward accounting pool.
Claim by Eligible Stakers
Eligible staked outputs claim accrued rewards using explicit claim transactions.
Implementation Phasing
HF1 Baseline
- • Track `stake_ratio`
- • Compute emission and burn splits
- • Defer live claim transaction grammar to follow-up activation
Claim Activation Hardfork
- • Add claim transaction/output grammar
- • Add accrual and claim validation paths
- • Expose wallet RPC for claim estimation and submission
Shard Visualization
Stakers who archive chain shards will see each shard as a unique, reproducible visual in the wallet — a human-readable fingerprint of that window of chain history. The samples below are pre-rendered from our candidate compositor using illustrative fake-chain data.
Pre-rendered samples from the candidate compositor — illustrative fake-chain data, not live mainnet shards.
Each archival staking shard will have a unique visual derived deterministically from its public chain content. Two stakers archiving the same shard see the same image; different shards look different. That gives you a quick visual integrity check alongside cryptographic verification — and makes rare shards easy to recognize at a glance in the wallet.
The current candidate formula layers two difference composites: a round-ish foreground (aperiodic tile ⊖ phyllotaxis) over a crystalline background (truchet ⊖ crystalline), then merges those with a final difference pass. Palettes and blend strength come from the shard hash and aggregate chain statistics — fixed algorithms, variable aesthetics.
Across chain regimes
Same regime, different hash
Regime labels describe aggregate chain character; the shard hash still drives the final look. These two genesis-regime samples share a label but not an image.
Operator Notes
No immediate coinbase format change is required for HF1. Reward accounting metrics should be exposed in node RPC before claim activation so economics can be validated in production conditions.