This page describes a staking system that is built but not yet open. Yoalto runs genesis validators only: there is no registration path, no reward issuance, and nothing that raises slashing evidence. What follows is the mechanism as implemented, not an invitation to join a network.
Accounts never live on chain 0 — the partition map returns [1, 255] and never 0 — so a chain-0 applier cannot see your balance. Bonding therefore starts where your account is: nonce, fee and balance are checked there, and a pending staking op is written.
A keeper drains that queue into a system action on chain 0, which does the staking half. One queue and one system action serve bond, cancel and unbond alike, so the parts that must be right every time are written once rather than three times.
Newly bonded stake is inert until an epoch boundary activates it: no rewards, no slashing exposure, no voting power. Share-birth and weight-birth become the same event, which makes reward-sniping unrepresentable rather than merely detected.
Unbonding moves stake to a second pool and queues an exit. The boundary stamps the clock — the chain-0 leg has no trustworthy view of the current epoch, and a proposer-supplied one could shorten somebody's delay.
At each epoch boundary the chain runs exactly this sequence:
A wrong order here does not crash and consensus cannot catch it, because every node would be wrong identically. Slashing before rewards stops a validator earning on stake it is about to lose; activating after rewards is what keeps new stake from collecting a payout it was not present for. Each binding pair has a test named for it, verified by mutation.
A slash burns a fraction of both pools. Exiting stake stays liable for faults committed while it was active — excluding it would let a validator escape most of a penalty by having merely started to leave. It is also what makes a queued exit's payout fall automatically, with no per‑entry bookkeeping.
One validator runs three components — a reactor for consensus and execution, a broker for P2P, DKG and the random beacon, and an API server — as a pod cluster sharing one FoundationDB cluster. The 256 partitions are spread across pods, so capacity is added by scaling out rather than by moving to a bigger host.
| Component | Status | Notes |
|---|---|---|
| Staking state machine | Shipped | two pools, shares, boundary pipeline |
| Epoch rotation | Shipped | genesis seeding, boundary, gossiped EpochCerts |
| DKG group key on chain | Shipped | committed by an independent path |
| Validator registration | Designed | no applier; needs proof-of-possession |
| Commission setting | Designed | nothing sets CommissionBps yet |
| Rewards and payouts | Designed | fees are burned; no issuance configured |
| Slash detection | Designed | penalty applies correctly; nothing raises evidence |