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
reportMaliciousDistribution 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
Last updated
