Design

The main design principle for x/dgov module is to keep the well tested and wildly usedx/gov module as is and add Dchain's unique Oversight Committee functionality on top of it.

Main differences:

• Introduce additional period after an original gov proposal has passed (by votes from native token stakers) that allows the Oversight Committee to decline the execution of the passed proposal. By default, all passed proposals are executed if Oversight Committee do not interfere.

• Introduce a state where a list of disallowed message types are stored, only message types NOT on this list can be performed by the Oversight Committee in case of emergency proposal execution

• Introduce new emergency proposal execution path that allows the Oversight Committee to make an emergency decision without voting from the native token staker, i.e. does not follow the normal gov proposal process.

• Custom vote tallying mechanism: Implements a voting system where delegators must vote directly - validators do not vote on behalf of their delegators (no vote inheritance)

• Opt-in governance voting: Voting requires verification through the x/vcv module - voters must include extension options to participate

Vote Tallying Design

The x/dgov module implements a custom vote tallying mechanism in x/dgov/keeper/tally.go that fundamentally differs from standard Cosmos SDK governance.

Key Design: No Validator Vote Inheritance

Implementation in WrapperDefaultCalculateVoteResultsAndVotingPower:

1. Direct voting requirement: Only votes cast directly by DT stakers are counted. The function iterates through all votes submitted for a proposal.

2. Voting power calculation: For each vote submitted:

   • The voter's total delegations across all validators are enumerated
   • Voting power is calculated as: delegation_shares × validator_bonded_tokens ÷ validator_total_shares
   • This power is weighted according to the voter's chosen options (Yes/No/Abstain/NoWithVeto)
   • The calculated voting power is added to the respective vote option tallies

3. No default inheritance: If a delegator does not submit a vote, their delegated stake does not contribute to any vote option, even if their validator(s) voted. This is in contrast to standard Cosmos SDK governance where non-voting delegators inherit their validator's vote.

4. Validator voting: When a validator votes, their voting power is calculated from:

   • Their self-bonded stake (via their own delegations to themselves)
   • Only the stake from delegators who also explicitly voted and delegated to this validator

Opt-In Voting via x/vcv Extension

Governance voting requires explicit opt-in through the Verifiable Credential Verification (x/vcv) module:

• MsgVote verification: The MsgVote message type is registered in the x/vcv XVerifierRoutesRegistry (see x/vcv/keeper/x_verifier_routers.go:45-51)
• Extension option requirement: Each vote transaction must include an x/vcv extension option with verification credentials
• Voter attribute routing: The x/vcv router extracts the voter attribute from MsgVote and applies configured verification criteria
• Validation before tallying: Only votes that pass x/vcv verification are accepted and subsequently counted during the tally process

Implementation Details

The tally function (see x/dgov/keeper/tally.go):

// For each vote cast (that passed x/vcv verification):
// 1. Record if voter is a validator
// 2. Iterate through voter's delegations to all validators
// 3. Calculate voting power from each delegation
// 4. Add weighted voting power to results
// 5. Remove vote from store after processing

This design ensures that:

• Staking delegation is purely for network security and validator selection
• Governance participation requires explicit action from each stakeholder
• Validators cannot influence proposal outcomes using delegated stake from non-voting delegators
• Only verified and eligible participants can vote

Interaction of OversightCommittee with x/dgov (wrapped x/gov)

State Diagram of a Proposal on Dchain