P3 slashing economics: slashed-stake destination, penalty sizing, dispute bonds, delegator semantics

[umeradl]

We're pushing to close the P3 mechanism designs (tracking issue #36), and slashing has three economic decisions that shape the protocol beyond one contract. Design context: MECHANISM_DESIGN §4, implementation issue #38.

cc @abrahamnash — points 1 and 4 in particular touch white-paper semantics, and we'd value your read before we freeze the spec.

1. Where does slashed stake go?

Options: (a) burn, (b) treasury, (c) redistribute to honest validators of the same GI, (d) split. Today slashed tokens strand inside the stake contract — an accidental burn.

Current recommendation: 50% burn / 50% treasury. Burning is a deflationary sink and avoids validators profiting from peers being slashed (which encourages false disputes); the treasury half funds dispute adjudication. Reporters get only a fixed dispute bounty, never a share of the slash.

2. Partial-slash fraction and the score-deviation threshold

Today a missed audit vote slashes a flat minStake() — it fully unstakes a floor-staked validator for one liveness fault, which over-punishes. Proposal: partial slash = DAO-settable fraction of min stake (25–50%), full slash reserved for provable malice and recidivism. The S3 score-deviation threshold needs empirical data from BlockFLow scoring validation (P3-SCR) first — plan is a wide threshold in warning-only "shadow mode" for the first weeks of DevNet 2.0, then tighten.

3. Dispute bond size and window length

Any staked validator can open a dispute by posting a bond (forfeited if frivolous, returned + treasury-funded bounty if upheld), triggering re-evaluation by a fresh subgroup. What bond size deters spam without pricing out small validators, and is a window of ~1 GI enough?

4. White-paper alignment: delegator penalties and permanent removal

White paper §8.1 specifies that delegators to a slashed validator lose a percentage of their stake, and that slashed validators are permanently removed (must re-register a new identity). DevNet has no delegation yet (parked to P5+), and our current design jails/blacklists rather than forcing identity re-registration. Do we treat the §8.1 semantics as binding for 2.0, or as the eventual target once delegation lands?

[umeradl]

Thanks for working through this, Abraham — appreciate the detailed pass. We're wiring these into the DIN P3 specs now.