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 (5)
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
one question , Have any other projects done this? we can check this
good idea
KYC Mechanism Modification Proposal 3
Add a waiting period to the uploadKYC function
If a person uploads their KYC, they will enter a waiting period. After 1000 blocks, they can call the contract to activate their KYC. Additionally, implement a KYC invalidation mechanism through voting. If during this period they receive 1/3 of the votes against them, their KYC will be considered failed, and they will not be able to activate it.
Integrating Zero Knowledge (ZK) Proofs into KYC processes marks a significant leap in blockchain technology, refining the operations of masternode networks:
Here is Ankr Verify Solution :
For an in-depth understanding of this revolutionary process, visit the Ankr Verify documentation : ankr.com/docs/verify/overview/