Shekyl Stats

Refreshing...

Network

Connected
Seed Nodes Active
--

Chain

Current Block
0
Target Height
0
Top Block Hash
--
Block Time Target
2 min

Rewards

Last Block Reward
0.000000 SKL
Difficulty
0
Estimated Hash Rate
0 H/s

Supply

Circulating Supply
--
Remaining Supply
--
Total Burned
0.000000 SKL

Economics

Release Multiplier
0
Burn Rate %
0

Staking

Stake Ratio
0
Staker Pool
0.000000 SKL
Staker Emission Share
0
Total Staked
N/A
Staking Height
N/A
Tier 0 Lock Blocks
N/A
Tier 1 Lock Blocks
N/A
Tier 2 Lock Blocks
N/A

Protocol

Transaction Format
TransactionV3
Membership Proof
FCMP++
Spend Auth
Ed25519 + ML-DSA-65
Confidentiality
Stealth + BP+

Node

TX Pool Size
0
Database Size
0 B
Node Version
--
Sync Status
Syncing

Staking Guide

How Shekyl staker rewards are designed, why they are claimed rather than paid in the coinbase, and how the wallet does that claim for you.

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. From v3.1.0-alpha.8 the wallet submits the emission-claim transaction itself once each reward epoch settles — there is no claim button, and the claim RPC methods are refused. Rewards below the compiled-in fee floor wait until they cover the fee.

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.

The wallet claims automatically

Once each reward epoch settles, the wallet submits the emission-claim transaction. Rewards too small to cover the fee wait and aggregate. Nothing the user initiates is blocked by a background claim.

From genesis

Archival staking is the model

  • • Stakers post collateral, hold chain shards, and answer retention challenges
  • • Emission claims are a consensus transaction the wallet submits unattended
  • • There is no separate claim-activation hard fork and no wallet-RPC claim method

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.

Design preview

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 tilephyllotaxis) over a crystalline background (truchetcrystalline), 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

Sample shard visual for an early-chain window (design preview, not live mainnet data)
Early chain50f27e5f6e1f0f6b
Sample shard visual for a coinbase-heavy chain window (design preview)
Coinbase-heavy7198050d15341649
Sample shard visual for a low-activity chain window (design preview)
Low activity63a99039ed1dbbfd
Sample shard visual for a busy chain window (design preview)
High activity7b8e373875827782
Sample shard visual for a stake-heavy chain window (design preview)
Stake-heavy7b6be3d079a46e05
Sample shard visual for a high-value-dispersion chain window (design preview)
High value dispersionaf48555a394cf46b

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.

Genesis-regime sample A (design preview)
Genesis · hash …0f6b
Genesis-regime sample B, different hash (design preview)
Genesis · hash …ae00
Read the shard visualization spec

Operator Notes

No immediate coinbase format change is required. The wallet claims on a cadence driven by chain progress; operators who want the shard-holding side of staking should start from the Staker-Operator Guide.