Developers Forum for XinFin XDC Network


Posted on • Updated on

[Proposal] Proposals for Modifying Validator Contract Functionality

1. KYC Mechanism Modification

Current Status: The current KYC mechanism is ineffective because anyone can upload KYC information without verification.

Proposal One: Add a voting mechanism to the uploadKYC function:

  • Only KYC-verified Masternodes can propose new candidates.
  • All Masternodes need to vote on the uploaded KYC information, and only those that receive more than 75% of the votes can pass KYC verification.

Proposal Two: Add a waiting period to the propose function:

  • After a candidate is proposed, the candidate address will not become a candidate immediately, but will enter a waiting list for two weeks.
  • Create a new voting method to vote on whether the candidate in the waiting period is invalid.
  • If 75% or more of the voters believe the candidate is invalid, the candidate will be removed from the waiting list and will not become a candidate.
  • If the candidate is not voted invalid during the waiting period, the candidate can become a candidate by calling the claimCandidate function to remove itself from the waiting list.

2. Modify Voting Parameters

Current Status: The request parameters for voteInvalidKYC and invalidPercent functions are invalidCandidate.

Suggestion: Change the request parameter to invalidOwner to make the system more stable.

3. Implement a Blacklist for Disqualified Owners

Current Status: If a owner is voted out, he will still have a chance to be proposed later.

Suggestion: This change introduces a blacklist mechanism to address the issue of repeatedly proposing unqualified owners. When an owner is voted out due to invalid KYC, both the owner and any candidates they propose will be added to a blacklist.

  • Blacklisted owners lose the ability to withdraw funds.
  • Blacklisted candidates cannot be re-proposed for ownership.

Soliciting Opinions:

  • Which of the two proposals for the first opinion is better?
  • Any other suggestions for the second opinion?
  • Any other suggestions for the third opinion?

Discussion (4)

akhekade profile image
Atul Khekade • Edited on

Why not use a third party Zero Knowledge based KYC - instead of existing document functionality.

There are third party KYC specialists who can pass a verifiable ZK Proof Hash which goes into KYC metadata hash for masternode proposal.

This would not add any complexity, voting or manual approvals into Masternodes logic

So instead of IPFS hash that it uses today, it would use ZK Proof from third party KYC provider

galaxyscitech profile image
Galaxy Author

one question , Have any other projects done this? we can check this

galaxyscitech profile image
Galaxy Author • Edited on

good idea

anilchinchawale profile image

Integrating Zero Knowledge (ZK) Proofs into KYC processes marks a significant leap in blockchain technology, refining the operations of masternode networks:

  • Preserved Privacy: ZK Proofs facilitate authentication without exposing sensitive data, upholding user confidentiality.
  • Bolstered Security: Leveraging ZK Proof Hashes ensures a secure, immutable KYC verification process, impervious to unauthorized alterations.
  • Seamless Integration: Collaborating with specialist KYC providers enables straightforward, efficient implementation.
  • Streamlined Operations: This framework eliminates complex approval processes, resulting in a more agile and consistent masternode function.
  • Technological Foresight: Adopting this cutting-edge methodology keeps pace with the dynamic evolution of blockchain technology, leading to industry advancements.
 Transitioning from traditional IPFS hash methods to ZK Proofs supplied by reputed KYC facilitators empowers us to build a more sophisticated, privacy-centered blockchain environment.

Here is Ankr Verify Solution : 

  1. A user creates a digital ID and submits their credentials.
  2. Synaps, Ankr's KYC partner, verifies them and stores them in a secure vault.
  3. Ankr Verify generates claims, corresponding the user's credentials, and binds them to the digital ID.
  4. A Web3 service/Smart-Contract asks if the user meets a certain requirement via ZK proofs.
  5. Relying on the corresponding claim, Ankr Verify sends a "yes/no" answer. No sensitive data is ever sent in this process.

For an in-depth understanding of this revolutionary process, visit the Ankr Verify documentation :