Skip to content

Design question: who should be allowed to open a PoC challenge that waives devshard misses? #1970

Open @kaileido opened 2026-10-10 13:19 UTC 0 comments Updated 2026-10-10 13:19 UTC

Area

Branch release/v0.2.16-post1, module x/inference (PoC-challenge creation and the devshard miss waiver).

Relevant code: - CreatePoCChallenge (who may open a challenge) - WaiveDevshardMissesForActiveChallenge (the waiver) - IsAllowedEscrowCreator (the allowlist the gate reuses) - settlement call site (where the waiver runs, with the "waive only challenge-window misses" TODO) - getInactiveStatus (the downtime signal the waiver feeds)

What the current rule allows

When a host is under an open challenge it must run PoC instead of serving inferences, so the waiver zeroes its missed-inference count at settlement so it is not marked INACTIVE for downtime it could not avoid. The intent is fine, but challenge creation is gated by the devshard escrow allowlist, whose default (empty) means anyone, and the only same-party check is creator != target, so under default params a funded account can open a challenge against a host it also controls. On mainnet today the escrow allowlist is set (18 addresses), so only those addresses can open a challenge; the gap is the default-open semantics and the coupling to the escrow list.

Why it matters

The waiver suppresses the MissedRequests delta that drives the downtime SPRT, so a host that opens a challenge against itself can keep missing its queued inferences, stay ACTIVE, and keep its epoch reward without serving.

The design doc (proposals/multi-model-poc/long-poc-challenge.md) says a challenge is opened by "a governance-approved address", but the code's default lets anyone do it, so offline accounting and rewards can be wrong.

Note: this only suppresses the downtime signal. Completed/validated counts are unchanged, so it is not reward-count forgery.

Options

  1. Gate challenge creation to an explicit allowlist, empty means deny. Reuse the existing escrow allowlist field for the challenge path with inverted empty-semantics, so the feature is off until governance approves a challenger. Small, no proto change, no migration. Trade-off: couples escrow and challenge policy (approving a challenger also restricts escrow creation to that list), and an approved-but-malicious challenger could still self-challenge.

  2. Dedicated allowed_challenger_addresses param on PoCChallengeParams, empty means deny. Same security outcome as option 1 but decoupled: escrow creation stays permissionless while challenge creation is gated on its own. Trade-off: needs a new proto field plus a (trivial, default-nil) migration.

  3. Scope the waiver by assignment time (the TODO's "window" idea), keep creation permissionless. Waive only misses whose work was assigned after the challenge opened. Trade-off: this does not fix it and regresses honest challenges. New assignment already stops at the challenge start height, so every waivable miss comes from work assigned before the challenge opened, which means this would waive nothing and penalize honest challenged hosts for pre-challenge work.

Option 2 (dedicated challenger allowlist, default deny) as the clean fix. Option 1 is the minimal stopgap if a proto change is not wanted now.

The question for the team

Should PoC-challenge creation have its own governance-gated allowlist that is closed by default, independent of the escrow allowlist? If yes, option 2; if coupling is acceptable for now, option 1.

A reproducing test and a draft fix exist and can be shared with maintainers on request.

🔄 Auto-synced from Issue #1970 every hour.