Skip to content
This repository has been archived by the owner on Oct 2, 2021. It is now read-only.

[KIP-003] Retroactive Fixes to Missed Airdrop Participants #5

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
84 changes: 84 additions & 0 deletions kips/kip-003.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# KIP 003 - Retroactive Fixes to Airdrop

Author: Keefer Taylor, Hover Labs <[email protected]>

### 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](https://tzstats.com/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.

🗒️ ⬜ <!-- ✅ --> _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))

🗒️ ⬜ <!-- ✅ --> _TODO(keefertaylor): Discuss with community which option makesmore sense once we have a better sense of the number of claimants.