Validator slot cap
How many advertised benchmark slots receive live tickets on any one validator, the disk, memory and CPU ceilings that narrow an overloaded host, and the hard stop above which it receives nothing at all. Applied at the next ticket issue, live within seconds, and recorded as an append-only audited revision.
Slot policy in force
How many advertised benchmark slots receive tickets on any one validator, plus the disk circuit breaker. Both are evaluated at ticket issue time only: a change never revokes a live lease, so an in-flight benchmark always runs to completion and a ramp down drains rather than aborts.
Concurrent slot cap
2of 8 advertisable
Shipped default (revision 0). No operator revision has ever been written.
- Ceilings (disk / mem / cpu)
- 90% / 90% / off
- Hard stop
- 95%
- Restricted to
- 1 slot
- Propagation
- Within 5s
- Shipped default
- 2 / 90%
A validator advertises its own capacity in the heartbeat; this cap decides how many of those advertised slots the platform fills with live tickets, so it can narrow the fleet but never widen it past what a validator can serve. A cap of 1 is the kill switch: dispatch returns to strictly serial. A validator whose latest heartbeat reports disk, memory or CPU at or above its ceiling is held to 1 slot; at or above the hard stop it is issued nothing at all until it recovers. A ceiling of 0 turns that resource off in both tiers, which is why CPU ships off — a pinned CPU is a working benchmark host, not a failing one. All of it is evaluated at issue time only: live leases keep running, and the restriction lifts on its own when a fresh heartbeat reports headroom. Changes reach the dispatch path within 5s with no platform restart.
Fleet right now
Scoring v7Advertised capacity and reported disk from the latest signed heartbeats. Slots filled is what the cap would issue at the next ticket, not a live reassignment.
| Validator | Advertised | In flight | Disk | Updater | Slots filled | Issuance |
|---|---|---|---|---|---|---|
| 5GrwvaEF…utQYacceptingscorer unverified | 1(1 healthy) | 0 | 10% | self-managed | 1 | accepting policy permits |
Apply a new revision
A revision stores the whole policy, never a diff. Every knob is written every time, against revision 0; a concurrent write is refused rather than overwritten.
Revision history
Append-only, newest first. Nothing here is ever edited or removed; a change is a new revision recorded against the operator who applied it.
No revision has ever been written. The fleet is running the shipped default of 2 concurrent slots at a 90% disk ceiling.