x/inference: failed confirmation PoC is slashed by slash_fraction_downtime; confirmation_poc_params.slash_fraction is never read #2208

Open @kaileido opened 2026-11-03 14:03 UTC 0 comments Updated 2026-11-03 14:03 UTC

Problem

A participant that fails confirmation PoC is slashed by collateral_params.slash_fraction_downtime, not by confirmation_poc_params.slash_fraction. The confirmation PoC field has no reader in the chain code.

ComputeStatus returns INACTIVE with reason FailedConfirmationPoC (calculations/status.go:80-82).
Every move into INACTIVE goes to deactiveParticipant, which calls SlashForDowntime whatever the reason (keeper/participant_status.go:69-79), and logs "deactivated for downtime".
SlashForDowntime uses CollateralParams.SlashFractionDowntime (keeper/collateral.go:197-210).
ConfirmationPocParams.SlashFraction is set to 0 in the v0.2.5 upgrade (app/upgrades/v0_2_5/upgrades.go:76) and otherwise only appears in param validation.

Current mainnet params: confirmation_poc_params.slash_fraction = 0, collateral_params.slash_fraction_downtime = 0.1, alpha_threshold = 0.5. So a host whose confirmation PoC ratio drops below 0.5 loses 10% of its required collateral, although the confirmation PoC slash is configured as 0. Governance cannot change the confirmation PoC penalty without also changing the downtime penalty. A PoC challenge writes the same ratio (module/poc_challenge.go:208-210), so a failed challenge ends in the same slash.

Expected

proposals/random-poc/README.md describes slash_fraction as the collateral slashed for a failed confirmation PoC. With the field at 0, a failed confirmation PoC should move the participant to INACTIVE without a collateral slash.

Suggested fix

In deactiveParticipant, when the reason is FailedConfirmationPoC, slash with ConfirmationPocParams.SlashFraction (skip when it is nil or zero) instead of SlashForDowntime, and log the actual reason. This changes state transitions, so it ships with a chain upgrade. If the downtime fraction is the intended penalty, the confirmation PoC field should be removed instead, so the parameter set does not suggest a separate knob.

2205 updates the proto comments to describe the current behaviour; they need another edit once this is decided.

🔄 Auto-synced from Issue #2208 every hour.