DIN-DAO Stage C: validator governance voting power — double-locking vs. stake-bridge (DD-1)

[umeradl]

Tracked as DD-1 in Developer/design/DESIGN_DECISIONS.md. Raised by @robertocarlous on PR #27 (feat/din-dao, issue #23).

Problem

DinValidatorStake already holds a validator's slashable DIN stake. Stage C's DinGovernanceStaking (stDIN) is a separate contract: lock DIN → mint non-transferable, checkpointed voting power (OZ ERC20Votes). As shipped in PR #27, these two locks are entirely independent — a validator who wants governance voting power must lock a second, distinct pool of DIN into DinGovernanceStaking, on top of what's already locked (and slashable) in DinValidatorStake.

Net effect: either validators need 2x their DIN (one set staked for validation, one locked for governance), or they get zero governance power despite being the most economically committed participants on the network.

Doesn't block PR #27 merging — Stage C doesn't activate before Testnet 1.0 regardless — but worth resolving with real discussion rather than deciding under PR-review time pressure.

Options

A. Double-locking (current PR #27 behavior) — keep the two contracts fully independent.

• Pros: simplest to build/audit, zero coupling between governance and slashing logic.
• Cons: capital-inefficient for validators; under-weights the most committed participants.

B. Stake-bridge

• Derive governance voting power directly from a validator's DinValidatorStake balance — e.g. a read-only adapter reporting it as IVotes-compatible voting power, no second lock.
• Pros: no double-locking; governance power tracks real protocol commitment instead of a parallel, unslashable pool.
• Cons: couples governance power to a balance that can shrink via slashing mid-proposal (checkpoint/snapshot semantics get more complex); more contract surface to audit; conflict of interest — see below.

C. Hybrid

• Allow both paths — a validator can use stake-bridged votes and/or lock stDIN; non-validators stay stDIN-only.
• Pros: flexible, doesn't force validators to pick one.
• Cons: most complex option — two independent power sources feeding one quorum invites double-counting/gaming edge cases (e.g. unstake-then-relock timing around snapshots); inherits B's conflict of interest on its bridged-vote component.

Full write-up with more detail: DD-1 in DESIGN_DECISIONS.md.

Update: conflict-of-interest argument for Option A

This branch's own Documentation/technical/din-dao/README.md (§5, Voting Power Model) already recorded a rationale against B/C when Stage C was designed:

Validator stake in DinValidatorStake is not counted toward governance power in v1. Hybrid stake-voting would create a conflict of interest when governance votes on slashing conditions or blacklisting appeals.

That's a real, concrete argument for A: DinGovernor proposals include Operational-category items — slasher authorization, blacklisting, model disable/enable (§4.1 of the same doc) — and a validator voting with power derived from their own slashable stake is voting on the rules that could slash them. B and C both inherit this to the extent they let bridged stake vote on those proposals.

Possible mitigations, if bridging is still wanted for the capital-efficiency win

1. Category-scoped carve-out. Bridged validator voting power only counts toward Parameter, Treasury, and Upgrade proposals — zero weight on Operational proposals (the category that actually contains slashing/blacklisting decisions). Keeps the conflict-free upside for most governance activity, removes it exactly where it exists. Cost: stock OZ Governor doesn't support per-category voter-weight rules — this needs a custom voting/weight module, not vanilla GovernorVotes.
2. Per-proposal recusal. A validator who is the explicit subject of a pending slashing/blacklist proposal has their bridged votes excluded from that proposal only. Finer-grained than (1) but more engineering — needs the Governor to cross-reference proposal calldata against the voter's validator identity at vote time.

Both are real additional scope on top of B/C's already-larger audit surface — worth weighing against just shipping A now (simplest, no conflict, matches what's already documented) and revisiting bridging later if validator under-representation in governance actually becomes a problem in practice.

My take (updated)

Leaning toward A (double-locking, current PR #27 behavior) given the conflict-of-interest argument above — it's already the documented rationale in the branch, and neither mitigation for B/C is free. Still open to B/C with mitigation (1) if the team thinks validator capital-efficiency is worth the added Governor complexity.

cc @Santiagocetran @Abidoyesimze @robertocarlous @abrahamnash — input welcome on: A vs. B/C-with-mitigation, and separately, whether either mitigation above is worth building for v1 or should wait until we see actual demand from validators for a governance voice.

[umeradl]

Closing for now. We'll reopen this when governance work resumes.

DD-1 was deferred on Aug 4, and it was never settled on its merits. Abraham's DD-3 decision (Discussion No. 70) moved all of DIN-DAO, Stages A–D, to post-mainnet: DevNet governs off-chain until then. PR No. 27 (feat/din-dao) was closed on Oct 8, to be reopened after mainnet.

When this resumes, the starting point is still Option A (double-locking), because of the conflict-of-interest argument. The full write-up stays in DESIGN_DECISIONS.md DD-1, and issue No. 23 stays open as the DIN-DAO tracker.