On-Chain Governance for XDC DPoS
XDC supports a built-in public governance mechanism whereby all network changes (update_proposal) must be approved by two-thirds of the Masternode holders (register_validator).
On-chain governance is a formalized process by which eligible voters--in this case, Masternode holders--can change the protocol.
  • update_proposal: Any entity registered as a Masternode can vote on update_proposal with proposed vote_period.
  • vote_type: Identity-based 1-register_validator (Masternode) = 1-vote
  • vote_period: between 15-90 days
  • vote_condition: more than one-tenth of register_validator should participate in voting; otherwise, update_proposal gets void.

How the On-Chain Governance System Works

The on-chain governance system only works online. Changes to the blockchain can be proposed through code updates. After that, Masternodes can vote to accept or reject the proposed change. Masternode votes all carry equal weight. If two-thirds of the validator_node vote to accept the proposed change, the change is made to the blockchain and baselined. In some cases, if the proposed change is rejected, the updated code may be rolled back to the previous version.

Pre-defined Update

  • Update the block time
  • Update with vote_period
  • Update with vote_type
  • Update with vote_condition
  • Update the WITHDRAWAL_PERIOD
  • Update with MAX_REGISTERED_VALIDATORS
  • Reduce VALIDATOR_REWARD
  • Update with REWARDS_TRANSFER period
  • Update/Upgrade Smart contract address
  • Update MIN_STAKE
  • Update WITHDRAWAL_PERIOD
  • Update function reportMalicious
  • Distribution of subsidies when relevant.
  • Retroactively change the state of the blockchain.
  • Time-Based limitation to add any changes in the network.
  • Changes in the parameters and existing protocol of a blockchain.

Update Hard-Coded value

-HashLength
-AddressLength
-MasternodeVotingSMC
-BlockSigners
-RandomizeSMC
-FoundationAddr
-TeamAddr
-VoteMethod
-UnvoteMethod
-ProposeMethod
-ResignMethod
-SignMethod
-RewardMasterPercent
-RewardVoterPercent
-RewardFoundationPercent
-HexSignMethod
-HexSetSecret
-HexSetOpening
-EpocBlockSecret
-EpocBlockOpening
-EpocBlockRandomize
-MaxMasternodes
-LimitPenaltyEpoch
-BlocksPerYear
-LimitThresholdNonceInQueue
-DefaultMinGasPrice
-MergeSignRange
-RangeReturnSigner
-MinimunMinerBlockPerEpoch
-MinGasPrice
Contract State Transfer: Whether through a migration process or a persistent storage pattern, the contract state would have to be transferred to the new version of the contract.
Current TestNet Link: Click here​
GitHub Code: Click here​
Smart Contract Link: Click here​
The Masternode must stake 10 million XDC and upload a valid self-KYC certification (using IPFS) to be a Validator_Node.

Current Self-KYC Flowchart

Smart Contract code: Click here​

KYC Functions

ο»ΏThe following list of functions helps explain the major features of the XDPoS KYC smart contract.
Function uploadKYC
Users can upload their KYC documents, which are then processed and added to the transaction data and, finally, to a block.
Function voteInvalidKYC
Masternode candidates can use the VoteInvalidKYC function to view a submitted KYC certification and vote to reject it if they doubt its validity.
Function getLatestKYC
The function GetLatestKYC can be used to retrieve the most recent KYC documents of the user in question.
Function getHashcount
The function GetHashcount can be used to return the number of counts of uploaded KYC.
Function getAllKYC
The function GetAllKYC can return the whole array of KYC data submitted by the user in question.
Google Doc: Click here​
Copy link
On this page
How the On-Chain Governance System Works
Pre-defined Update
Update Hard-Coded value
Current Self-KYC Flowchart
KYC Functions