KIP 003 - Retroactive Fixes to Missed Airdrop Participants

Author:
Keefer Taylor, Hover Labs [email protected]

Created:
08/10/2021

Status:
DRAFT

Summary

Kolibri DAO Token ("kDAO") is a governance token for the Kolibri system. 1M kDAO are in existence.

Of those kDAO, 350k kDAO were given to the Kolibri Community Fund. 150K kDAO were airdropped to the community. Initially, Hover Labs produced a list of airdrop participants, but upon further analysis, identified clusters of addresses that may represent sybil attacks and removed them from the airdrop. We announced this change on both our Discord and Twitter in advance.

After the airdrop occurred, several credible entities have come forward with credible evidence that they were not performing a sybil attack.

Motivation

These community members appear to be operating in good faith, and be early users of the protocol who rightfully qualified for the airdrop. This proposal seeks to bring them into the community of Governance holders.

Existing token holders may be motivated to uptake this proposal since it benefits the system by expanding the number of users who hold kDAO, thereby increasing decentralization.

Details

A one time supplemental airdrop to affected users can be carried out from the Community Fund.

Criteria For Inclusion

For the airdrop, users will be required to self-identify and provide credible evidence to the community. We can gather and validate this information trustlessly by creating a new “Poll” smart contract which has interface:

// Submits a request for inclusion from the sender's address.
submit(evidenceLink: string)

// Allows a kDAO holder to vote on whether evidence is sufficient for inclusion
// voteValue = 0 is "no", voteValue = 1 is "yes"
vote(prospectiveRecipientAddress: address, voteValue: nat)

Like the Kolibri DAO contract, the poll contract will use a snapshot system to prevent users from acquiring kDAO to game the system. This snapshot will be hardcoded to block 1597357 (August 10, 2021, approx 20:36 UTC).

The contract will hardcode a cutoff date of 1 month after it is deployed, at which point submission and votes are no longer accepted.

Any users who have a simple majority of votes at the end of the period will be eligible to receive a retroactive airdrop as compensation.

Lastly, a new user interface will need to be developed to interact with this contract.

A note on timing: This is a rather heavyweight, but completely trustless, way to carry out this proposal. It requires engineering effort to develop the smart contracts / interface, and community engagement. However, this up front cost may be worthwhile if we intend to run other trustless poll contracts in the future.

:spiral_notepad: :white_large_square: TODO(keefertaylor): Discuss with community whether it makes sense to pause other projects for Hover Labs to work on this, or if there are community members who can help.

Payout Amount

TODO(keefertaylor): Discuss with community what is reasonable here. We could give every address a fixed amount, the original amount, or some fraction of the original amount. 350,000 kDAO in the community fund is a lot, but it is finite and we should be conservative.

Airdrop Process

A lambda to pay out some $AMOUNT of kDAO from the community fund to a destination address ($DESTINATION) could be crafted as follows:

{ 
  DROP; 
  NIL operation; 
  PUSH address "KT1LdS5mBkTzrjacqgJ1FMZNmaSoUazZXSuR"; 
  CONTRACT %runLambda (lambda unit (list operation)); 
  IF_SOME {} { PUSH string "BAD_CONTRACT"; FAILWITH }; 
  PUSH mutez 0; 
  LAMBDA unit (list operation) { 
     DROP; 
     NIL operation; 
     PUSH address "KT1RyoAZJ3za3FzYsTJYvqzzq4oEW5xnumdQ"; 
     CONTRACT %send (pair address int); 
     IF_NONE { PUSH string "BAD_CONTRACT"; FAILWITH } {}; 
     PUSH mutez 0; 
     PUSH (pair address int) 
     (Pair "$DESTINATION" $AMOUNT); TRANSFER_TOKENS; CONS }
  }; 
  TRANSFER_TOKENS; CONS 
}

Note that KT1LdS5mBkTzrjacqgJ1FMZNmaSoUazZXSuR is the Break Glass contract for the Community Fund, and KT1RyoAZJ3za3FzYsTJYvqzzq4oEW5xnumdQ is the community fund.

The recipient of the transfer could be a few folks:

  • A trusted community member who can then run an airdrop with a script (requires low engineering / operations effort; requires a high level of trust)
  • A multisig composed of trusted community members who can perform the operations (requires moderate engineering / operations effort; requires a moderate level of trust)
  • A smart contract where users can either claim their distribution ((requires high engineering / operations effort; requires low level of trust))

:spiral_notepad: :white_large_square: _TODO(keefertaylor): Discuss with community which option makesmore sense once we have a better sense of the number of claimants.