[heifner]

Closes WIRE-367.

Producer rank stops being a governance write and becomes position in a score-ordered index, and producer pay stops being a per-round threshold and becomes per block produced. A candidate could previously complete every self-service step and reach OPERATOR_STATUS_ACTIVE yet never be scheduled, because rank was only ever written by hand.

The on-ramp this completes

A stranger can now bond on Ethereum and Solana and be scheduled, with no vote and nobody's approval. Only the bootstrapped flag needs the registry's authority; everything else is self-signed:

1. sysio.authex::createlink on each chain, so an outpost deposit is attributable to the WIRE account.
2. sysio.opreg::regoperator(account, OPERATOR_TYPE_PRODUCER, is_bootstrapped = false).
3. Bond on the outposts themselves. The deposits ride OPP to the depot; once every required chain is at its minimum the operator flips ACTIVE and is rescored on the bond it posted.
4. regproducer + regfinkey.
5. The next ranked rebuild schedules it by position.

flow-producer-registration drives that path against real outposts. It registers the producer and its finalizer key before any collateral and asserts no schedule ever names it, so entry is demonstrably driven by the bond; at the end it withdraws the Ethereum bond and asserts the producer leaves. In between the account produces a real block — also the first end-to-end coverage of regfinkey → set_proposed_finalizers.

New: docs/becoming-a-block-producer.md, the operator-facing guide.

What changed

• rank_score replaces rank — two tier bits (healthy / bootstrapped / demoted) over a weighted composite. Tier always beats score.
• Three live factors — collateral (linear, uncapped, min across required pairs), participation, and snapshot attestations at a tenth of collateral's weight. relay / api / benchmark ship at zero pending an attestation path.
• Missed rounds are a model, not a counter. The old counters recorded presence only, so absence left no trace. onblock now walks the schedule between the previous block's producer and this one's, scoring each round once. A round is served at min_blocks_per_round or better; three unserved in a row demotes.
• Recovery is decided by the live schedule. Still scheduled, a producer recovers by serving a round. Once dropped, regproducer is the door back and clears the streak with the flag — it is refused as a pardon while the producer still holds a slot, or an absent operator could clear the flag on a timer between each demotion and the next rebuild.
• Two predicates. is_schedulable (active row, ACTIVE operator, finalizer key) governs ranking, pay and snapshot eligibility. is_eligible_operator drops the key requirement and is what peer discovery walks, seeded from the chain's own active schedule.
• Walks are bounded by construction. regproducer is permissionless, so compute sinks every unschedulable producer into the demoted tier, which sorts last — a walk that breaks there has seen every schedulable producer, with max_rank_walk_rows as backstop.
• Bounded rescore drain. A weight or collateral-minimum change invalidates every stored score, so onblock drains a bounded cursor rather than rewriting an unbounded table inline. The rebuild does not wait for it: ranking converges over a few ticks, because deferring would let anyone freeze the schedule and finalizer policy by registering. The drain also re-derives the demotion flag from the streak, so a changed threshold reaches producers already past it.
• setscorecfg validates its fields, including rejecting a min_blocks_per_round above the round size.

Pay is per block produced

The old per-round threshold is gone, along with eligible_rounds, current_round_blocks, last_block_num and the global total_unpaid_blocks. onblock increments unpaid_blocks. payepoch splits the producer pool into active and standby slices (standby_bps, default 800):

• Block pay is active_pool × blocks / divisor, the divisor being the period's nominal slots raised to blocks actually produced when a period runs long. A missed block is not counted, so its pay stays in the treasury rather than going to whoever did show up.
• Standby retainer — positions 22 through standby_end_rank draw a per-position share decaying linearly. A vacant position pays nobody.
• Blocks produced are not forfeited. A producer that is not payable when the walk reaches it is neither paid nor reset, and keeps its count for the first payepoch at which it is payable. Settling does require being back within the walk's reach.

Snapshot credit is stamped with the pay period that earned it and expires at the boundary rather than being consumed on leaving the walk. One bound is accepted rather than swept for: the walk breaks at the demoted tier and at max_rank_walk_rows, so a row past either is not reset, and a schedulable row past the ceiling keeps a stored key carrying the previous period's term until something rescores it. Reaching that takes 500+ ranked schedulable producers; a demoted row's stale term is inert, since every walk breaks at that tier and nothing reads the order within it, and an inactive row is unscored() and carries no term at all.

One shape is deliberate: a miss short of demotion still costs a slot if it drops the producer below the active set. More collateral outranks the penalty, and serving clears it. A producer that missed is worth less than one that did not, and the way back is an explicit assertion of readiness rather than the passage of time.

Test cost

Making producers schedulable made the snapshot-attestation fixture expensive: with finalizer keys registered, the node signs and verifies a vote on every block of the block_spacing advance. The fixture now builds that history in its constructor, before the system contract is deployed, so those blocks run no contract code. The suite is also its own ctest entry.

	before	after
whole binary, single ctest entry	2337s	—
CI form, parallel wall clock	—	950s
margin vs the 2700s TIMEOUT	1.16×	2.84×

WIRE-382 tracks making block_spacing configurable, which retires the advance entirely.

Validation

• contracts_unit_test and contracts_snapshot_attest_test, with cases covering each review round: pay that rounds to zero keeps its blocks, an unserved round counts against the producer, a raised collateral minimum sinks the producers now below it, a bonded producer without a finalizer key holds no rank, regproducer cannot pardon a producer that still holds a slot, and a changed miss threshold reconciles an existing demotion.
• producer_rank_test on a live 5-node cluster, covering demotion and recovery — what a single-process contract test cannot reach. It stops a scheduled producer's node, asserts demotion at exactly the threshold with no miss charged to the producers that kept going, and asserts the min_schedule_size floor retains it rather than publishing a short schedule.
• e2e gate 34283755789, including producer-registration and emissions-soak — the latter being where genesis producers newly drawing producer pay would have surfaced.

Stack

Merge first. Downstream, in order:

1. chore(sdk-core): regenerate SysioContractTypes for the producer-score ABI (WIRE-367) wire-libraries-ts#80 — regenerated ABI types
2. feat(cluster-tool): per-producer finalizer keys, genesis producer registration, and the producer-registration flow (WIRE-367) wire-tools-ts#94 — harness + the producer-registration flow

Note for whoever merges: this repo's ruleset requires approval from the cicd team specifically, and auto-merge is disabled repo-wide.

[huangminghuang]

[P1] Re-registration can erase every missed round without proving liveness

The existing-row upsert clears both is_demoted and consecutive_missed_rounds on every regproducer or regproducer2 call. Both actions are repeatable with only producer authorization and accept the same key, so an offline but transaction-capable operator can resubmit after every one or two misses, or immediately after demotion, and restore the healthy tier without producing a block. That bypasses the core demotion mechanism indefinitely. Please make block production the only way to clear the streak, or introduce a recovery state, proof, or cooldown that cannot be reset repeatedly.

[huangminghuang]

[P1] Residual on b569e00: re-registration still erases the miss-rate evidence\n\nThe latest change preserves consecutive_missed_rounds, but every repeatable regproducer/regproducer2 still zeros rounds_in_window, missed_rounds_in_window, and miss_window_open_ms. A producer that alternates misses with produced rounds, or chronically delivers short rounds (which do not advance the consecutive streak), can re-register before the minimum rate sample and remain eligible indefinitely. Please reset the window only on a genuine demoted-to-recovered transition, not on an ordinary active-row upsert.

[heifner]

Confirmed and fixed in 4fce5f4 — and it was worse than described. Short rounds feed the rate gate ALONE (a short round deliberately does not advance the consecutive counter), so a producer delivering a fraction of every round accrues evidence only in the window, and a free repeatable wipe left none of it. The cron loop the streak was protected from applied in full to the rate gate.

The window now resets only on a genuine demoted-to-recovered transition. Two tests: regproducer_does_not_launder_the_miss_window drives the actual loop — alternate miss/produce, re-register after each — and asserts the gate still fires; regproducer_clears_the_window_of_a_demoted_producer pins the reset that IS kept, since a demoted producer is unscheduled, observes no rounds, and could otherwise never improve its recorded rate.

[huangminghuang]

[P1] Healthy-tier rows do not bound these scans

An ACTIVE producer operator remains in the healthy tier even without a finalizer key, so this loop can skip an arbitrary number of bonded but unschedulable rows before finding 21 producers. Producer admission is permissionless and max_available_producers is stored but not enforced. The same assumption appears in payepoch, which walks every non-demoted row. Enough such rows can exhaust action CPU during the periodic onblock rebuild or inline epoch payout. Please enforce a hard safe bound on active candidates or paginate and decouple these walks.

[huangminghuang]

[P2] The new hard ceiling makes debt beyond row 500 permanently unreachable\n\nThe CPU bound fixes the unbounded scan, but every payepoch restarts from prodrank.begin(). Registration/ACTIVE producer count is not otherwise capped, so a producer can earn blocks while top-21 and then be displaced below row 500 before payout. While ordering stays stable, no later payout reaches or clears that earned debt; retaining unpaid_blocks therefore does not provide eventual settlement. Please paginate with a persistent cursor or settle block debt through a separately bounded index.

[heifner]

Confirmed, and accepted with the promise corrected rather than the bound changed.

The reasoning is economic: a producer bonded and unpaid does not stay bonded — the capital moves to where it earns — so a standing population of 500+ ranked-but-unpaid producers is not a state the system settles into. Past what is paid there is nothing to look at.

Worth separating out the common case, which is not rank at all: a temporarily unschedulable producer (key rotation, transient opreg UNKNOWN) sits in the demoted tier that the walk breaks at, and its carried blocks settle at ANY position once it is schedulable again. The genuinely unreachable case is narrower than the general one — earning while top-21, then being displaced 500+ positions before the next payout, which needs a mass onboarding between two payouts rather than a slide.

So 4fce5f4 drops the "nothing is ever forfeited" claim from the operator guide. It now says blocks produced are not forfeited, and states plainly that settling held blocks requires being back within the pay walk's reach.

[huangminghuang]

[P1] Preserve actual schedule members in peer discovery

This result is based only on eligible-operator rank, not the active or pending schedules. A producer demoted but retained by the four-member schedule floor is omitted even though its next block is supposed to clear demotion. Conversely, 30 higher-scoring ACTIVE producers without finalizer keys can fill the response even though none can enter the ranked schedule. Because a nonempty cache refresh removes omitted keys, this can evict real scheduled BPs and disable or reject automatic BP gossip. Please seed and deduplicate active and pending schedule members first, then fill remaining capacity with ranked candidates.

[huangminghuang]

[P1] Reevaluate existing operators before activating new collateral minima

setconfig writes the new requirement vectors and only asks sysio.system to rescore. It never reevaluates existing operator statuses. Raising a minimum therefore leaves a now-undercollateralized producer ACTIVE; the score sweep lowers its composite but compute and is_schedulable still trust that stale status, so it can remain healthy, scheduled, and payable indefinitely. Lowering a minimum likewise leaves newly qualified UNKNOWN rows excluded. Please stage the config behind a bounded eligibility sweep or make authoritative consumers check the live minima.

[huangminghuang]

[P1] Residual on b569e00: the live producer ratio fixes only part of this\n\nA raised producer minimum is now caught by producer_score, but compute checks the stored ACTIVE status before evaluating that ratio. Lowering the minimum therefore cannot promote existing UNKNOWN producers. Batch operators and underwriters have no equivalent live-minimum check, so raising their minima leaves underbonded rows ACTIVE and still eligible for epoch selection or underwriter authorization until some balance mutation happens. The config change still needs a bounded status reconciliation or authoritative live checks for every role.

[heifner]

Confirmed on all three counts. The decision for this PR is to accept and document rather than reconcile, so flagging that explicitly rather than marking it fixed.

One correction to the finding, though: the underwriter half is narrower than it looks. sysio.uwrit::try_select_winner refuses any candidate whose LIVE available_via_mirrors does not cover src + dst, so every underwritten leg stays collateral-backed at its real value — the minimum is an eligibility floor, not a capacity control. The exposure that remains is the batch-operator one: an underbonded op keeps serving in groups with a smaller slash-at-risk than governance just set.

Accepted because that exposure is one role in one direction, self-corrects on any balance movement (reevaluate_eligibility fires on deposit, withdraw, withdraw-flush, slash and terminate), and is auditable off-chain by comparing balances against op_config. The operator guide now states that a minimum change binds new registrations immediately and existing operators on their next balance movement, and that a lowered minimum needs a balance touch to take effect.

A bounded reconciliation sweep in opreg following the flushwthdw shape is the right permanent fix for all three roles and both directions — but it is opreg work rather than producer ranking, and deciding what happens to an operator whose status flips mid-epoch deserves its own review.

[huangminghuang]

[P2] Do not publish ranks from mixed score generations

Only 32 primary-key rows are rescored before update_ranked_producers consumes the secondary index. The comment says tiers make the partial state safe, but composite order selects the top 21 and standby positions within each tier. For example, reducing collateral_weight to zero makes the first batch lose that term while untouched rows retain their old inflated scores, so schedules, retainers, snapshot eligibility, and peer ranks match neither configuration for multiple ticks. Please stage scores by generation and atomically activate them after the sweep, or defer every rank consumer until one coherent generation is ready.

[huangminghuang]

[P2] Apply a lowered miss threshold to existing streaks

setscorecfg stores the new max_consecutive_missed_rounds and opens only a score sweep. The sweep recomputes participation, but tier_for still uses the persisted is_demoted flag. A producer whose streak already meets the lower threshold can therefore stay healthy indefinitely, especially after falling outside the schedule where no later missed-round event can flip the flag. Please reconcile streak-to-demotion state during the sweep, with explicit semantics for threshold increases.

[heifner]

Fixed in 9c19796. The ordering was what blocked this: while regproducer pardoned a producer but preserved its streak, re-deriving the flag would have re-demoted that producer on the very next sweep, and — unscheduled — it could never produce the block that was its only other way out. Gating the pardon on schedule exit let the pardon clear the streak too, and the sweep now re-derives is_demoted from warrants_demotion(streak, weights).

Semantics are symmetric, per your point about threshold increases: the streak is the evidence and the flag caches it, so a lowered limit binds on streaks that already breach it and a raised one releases the rows now under it. One expression, both directions.

a_raised_miss_threshold_reconciles_an_existing_demotion covers it on a producer carried off the schedule with its demotion intact — the case with no other remedy, since off-schedule it observes no rounds. It exercises the raise direction deliberately: a producer with a live streak is by definition still scheduled, so it serves a round and resets the streak before any sweep can run, which leaves the lowered direction with no deterministic setup in this fixture.

[huangminghuang]

[P2] Keep block entitlement when integer pay rounds to zero

A producer with unpaid blocks is added to to_reset even when active_pool multiplied by blocks divided by slot_divisor rounds to zero, so the later reset erases those blocks without crediting anything. A valid 60-second period with a one-unit active pool and 120 nominal slots demonstrates the loss. This contradicts the stated no-forfeiture invariant. Please retain the blocks or carry a per-producer fractional remainder until the entitlement is representable.

[huangminghuang]

[P1] The zero-rounding fix can now over-distribute the active pool\n\nOn b569e00, first-pass-zero rows are removed from slot_divisor but the final loop still pays them if that smaller divisor makes them nonzero. A reachable carried-debt state with nominal_slots=120, active_pool=1, and two payable rows holding 120 blocks each first removes all 240 blocks, obtains a final divisor of 120, and then credits both rows 1: two units of claims from a one-unit pool. Please keep first-pass-excluded rows carried for this payout, or recompute the payable set while enforcing the pool total.

[heifner]

Confirmed — your arithmetic is exact, and this one was mine. Fixed in 4fce5f4: the first pass now DECIDES the payable set and the second only prices it, so a row excluded from the divisor is excluded from payment and its blocks carry to the next payout.

The comment I had written argued for the bug ("a row that crosses back over the threshold is simply paid, which is the outcome we want") without accounting for those blocks no longer being in the divisor. Test a_tiny_pool_never_credits_more_than_it_holds asserts a one-unit pool can never credit more than one unit.

[huangminghuang]

[P2] This withdrawal path cannot release the outpost bonds described above

The guide tells operators to bond on Ethereum and Solana, but sysio.opreg::withdraw is hardcoded to the WIRE balance on WIRE_TOKEN. Following this instruction records an insufficient-balance failure and leaves the outpost collateral untouched. Please direct operators to each holding outpost withdrawal entry point, which then reaches withdrawinle on WIRE.

[huangminghuang]

Additional findings on the current head. These inline comments cover issues not already tracked in the existing review threads; residual issues from those threads are posted as replies there.

[huangminghuang]

[P1] Add an upgrade path for existing producers and global rows

This widens persisted rank from uint32_t to uint64_t in place and replaces the existing producer tail. The same header also removes total_unpaid_blocks from the middle of the persisted global row before appending new fields. KV deserialization is positional, so rows already on chain will consume neighboring bytes as the new fields and/or underflow; onblock reads global immediately, making a populated-chain deployment capable of aborting block processing. Please add an explicit migration or a versioned compatibility decoder rather than reading the old bytes through the new structs.

[heifner]

Nothing deployed, we do not need an upgrade path.

[huangminghuang]

[P1] Migrate emitcfg instead of inserting into its serialized layout

standby_bps is inserted before the existing epoch_log_retention_count and pay_cadence_epochs fields. An existing row therefore shifts those two values and is two bytes too short for this decoder. Please use an explicit migration/versioned representation (or an actually compatible tail-extension strategy) before rollout.

[heifner]

Nothing deployed, we do not need an upgrade path.

[heifner]

Same ruling as the sibling thread — @heifner: nothing deployed, so there is no existing emitcfg row whose fields could shift.

[huangminghuang]

[P2] Gate snapshot credit on current schedulability, not only is_demoted

unregprod leaves the provider mapping and is_demoted == false, so the retained provider can still vote and this helper credits an inactive producer. The rescore parks that row below the pay walk, where the counter is never reset, and a later regproducer restores it with service credit earned while parked. Losing the finalizer key or opreg eligibility has the same lifecycle. Please test/gate the live schedulable predicate here, or consume credit on every transition out of the walk.

[heifner]

Fixed in 4fce5f4 — you are right that is_demoted was the wrong predicate. unregprod parks a row by clearing is_active and letting the rescore sink it by TIER, so the flag stays false and every parked producer was still credited; losing a finalizer key or opreg eligibility did the same. The gate is now producer_rank::is_schedulable against the live row.

Test a_parked_producer_earns_no_snapshot_credit (991f955) parks a producer, keeps it voting into a quorum, and asserts it earns nothing while the still-schedulable producer is credited.

[huangminghuang]

[P2] Preserve nominal slots across epoch-duration changes

This applies the current epoch duration to every epoch accrued in the open pay period. For example, a two-epoch period containing a 60-second epoch (120 slots) followed by a 120-second epoch (240 slots) has 360 nominal slots, but this computes 480 and pays only 75% of the active pool under full production. Persist accumulated nominal slots per accrual, or settle the period before applying a duration change.

[heifner]

Fixed in 4fce5f4 by accruing the divisor the same way the pool already is. t5_state gains pending_nominal_slots; accrueepoch adds each epoch's slots at the duration in force for THAT epoch, and payepoch consumes and resets it alongside pending_emission_amount.

Test nominal_slots_accrue_at_each_epochs_own_duration (991f955) accrues one 60s epoch, doubles the duration, accrues a second, and asserts the total is 120 + 240 rather than the 240 x 2 the payout-time formula produced.

[huangminghuang]

[P2] Reject min_blocks_per_round above the fixed round size

The standard producer round has 12 slots, but this config path accepts any uint32_t. Setting 13 makes every fully produced standard round count as short and eventually rate-demotes every healthy producer. Please retain zero as the disabled value and otherwise require the threshold to be at most blocks_per_round.

[heifner]

Fixed in 4fce5f4: setscorecfg now checks min_blocks_per_round <= blocks_per_round (12), with zero still the disabled spelling. Covered by setscorecfg_rejects_a_configuration_that_inverts_the_rate_gate, which asserts 13 is rejected and both 12 and 0 accepted.

Fair catch — that action gained five other bounds in the same commit that introduced this field, and I missed the one field the commit added.

[huangminghuang]

[P3] Align the guide with the implemented rescore behavior

The current implementation intentionally rebuilds the schedule after each partial rescore drain and accepts mixed-generation ordering while the sweep converges. This sentence promises the opposite behavior, so operators will reason incorrectly about when a configuration change becomes visible.

[heifner]

Fixed in 4fce5f4. The guide now says the schedule keeps being rebuilt while the sweep drains and that ranking converges over a few rounds rather than switching in one step. That sentence predated removing the publish freeze and I did not revisit it afterwards.

[huangminghuang]

Re-reviewed 991f955. I disregarded persisted-layout/backward-compatibility concerns as requested for the pre-launch stage. The new commits fix the ordinary re-registration reset, payout-divisor over-distribution, mixed-duration nominal-slot accrual, and min_blocks_per_round bound, but the remaining findings below prevent approval.

[huangminghuang]

[P1] Reset the rate window only after the producer has actually left the schedule

This treats every demoted row as the documented dropped-producer recovery case, but regproducer/regproducer2 never checks whether the producer has left the active schedule. A producer demoted by the rate-only path can submit regproducer immediately, before the next schedule rebuild, and this branch clears both is_demoted and the entire rate window without a produced block or any time off-schedule. Repeating that after each demotion makes chronic short-round delivery unpenalizable; preserving the consecutive streak does not help because short rounds deliberately leave it at zero. Gate this reset on actual schedule removal (or another recovery condition that cannot be invoked while the producer still holds a slot), and cover demotion followed by immediate re-registration.

[huangminghuang]

[P1] Implement the advertised rolling miss window

Once the elapsed time reaches the configured window, this discards every prior observation at once, so the implementation is a tumbling bucket rather than the rolling window promised by the config, guide, and PR description. Boundary-straddling short rounds can therefore exceed the limit in a real duration-sized window while neither bucket exceeds it. For example, with a five-round minimum and a 40% limit, GGGSS | SSGGG leaves each bucket at 40%, but the sliding five-round window after the first two rounds of the new bucket is GSSSS (80%); short rounds do not advance the consecutive gate. Expire observations as they age out (or use an equivalent rolling representation) and add a boundary-straddling test.

[huangminghuang]

[P2] Exclude demoted-tier producers from snapshot credit

is_schedulable checks the active producer row, ACTIVE producer opreg status, and finalizer key, but it does not check is_demoted or the row's rank tier. A miss-demoted producer therefore still passes this gate and can keep voting through its retained provider mapping. Its credit then accumulates while payepoch stops before the demoted tier, and regproducer restores the row without clearing snapshot_attestations, bringing that stale score back into ranking. Gate credit on the same tier-plus-live predicate used by the pay walk and add demoted-producer coverage; the new parked-producer test exercises only is_active == false.

[huangminghuang]

[P2] Consume snapshot credit on every pay-walk exit

Demotion and unregprod are not the only events that drop a row out of the pay walk. Deleting the last finalizer key, losing ACTIVE producer-opreg eligibility, or falling below a raised live collateral minimum all make compute return unscored(), but those paths only call rescore and never clear an existing snapshot_attestations value. Because payepoch stops at the demoted/unscored tier, the value can survive across pay periods and reappear after re-keying, top-up, or status recovery. Detect and consume every eligible-to-ineligible transition at its event (without consuming a fresh credit on the reverse transition), and test exit -> pay epoch -> return for finalizer/opreg eligibility.

[huangminghuang]

[P2] Make this regression test reach the over-distribution path

With the fixture defaults, compute_bps == 4000 and producer_bps == 7000, so tiny_emission == 1 produces compute_amount == 0, producer_pool == 0, and active_pool == 0. Both the old and fixed implementations credit zero, so reverting the new block_payable guard still passes this test. One three-producer cycle also leaves total produced blocks below the 120-slot nominal divisor, so the divisor cannot collapse in the way described above. Configure a nonzero one-unit active pool, create at least two excluded rows whose combined blocks exceed the nominal slots, and assert producer credit against the actual active pool so the pre-fix second pass demonstrably fails.

[huangminghuang]

Re-reviewed current head 905f622d0f15, with back-compatibility and persisted-layout concerns intentionally out of scope. All current-head CI checks pass, but I found the three current-head issues below, so I am not approving. The existing unresolved finding about lowered max_consecutive_missed_rounds not reconciling persisted is_demoted also still applies: #599 (comment)

[huangminghuang]

[P1] Require an actual schedule exit before clearing demotion

Preserving the streak does not prevent the cron bypass described in this comment, because tier_for consults only is_demoted. Once the streak is at the threshold, each next unserved round sets this flag again, but the offline operator can submit repeatable regproducer immediately afterward and before the next rebuild, restoring the healthy/bootstrap tier; repeating that once per round lets a sufficiently bonded operator remain scheduled without ever serving. The new test calls regproducer only once and therefore codifies the clear without exercising the repeat loop. Please gate this recovery on the producer actually having left the active schedule (or another non-repeatable recovery state), and cover repeated miss → re-register → rebuild.

[heifner]

Confirmed and fixed in 9c19796. You were right that preserving the streak did not close this: tier_for reads the flag, not the streak, so each unserved round re-raised it and an immediate regproducer cleared it again before the next rebuild.

The pardon is now gated on absence from get_active_producers(). A producer that still holds a slot recovers only by serving a round, so the cron loop has nothing left to clear. Off the schedule there are no rounds left to serve, so that pardon clears the streak along with the flag — which also removes the reason the streak had to survive it in the first place.

regproducer_cannot_pardon_a_scheduled_producer drives the repeat loop rather than a single call: four producers keep the schedulable count under min_schedule_size, so the floor holds the target in the schedule, and it misses three rounds, re-registers, and asserts still demoted — three times over, with the streak accumulating across the attempts instead of restarting.

regproducer_pardons_a_producer_the_schedule_dropped pins the case that is still allowed, and it now asserts the demotion actually survives the schedule exit. Worth flagging that the old test was passing vacuously: a demoted producer keeps producing under the retained schedule and serves a round — recovering — before the rebuild ever drops it, so the assertions held for free.

[huangminghuang]

[P2] Expire snapshot-derived rank beyond the payout cap

Rows after this ceiling are neither reset nor rescored, yet period_start_epoch advances later in this action. Their persisted rank_score can therefore keep the prior period's snapshot term even though a fresh rescore would ignore it via snapshot_period. If higher-ranked producers later leave, such a row can move into a schedule or standby-paying position without any event that rescored it, so stale service affects the next period. Since snapshot credit is bounded by the provider set, please rescore credited providers at the boundary (or use another bounded expiry mechanism) and add a regression with a credited row beyond max_rank_walk_rows.

[heifner]

Fixed in 9c19796. payepoch now rescores the mapped providers still holding credit, after period_start_epoch has moved, so the stale term stops scoring — bounded by max_snap_providers, as you suggested.

One correction to the scope: max_rank_walk_rows is not the reachable end of this. The walk breaks at the demoted tier before it reaches the ceiling, so any parked or sunk row carrying credit hits the same hole without needing 500 rows ahead of it. The fix covers both, and the comment now says so.

No regression test, and I would rather say that than imply coverage. It needs a fixture with both snapshot voting and the pay machinery, and neither existing one has both: block_spacing is 25000, which snapshot_attest_tester only affords by building those blocks before the system contract is deployed, while payepoch requires sysio.epoch authorization and a prior accrueepoch that fixture has no setup for. Building that seemed out of proportion here, but I am happy to add it if you would rather the fix not land uncovered.

[huangminghuang]

[P2] Rewrite the guide and PR body for the current model

This head deleted the rate/window gate: every round below min_blocks_per_round now increments the same consecutive streak, and only a served round (at least the configured threshold), not one block, clears it. This section still promises two gates, a rolling 24-hour rate, short-round-only rate handling, and a fresh rate window from regproducer. Lines 161–165 also say leaving the pay walk consumes snapshot credit, while the new period-stamped implementation deliberately retains same-period credit. The PR description repeats the removed rate-sweep, set_demoted, and snapshot-exit mechanics. Please update these operator/reviewer-facing descriptions to match the code.

[heifner]

Fixed in 9c19796. "Staying in the schedule" is rewritten for the rule the current head actually implements: a round is served at min_blocks_per_round or better, anything less increments the same streak whether it delivered nothing or nearly enough, and only a served round clears it. The two-gate table, the rolling 24-hour rate and the short-round-only handling are gone, along with the claim that regproducer starts a fresh rate window.

The two doors back are now stated as the schedule deciding between them, which is also the behaviour change in this push. The snapshot paragraph is corrected as well: credit is stamped with its pay period and expires at the boundary, rather than being consumed when a producer leaves the pay walk.

PR description updated to match — the rate-sweep paragraph, the set_demoted sentence, and the snapshot-exit consequence.

[huangminghuang]

Re-reviewed current head 9c19796f19. The regproducer pardon gate, threshold reconciliation, and operator-guide updates address the earlier findings. One snapshot-period cleanup hole remains, so I’m not approving this head yet.

[huangminghuang]

[P2] Expire credits after provider mappings are pruned

This sweep only sees producers that still have a snapprovs row. However, prune_stale_snapshot_providers_if_full can erase a mapping when its producer falls out of the top 30 without clearing snapshot_attestations. If that credited producer is then beyond the 500-row pay walk, neither cleanup path rescores it after period_start_epoch advances, so its cached rank_score can continue carrying expired snapshot credit and can affect scheduling if higher rows later leave. Please track credited producers independently of the live mapping set, or clear/rescore the producer when pruning, and add a prune-to-period-boundary regression test.

[heifner]

Confirmed and fixed in 60dff97. The boundary sweep finds credited rows through snapprovs, so a mapping erased for capacity orphaned the credit on the producer row exactly as you describe.

Taking your second option: prune_stale_snapshot_providers_if_full now consumes the credit and rescores before erasing, inside the loop it already walks. Worth noting that rescoring alone would not have closed it — within the same period compute still counts the credit, so the row would look correct right up to the boundary, where there is still no mapping for the sweep to find. The credit has to go at the moment the mapping does.

I went this way rather than tracking credited producers independently because that means new persistent state which itself needs bounding and its own pruning — more surface for the same class of hole, to preserve a rating that describes a producer that is no longer a rank-eligible provider. Scope is one call site: the other erase in regsnapprov is immediately followed by an emplace for the same producer, so no mapping disappears there.

pruning_a_provider_consumes_its_snapshot_credit covers it. It needed a fixture with both halves — capacity producers and a chain advanced to an attestable height — so it pairs capacity_producers() with cadence_periods = 1: credit a producer by vote, park it to make the mapping stale, let a full-table registration prune it, and assert the credit is gone.

One correction to my earlier reply on this thread, which was wrong on the record: I said a parked row with credit hits this hole. It does not — compute returns unscored() for an inactive row, so a parked producer carries no composite and no snapshot term at all. The rows that do carry it are miss-demoted-but-schedulable ones and schedulable rows past max_rank_walk_rows. That is also why the test asserts the cleared counter rather than a moved rank_score: on the parked row this fixture can drive into the prune, there is no composite in which to observe the term leaving. The point about the demoted tier being reachable well before 500 rows stands.

[huangminghuang]

[P3] Describe the served-round threshold accurately

This says only a zero-block round increments the streak and that producing any block clears it, but record_round_result now increments for every round below min_blocks_per_round and clears only when that threshold is met. The adjacent is_demoted comment has the same “producing a block” wording. Please align these field docs with the implemented served/unserved rule.

[heifner]

Fixed in 60dff97. Both field docs now state the served/unserved rule: consecutive_missed_rounds counts rounds scheduled and not served at min_blocks_per_round or better — so a round that delivered some but too few blocks counts exactly as an empty one — and clears by serving a round rather than by producing a block.

is_demoted is corrected the same way, and also picks up the gate added in this push: regproducer clears it only once the schedule has dropped the producer, and is refused as a pardon while it still holds a slot. The old wording implied regproducer always clears it.

Also extended the snapshot_attestations doc to note the prune path now consumes it, per the sibling thread.

[huangminghuang]

Re-reviewed current head 60dff9705e. The earlier prune and field-documentation findings are partly addressed, but a pending vote can recreate credit after its provider mapping is removed, reopening the same period-boundary cleanup hole. I’m not approving this head yet.

Additional documentation cleanup: contracts/sysio.system/EMISSIONS.md:71-73 still describes the removed eligible-round payout model; producer_rank.hpp:206-208 still says one produced block clears demotion; and snapshot_attest.cpp:116 still says no exit consumes snapshot credit. Current-head CI is still in progress, and the PR’s cited e2e run predates this head.

[huangminghuang]

[P2] Prevent pending votes from recreating orphaned credit

Clearing existing credit here does not cover a vote recorded before the prune. snapvotes.voters retains producer identities; if another provider later completes that tuple, credit_snapshot_attestations credits every saved voter without checking snapprovs, so this producer regains credit after its mapping is gone. For an active producer beyond max_rank_walk_rows, payepoch then reaches it through neither the pay walk nor the provider sweep, and the expired term can remain cached in rank_score. The new K=1 test finalizes before pruning and cannot catch this sequence. Please cover vote → prune → later quorum → period boundary and either require a current mapping when crediting or track credited producers independently.

[heifner]

Reverted in f34561a. You are right that this reopened the hole, and chasing it further turned up something that changes the whole picture — so I have reverted the fix rather than patched it again.

Every consumer of the prodrank index breaks at the demoted tier: update_ranked_producers, this pay walk, snapshot_ranked_producers and getpeerkeys. So a demoted row's stale snapshot term orders it only among rows nothing reads, and an inactive row is unscored() and carries no composite at all. The harm needs a SCHEDULABLE row past max_rank_walk_rows — 500+ ranked schedulable producers.

That makes two of my earlier claims on these threads wrong, and I would rather retract them plainly than leave them standing:

• I said a parked row with credit carries a stale term. It does not; compute returns unscored() for an inactive row.
• I said the demoted-tier break made this reachable well before 500 rows. The rows are reachable; the harm is not, because nothing reads order within that tier.

So the boundary sweep and the prune consumption were both buying very little. Against that, the sweep put an inline cost in every payout, prune consumption made a producer's rating depend on an unrelated producer triggering a capacity prune, and — as you found — a vote recorded before a prune re-credits at quorum with no live mapping. Both are reverted in the commit above. Staleness stays read-time via snapshot_period, and the walk's ceiling now documents the residual bound and what it does not affect.

This leaves your original finding accepted-and-documented rather than fixed, which is the same resolution the other bounded-walk finding on this PR reached. If you would rather see it actually closed, the honest way is a persistent cursor over the pay walk rather than a sweep bolted to the boundary — but that is its own change, and it needs the 500-producer case to be real first.

[huangminghuang]

[P3] Document the new early-expiry condition

This still promises that snapshot credit expires only at the pay-period boundary and survives a park-and-return within the period, but a full-table regsnapprov now clears that credit when it prunes the mapping. That makes survival depend on an unrelated producer registering. Either preserve boundary-only expiry with cleanup tracking independent of live mappings, or document the prune-forfeiture exception here and in the PR description.

[heifner]

Resolved in f34561a. Resolved by reverting the prune consumption rather than by documenting it — see the sibling thread. With nothing clearing credit early, this paragraph is accurate as written: expiry is at the pay-period boundary, and a park-and-return inside one period keeps the credit.

You were right that the alternative was unattractive. Making survival depend on whether an unrelated producer happens to trigger a capacity prune is arbitrary, and that was the strongest argument for dropping the mechanism instead of documenting around it.

snapshot_attest.cpp's "No exit has to consume it" is also correct again for the same reason, so I have left it — it only became wrong when the prune change introduced an exit that consumed credit. Flagging that explicitly so it does not read as overlooked.

[heifner]

On the documentation items from the review body, at f34561ac20:

• EMISSIONS.md — fixed. It described the eligible-round payout model; it now states per-block pay against the active slice, with standbys drawing a rank-decreasing retainer rather than being round-scaled.
• producer_rank.hpp — fixed. max_consecutive_missed_rounds now states the served/unserved rule, and that recovery is by serving a round while scheduled, or by regproducer once the schedule has dropped the producer.
• snapshot_attest.cpp "No exit has to consume it" — left as-is, because it is accurate again. It only became wrong when the prune change introduced an exit that consumed credit, and that change is reverted. Flagging it explicitly so it does not read as overlooked.

The PR description is updated to match: the boundary-sweep claim is replaced with the bound now accepted at the walk's ceiling.

On the e2e gate — you are right that the cited run predates this head, and it predates the three heads since. That link should not be read as covering f34561ac20. A fresh gate is needed before merge, and I have not started one; flagging rather than leaving the stale link to speak for the current head.

[huangminghuang]

Re-reviewed f34561a with backward compatibility intentionally out of scope. Reverting the prune-time cleanup removes the pending-vote regression, but the original cached-ordering defect remains actionable; see the inline finding.

[huangminghuang]

[P2] Expire cached snapshot scores beyond the walk cap

This remains a live ordering bug, not merely an unsupported 501st row. A producer can earn snapshot credit, then be pushed to row 501 by 500 higher-scored schedulable producers before the boundary. This payout skips it and advances the period. If just one higher row later exits, the stale key can put that producer at row 500 ahead of a candidate whose live score lies between its base and snapshot-boosted scores; the next payout can process the wrong row's carried blocks and include them in the shared divisor. With more churn, the same expired key can enter the active producer/finalizer set or standby band. Nothing rescores the row when entries above it move, and serving with an already-zero streak leaves it untouched. Since 500 is a scan guard rather than an enforced producer cap, documenting the inconsistency does not make the index safe. Please expire these keys through bounded persistent/lazy work or enforce the hard cap.

[heifner]

Not fixing this one, and I want to be direct about why rather than argue the mechanism — your analysis of it is correct.

The scenario needs 500 schedulable producers ranked above the affected row, as your own description says: bonded on every required chain, ACTIVE in opreg, and holding an active finalizer key, all scoring higher. This network is not expected to exceed roughly 35 producers. At that size the pay walk never reaches its ceiling, every row is rescored at every payout, and no key is ever stale — the defect is unreachable rather than merely unlikely.

You are right that 500 is a scan guard rather than an enforced cap, so nothing structurally prevents it. That is a real gap, and the place to close it is the cap, not the expiry: sysio.opreg's max_available_producers is stored and never enforced, which is the same root the earlier unbounded-walk thread landed on. That belongs in its own change against opreg rather than in producer ranking, and it wants the 500-producer case to be plausible first.

So this is an accepted, documented bound for launch, on the same basis as the other bounded-walk finding on this PR. The comment at the walk's ceiling states it, and states what it does not affect: a demoted row's stale term is inert because every walk breaks at that tier, and an inactive row is unscored() and carries no term at all. If the network ever approaches that scale, this needs revisiting together with the walk cap itself — the cap is the load-bearing assumption, not the expiry.

[huangminghuang]

[P3] Keep the operator docs consistent with the retained bound

This categorical promise conflicts with the accepted behavior documented in emissions.cpp: a schedulable row beyond the 500-row walk can retain a prior-period snapshot term in its stored key, and that term becomes observable if the row later moves back into range. Either fix expiry as above or qualify this guide. Please also clean up the related stale comments: snapshot_attest.hpp:151-153 says operator-registry status is not consulted even though registration now walks is_schedulable, and producer_rank.hpp:151-154 / producer_pay.cpp:68-70 still describe any/first produced block as clearing the streak rather than a served round.

[heifner]

The three stale comments are fixed in 8e9cfb8:

• snapshot_attest.hpp — you are right, and it was backwards: registration walks is_schedulable, so opreg status and the finalizer key are both consulted. The comment now says so instead of claiming the opposite.
• producer_rank.hpp — the streak clears on a SERVED round at min_blocks_per_round or better, and regproducer pardons only once the schedule has dropped the producer.
• producer_pay.cpp — the mid-round early return said the miss counter "was already cleared on the first block of this round", which is the old per-block model. Nothing is scored mid-round; a round is judged once, at the transition where its block count is known.

Comment-only — the rebuilt wasm is byte-identical.

On qualifying the operator guide: leaving it as written, because I think it is already accurate at the level it speaks. It promises that the credit does not survive the pay-period boundary, and that holds unconditionally — compute ignores a count whose snapshot_period is not current, at any rank. What can survive past the walk's ceiling is a stale cached sort key, which is an implementation detail the guide never makes a claim about. Qualifying an operator-facing document with a condition that needs 500+ schedulable producers would mislead more readers than it informs.