Flow DAO

FlowDAO is the managerial core of Kickflow. All executive decisions regarding Kickflow's match-funding rounds and associated features are taken by submitting executive proposals in the DAO. These proposals are put to vote and are voted upon by Kickflow Governance Token or $KFL holders.

Design

Flow DAO was initially inspired by the design of Kolibri's Murmuration DAO, but heavily customised to fit the Kickflow ecosystem.

Proposals raised in the DAO have associated metadata and a Michelson LAMBDA that takes in a UNIT parameter and returns a LIST of OPERATION. When a proposal is put to vote, it is essentially the operations in this list that are being asked to be approved for execution. These operations usually make certain changes in a contract belonging to the Kickflow ecosystem. A few such operations would be-

• An operation to set the CLR matches of the project entries in a matching-round.

• An operation to change the MatchingRound contract, the DonationHandler is pointing to.

• An operation to move the tokens from the CommunityFund contract.

For a proposal to pass the vote, the sum of up_votes and down_votes must be greater than or equal to the threshold for attaining quorum and the up_votes must be in a simple majority over the down_votes. Passed proposals are then timelocked for safety, before execution.

Description of entrypoints, contract storage parameters and proposal metadata format for Flow DAO can be found here.

Registering Proposals

Proposals can be registered or submitted in the Flow DAO, by $KFL token holders, holding a certain percentage of the total supply of the governance tokens. This threshold is set in the governance parameters of the storage as proposal_threshold and can be modified in the future through yet another proposal.

As mentioned in the design section, the proposals have associated metadata that is actually an IPFS hash of the proposal's description in a specific format, and a Michelson Lambda that is executed when the proposal passes the vote.

A sample lambda to set the CLR matches in a MatchingRound contract would look like-

SmartPy

def sample_lambda(param):
  sp.set_type(param, sp.TUnit)

  # operation
  c = sp.contract(
    sp.TMap(sp.TNat, sp.TNat), 
    sp.address("KT1GyfVpcgAYWbv1i5av6fbCipnBaYRGCrdd"), 
    "set_clr_matches"
  ).open_some()
  sp.result(
    [sp.transfer_operation(sp.map({1: 75000000, 2: 25000000}), sp.mutez(0), c)]
  )

Michelson JSON

[
  { "prim": "DROP" },
  { "prim": "NIL", "args": [ { "prim": "operation" } ] },
  { "prim": "PUSH", "args": [ { "prim": "address" }, { "string": "KT1GyfVpcgAYWbv1i5av6fbCipnBaYRGCrdd" } ] },
  { "prim": "CONTRACT", "args": [ { "prim": "map", "args": [ { "prim": "nat" }, { "prim": "nat" } ] } ], "annots": [ "%set_clr_matches" ] },
  { "prim": "IF_NONE", "args": [ [ { "prim": "PUSH", "args": [ { "prim": "int" }, { "int": "9" } ] }, { "prim": "FAILWITH" } ], [] ] },
  { "prim": "PUSH", "args": [ { "prim": "mutez" }, { "int": "0" } ] },
  {
    "prim": "PUSH",
    "args": [
      { "prim": "map", "args": [ { "prim": "nat" }, { "prim": "nat" } ] },
      [ { "prim": "Elt", "args": [ { "int": "1" }, { "int": "75000000" } ] }, { "prim": "Elt", "args": [ { "int": "2" }, { "int": "25000000" } ] } ]
    ]
  },
  { "prim": "TRANSFER_TOKENS" },
  { "prim": "CONS" }
]

Flow DAO also records the block level at which the proposal is registered. To prevent the usage of flash loans, the token balance that is considered for proposal_threshold, is one level behind the proposal's origin level.

Resource	URL
Sample proposal metadata hosted on IPFS	IPFS Link
Front-end interface to view a proposal on our governance portal	https://gov.kickflow.io/proposals
Front-end interface to register a new proposal	https://gov.kickflow.io/proposals/new

Voting

Voting on proposals in Flow DAO is done through the governance tokens ($KFL). The vote can be for or against the proposal, and the weight of the vote is considered to be the $KFL balance of the Tezos address that is voting. No locking up of tokens is required for voting and each address is only allowed to vote once.

To be precise, it is actually the historical $KFL balance- one level behind the origin level of the proposal that is considered. The rationale behind choosing a level behind is to prevent a flash loan attack situation, wherein the proposal is submitted and voted on at the same block level.

A more technical explanation of voting (based on the entrypoints called) can be found here.

Governance Parameters

There are a few governance parameters based on which the DAO functions. These parameters are flexible and can be changed by means of a proposal.

Parameter	Description
voting_period	The number of seconds for which the proposal can be voted upon.
quorum_votes	The number of votes required for the proposal to attain a quorum.
proposal_threshold	Minimum $KFL balance required to submit a proposal in the DAO.
timelock_period	The number of seconds for which a proposal that has passed the vote, stays timelocked before execution.

Timelocking

Every proposal that passes the vote is timelocked for a certain period (based on the value oftimelock_period in governance parameter). Timelocking is done as a safety measure to buy time for resolution, in a situation wherein a 'bad proposal' passes the vote.