Skip to main content

Concept

Overview​

Dchain has two governing parts:

  • The DT stakers propose and vote system: allows the community of DT holders who have staked to make governance proposal and vote on proposals.
  • Oversight Committee: a group of committee members who have high stakes in the network, such as the legal entities behind the deployed DApps form this group. The detailed rationale and DApps participation in the Oversight Committee can be found in the features

DT Stakers Voting Mechanism​

A key design principle in Dchain's governance is that staking delegation does NOT equal voting power delegation, and governance participation is opt-in only through verifiable credential verification.

Direct Voting Requirement​

Unlike some Cosmos SDK chains where validators can vote on behalf of their delegators:

  • Delegators must vote directly: Each DT holder who has staked tokens must submit their own vote on governance proposals to have their voting power counted.
  • No validator vote inheritance: Validators cannot vote on behalf of their delegators. If a delegator does not vote, their staked tokens do not contribute to the proposal outcome.
  • Voting power calculation: When a delegator votes, their voting power is calculated based on their total delegated stake across all validators they have delegated to.

Opt-In Governance Voting via x/vcv​

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

  • Extension option required: The MsgVote transaction must include an x/vcv extension option to be valid
  • Voter verification: The x/vcv module routes and verifies voters based on configurable criteria (see x/vcv/keeper/x_verifier_routers.go)
  • Registry-based validation: The MsgVote message type is registered in the XVerifierRoutesRegistry with specific verification requirements and criterion attributes (e.g., "voter" attribute)

This ensures that only eligible participants who have met verification requirements can participate in governance.

Rationale​

This design ensures:

  1. Active participation: Only engaged stakeholders who actively vote influence governance decisions
  2. Direct representation: Each stakeholder's voice is heard only when they choose to participate
  3. Clear accountability: Validators cannot make governance decisions that affect delegators without their explicit consent
  4. Separation of concerns: Staking for network security (delegation) is separate from governance participation (voting)
  5. Verified participation: Only verified and eligible participants can vote through the x/vcv verification mechanism

OversightCommittee group​

The main purpose of that group is to ensure that Dchain remains compliant for its stakeholders. This is done by allowing 2 actions to be done exclusively by this group. The group address is stored as authority in the dgov module.

Such group has their own Oversight Committee Group Policy and this policy has an address as well. in terms of Cosmos SDK account it's a real account but unclaimable one. the main difference is that it does not have private keys. But we may use such address as an authority in d-gov module, to check that message came exact from Oversight Committee.

The main responsibility of the group is to make a regulatory decision. It has 2 main mechanism to make it:

  • Send a MsgOversightCommitteeVeto message that declines the proposal that's being already passed.
  • Send a MsgOversightCommitteeExec message that allows to execute the attached message without voting. It's an emergency action to prevent the chain from going down. This group address is stored as authority in the dgov module.

Cosmos SDK Group overview​

We provide background on the cosmos-sdk's x/group module and how it supports Oversight Committee and dgov requirements.

The registered group has an Oversight Committee Group Policy which is an unclaimable account within the cosmos-sdk - i.e. it has address, account number and balances. The main difference is that it does not have private keys.

Instead, the group members must propose and vote to execute messages.

The group module from Cosmos SDK is responsible for making a collectivity decision through proposal mechanism. To be short:

  • There is a proposer, who is sending a SubmitProposal message with another message inside that will be executed in case of passing.
  • Other participants may vote on the proposal using Vote message.
  • Depending on the decision policy and the number of votes, the proposal is either accepted or rejected.

More details here. This Oversight Committee Group Policy address is used in dgov module, to check that special messages can only be executed by the Oversight Committee.