Whitelist
The
Whitelist contract is a registry that stores a set of addresses that can make their contributions count in the CLR match calculation during a funding round. Addresses are whitelisted based on some form of an identity solution.Since our match-funding rounds are based on the quadratic formula, some kind of an identity solution is mandatory. It prevents the gaming of the system by collusion- creation and coordination between multiple fake pseudonymous accounts.
Whitelist contract has an admin- a Tezos address controlled by Kickflow. The admin has the ability to add governors. The governors are addresses that have the exclusive right to whitelist other addresses. The admin itself is also a governor.The whitelisted addresses are stored in a
set of type address. When new addresses are to be added to the whitelist, then the whitelist_addresses entrypoint can be called by one of the governors, passing in a list of address.Users would need to sign-in to our platform using Github or Twitter OAuth. An OAuth based sign-in would give us access to the account creation timestamp for the respective platforms. Profiles with a Github/Twitter account at least 2 years old, can drop a whitelist-request on our platform. Only one address can be requested to be whitelisted by each profile.
Although stringent, these criteria would reduce the risk of gaming with the system by mass-coordinated fake profiles.
We have a whitelisting-bot that would whitelist addresses in chunks at regular intervals depending on the number of pending requests in our backend servers.
Governors are Tezos addresses that can whitelist other addresses by passing a list to the
whitelist_addresses entrypoint. The functionality of having governors whitelist addresses instead of the usual single admin address was introduced for flexibility. As more decentralised identity solutions come up on Tezos, we could have a contract- connected to a DID registry, functioning as a governor.
Governors can be added or removed by the contract admin.
Any contract can verify if an address is whitelisted by Kickflow, by calling
verify_whitelisted entrypoint. The call to the entrypoint fails (transaction reverts) if a non-whitelisted address is passed.The whitelisting criteria could be potentially upgraded down the line. In such an event, the existing whitelist would be cleared and a fresh whitelisting contract would be deployed. This would require the existing users to request a re-verification of their addresses using the new set of rules for whitelisting.
As Decentralised Identity (DID) solutions get more popular and widespread on Tezos, we would be incorporating the same for whitelisting.
Last modified 2yr ago