A note is eligible for PoS participation when it has been aged (between 5 and 10 days) and is unspent. Aging is measured against the per-epoch ledger snapshot: a note first appears in the snapshot of the epoch following the one in which it was minted, and becomes PoS-eligible when the epoch following the snapshot starts.
Channel bridge funds are currently stored as a per-channel scalar token amount. Because this scalar is not a note, it cannot participate in PoS. The goal of this design is to represent bridge funds as actual notes on the ledger so they can.
Ownership vs participation. Bridge funds remain owned by the channel, not by the sequencers. What is split across sequencers is PoS participation power: assigning a derived note to a sequencer's zk_id grants that sequencer the right to create PoLs from it, but no right to transfer or spend it.
Constraints.
Out of scope. What the channel does with PoS rewards earned on bridge funds (reduced fees, redistribution, retained by sequencers) is a channel-level policy concern, not addressed here.
The on-ledger representation of a channel's bridge funds must satisfy two conditions: (a) notes are owned by individual sequencer keys, since PoS participation is per-note, and (b) value is distributed symmetrically across the channel's sequencer set, so that no single sequencer dominates the channel's stake. Together, these mean each unit of channel value, when committed to the ledger, becomes a group of equal-value notes minted in parallel, one per sequencer. We call such a group a slice.
A slice consists of K notes of identical value, differing only by which sequencer's pubkey (their zk_id) they are issued to, where K is the size of the channel's sequencer set at the slice's mint time.
Default state. A channel may exist without any sequencer configuration if no explicit channel-creation operation has set its sequencer list. In this state S is empty (N = 0), no slices are minted, and the channel operates in floating-balance mode only. Deposits and withdraws function normally, but bridge funds do not contribute to PoS until the channel is explicitly configured with a sequencer list holding zk_id.
Sequencer identity. Slice notes are derived per-sequencer using the sequencer's zk_id. This is distinct from the sequencer's EdDSA pubkey, which is what the channel-creation message carries. The path by which the channel obtains each sequencer's zk_id can be done in the Channel Config operation.
Note restrictions. Slice notes participate only in the channel's deposit and withdraw flows. They cannot be transferred, spent, or pledged as service stake. PoL creation from a slice note is permitted (see PoS participation below).
Service-stake exclusion. Channel slice notes cannot be used as the stake backing any service declaration. They are reserved for the channel's bridge accounting and for PoL creation only. Any SDP-level mechanism that lock notes as service stake must reject notes owned by a channel. (Note ownership is by the sequencer's zk_id, so an SDP check on raw ownership is not sufficient; the check must recognize channel-slice provenance, e.g. via NoteId derivation )
Channel state. Because NoteIds are deterministic from (channel_id, epoch_number, sequencer_zk_id) (see NoteId derivation) and the ledger already maps NoteId → Note, the channel itself does not need to duplicate note data. It maintains:
M : (epoch_number, zk_id) → NoteId recording which slice notes currently exist for this channel.F.S.