Whitelistcontract 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.
Whitelistcontract 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
address. When new addresses are to be added to the whitelist, then the
whitelist_addressesentrypoint can be called by one of the governors, passing in a
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
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_whitelistedentrypoint. 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.