This doc is deprecated, but includes notes and consideration on implementation details that are still useful. see Draft: Permissionless Channel Sequencer

A stake-lottery channel sequencer: a drop-in sibling of the existing round-robin sequencer. Instead of a fixed roster of accredited keys taking turns, anyone who stakes a note can win the right to write the next message to a channel, via a transparent per-slot lottery

Why we’re doing this

• Today, channel sequencing is permissioned. Who may write a zone’s next message is decided by round-robin over a fixed roster of accredited_keys — someone has to gatekeep that roster.
• We want it permissionless. Anyone can put up stake and compete for the write slot; no fixed roster, no gatekeeper.
• Selection is stake-weighted, which is Sybil-resistant for free — splitting your stake across many notes doesn’t improve your odds.
• It’s cheap. We borrow Cryptarchia’s existing Proof-of-Leadership lottery math; no new cryptography, no ZK, O(1) validation.
• Small blast radius. Only the “who may write this slot” check changes; the rest of the pipeline (signing, mempool, finality, readers) is untouched.

TL;DR — the proposed scheme

• A channel starts permissioned (round-robin). Its config multisig flips it to lottery mode via a CHANNEL_LOTTERY_CONFIG op.
• Anyone registers a stake: a CHANNEL_STAKE op binds a note (UTXO) → an Ed25519 posting key in a per-channel registry. Tokens are not locked — they stay spendable.
• Every slot, each staker locally computes a lottery ticket= Poseidon2(CHAN_LEAD_V1, epoch_nonce, slot, channel_id, note_id) and wins iff ticket < threshold, where threshold is stake-weighted (φ_approx over the channel’s staked total); Cryptarchia’s block-production math, minus the secret.
• A winner posts the message with a tiny LotteryWin proof (note_id + a signature). Validators recompute the same ticket and accept iff it wins — no prover needed (transparent lottery), and every L1 node checks it identically.
• Eligibility = matured + unspent. A stake matures ~2 epochs after registering (effective_from)[as a grinding defense] and the note must still be unspent at post time (liveness check).
• Liveness: if nobody posts, the winning threshold widens every posting_timeout slots until someone wins — the permissionless analogue of round-robin’s timeout takeover.
• Conflicts: multiple winners in a slot resolve by first-write-wins on the channel’s hash chain (losers retry on the new tip). No new machinery.
• Off-chain: the sequencer pulls (epoch, nonce) from GET /epoch/beacon, computes its own wins locally, and posts when it wins — a normal client with no special privileges.

The rest of this doc is the deep dive — each design axis, the decision we made, the alternatives, and why. * marks a change from today’s round-robin implementation.