High Level Design

High Level Design of Kickflow Contracts

Core Contracts

• Flow DAO contract is the managerial contract that consists of the executive logic of Kickflow DAO. It takes decisions based on a token voting mechanism. Proposers can submit executive proposals in the DAO, which are then put to vote.

• Governance Token contract is a FA1.2 standard-based token contract, customised to record historical balances of an address. This assists in token voting.

• Community Fund contract represents a community fund managed by the DAO. This can store and transfer tez, FA1.2 & FA2 tokens. It also has the ability to delegate its tez.

• Matching Round contract handles the logic & features of a Kickflow match-funding round.

• Donation Handler contract handles multi-token payments during the match-funding round.

• Whitelist contract represents a registry, that holds a set of addresses that are allowed to make contributions during a match-funding round. This is the primary defence barrier against pseudonymous identities on Kickflow.

Overview

Match-funding rounds on Kickflow are designed to be conducted entirely on-chain through the use of smart contracts.

Flow DAO and Governance Token ($KFL) contracts will be staying the same throughout the course of Kickflow (except for governance parameter changes in the DAO). The rest of the contracts can be changed as a whole through fresh deployments (with new features), or partially (referring to storage changes in the contract) through the administration of the DAO.

In the initial design of Kickflow, each match-funding round would be conducted using a fresh Matching Round contract. The Donation Handler would be pointing to the currently active round contract and record the public contributions from whitelisted addresses in the same.

The pointer to the round contract in the Donation Handler can be changed via a proposal in the DAO- essentially meaning that every new match-funding round can only be conducted if approved by the DAO.