Wraith coordinator roster is one node in production, so the election is vacuous

[defenwycke]

Measured on the live fleet, 2026-08-20. Not a code bug — a deployment fact that makes the decentralisation claim currently false in practice.

What is running

vm4 is serving a Wraith coordinator right now: ghost-pool is listening on 0.0.0.0:9100, and /api/v1/pool/coordinator reports

{"enabled":true,"epoch":6689,"seats":1,"my_seat":0,
 "elected":["9fe860bd…4d1b38"],
 "coordinators":[{"endpoint":"95.111.221.169:9100","seat":0,"node_id":"9fe860bd…4d1b38"}]}

One seat, and the sole candidate is vm4 itself.

Why the roster has one member

node	coordinator_enabled	coordinator_role_enabled	wraith_election_enabled
vm1	false	false	false
vm2, vm3	(no [coordinator] keys → default false)
vm4	true	true	true
vm5–vm8	(no [coordinator] keys → default false)

Only opted-in nodes advertising a reachable endpoint enter the roster, and exactly one node has opted in. The draw is then trivial: with |roster| == 1, elect_coordinators can only return that node, every epoch, for ever. Rotation, fairness and no-self-nomination are all vacuous at this size — they are properties of a draw over a set, and the set has one element.

So the answer to "no single party is the operator" is, in production today, a single party. #697 was right about the conclusion and wrong about the cause: the code is wired (see the correction on that issue), the roster is empty except for one node.

This is not a bug to fix in code

Nothing here is malfunctioning. The gate is opt-in by design, and no operator has opted in besides vm4. What it means is that the sortition machinery cannot deliver its property until more nodes set coordinator_enabled = true and advertise an endpoint — and that any claim about decentralised coordination should say "one seat, one candidate" until they do.

Worth deciding:

• Which nodes should opt in? vm5–vm8 run ghost-pool but not ghost-pay; check whether a coordinator seat needs the L2 services co-located before enabling them.
• What is the minimum roster size below which the election should refuse to seat anyone, or at least report itself as degraded? Publishing seats: 1 as though it were an election invites the reader to assume a draw happened.
• seats_for_demand sized this at 1. Confirm that is demand-driven and not a floor.

Related, found at the same time

The deployed election view carries no beacon, roster or per-seat rank — it predates fa8ed99c0, which publishes them and has wallets verify the draw. Until vm4 is redeployed, a wallet on that commit will refuse this election as unverifiable and fall back to a manually configured coordinator. That is the intended direction of failure, but it is a deploy-ordering note: nodes upgrade before wallets rely on verification.

[defenwycke]

Re-measured live, 2026-09-09 — the reporting half has shipped, the roster has not moved

ghost-vm4, GET /api/v1/pool/coordinator (port 8080, not 9100 — 9100 is the coordinator's own listener and returns 404 for this path; worth correcting in the issue body):

{"enabled": true, "epoch": 6709, "seats": 1, "my_seat": 0,
 "roster_size": 1, "degraded": true,
 "beacon": "69a1a3c53756322582d19f73204d0388ff47558f25e3de3b5f70cc56f48b8719",
 "anchor_height": 966095,
 "roster": ["9fe860bd…4d1b38"],
 "coordinators": [{"endpoint": "95.111.221.169:9100", "seat": 0, "rank": "ceeb88a6…"}]}

Both "Related" notes in this issue are now resolved in production:

• the view carries beacon, anchor_height, roster and per-seat rank — so a wallet can recompute the draw instead of trusting it. v1.11.38 is fleet-wide, so the deploy-ordering concern (nodes upgrade before wallets rely on verification) is satisfied.
• degraded: true and roster_size: 1 are published, so a reader can no longer mistake one opted-in node for an election that rotated. MIN_MEANINGFUL_ROSTER = 3 (coordinator_election.rs:76), on the stated grounds that controlling one of two is controlling half the draw.

Epoch has advanced 6689 → 6709 with the same sole candidate throughout.

The remaining checklist item, answered

Which nodes should opt in? vm5–vm8 run ghost-pool but not ghost-pay; check whether a coordinator seat needs the L2 services co-located before enabling them.

It does not, and cannot — ghost-pay no longer exists. It was deleted from main with the bond subsystem (#699/#721), so there is nothing to co-locate. The only hard requirement a mainnet coordinator has is a reachable ghostd RPC (coordinator_supervisor.rs:62, mainnet_activation_refusal), and that URL is not a separate key at all — it is composed from [bitcoin] rpc_host/rpc_port (bins/ghost-pool/src/main.rs:7917), which every node already has because every node runs ghostd.

So vm5–vm8 need no new infrastructure to take a seat. What they need is a [coordinator] block: coordinator_enabled, coordinator_role_enabled, wraith_election_enabled, coordinator_port, advertised_endpoint, coordinator_fee_address. Confirmed absent — vm5 and vm6 have no [coordinator] section at all today; vm4 has all six keys.

vm5–vm8 are also the right candidates for a second reason: they are not in the mining DNS, so enabling them costs no miner-facing restart churn.

What is the minimum roster size below which the election should refuse to seat anyone, or at least report itself as degraded?

Answered in code already — it reports degraded below 3 rather than refusing. Refusing would take the coordinator layer down entirely on a roster that is merely small, which is worse than a stated-degraded one.

seats_for_demand sized this at 1. Confirm that is demand-driven and not a floor.

Demand-driven, and additionally capped by the roster: by_demand.min(MAX_SEATS).min(eligible) with MIN_SEATS as the floor (coordinator_election.rs:121). With eligible == 1 the cap is what produced seats: 1, not the demand term. Adding candidates raises it on its own.

⛔ Not actioned: enabling the nodes is an operator decision and a production config change, and nothing should be restarted until MESH_ENVELOPE_V2 fires at 966,400.