Pre-proposal call for discussion: What should we do with dropped tokens

I wonder if anyone is interested in helping me with a proposal to establish a ‘ruleset’ for what I see to be a very likely eventuality in the future.

Given the experience with Akita and all of it’s immense downside, I think the Stewards of GitCoin should establish a few simple rules concerning ‘token drops’.

I propose that any token drop that appears in the GitCoin Multisig without a prior vote by some committee of or the entire group of stewards be rejected by immediately (or within some time frame) sending the tokens back to the sender.

Reasoning: to better protect GitCoin’s community good will and avoid the ugly, unnecessary nonsense that’s gone on related to the Akita token incident including the ‘creative interpretation’ and near-blackmail as has been revealed on Twitter.

The idea is that in order for any token to remain in the GitCoin multisig, it must have been ‘whitelisted’ in some way first. This will eliminate the need to make any decision and allow the Stewards to act without needing to justify their behavior as it will have been already established.

6 Likes

I’m Ayodeji Fakayode a Graphics Designer, can I handle this project Graphics Design aspect??
I will be expecting feedback ayomifay@gmail.com

1 Like

redistribute redistribute redistribute redistribute

Since it has been missed, I feel it is necessary to redistribute it to those active community governance participants and contributors who make the GTC community better and better.

3 Likes

Hi @tjayrush,

Would you mind to establish a quick recap of what is the problem here before going into a full proposal. I am a bit confuse even after reading all the post regarding the Akita token incident.

Who did drop these tokens?, Why?, Why we should redistribute them? What was the purpose of this drop? At who this drop was indented to be?
Who did started this project and why it landed here at Gitcoin? What is the relation about this project and Gitcoin?

Citing this post here:

I quote in this proposal:

“The motivation behind this proposal is to mitigate collateral damage. The Akita investors invested believing that half of our supply was “burned” to VBs wallet.”

The motivation behind this proposal is not really clear. Why should Gitcoin interfere with the valuation of this project by redistributing these tokens or by allowing ressources consumption from burning them. It’s clear that many user want a redistribution, but at what cost, what are the main impacts, pros and cons etc.

1 Like

Hi @tjayrush
What do you mean ‘token drops’?

2 Likes

I will take an analogy to evaluate this, by thinking about the Akita instance.

Unless a token is notorious, it can be part of GTC community by default (i.e. legit custodian send token to community address, the gitcoin became the new custodian). Otherwise multisig wallet can vote and reject.

Analogy:

Token A joined Gitcoin with some hesitation (wallet owner made the choice, but not other hodler/speculators), therefore it is part of GTC community, it should have some degree of ‘freedom’ to find out whether prefer to stay or go.

(One possible way of giving that freedom back to A community:

Put 50% of A and pair with GTC to create a new liquidity pool (so price is set at the time) - or maybe 10% at a time so price discovery can be spread on 5 attempts, with say 6 month break in between so total 2 years, then this 50% is free to go.

The rest 50% A will be part of the GTC community and will not be sold. (Maybe use as grant/capital/even voting, it is a separate issue)

So we end up with a portfolio of token alliance. it is like a charitable extension or franchise part of wider gitcoin community.

Benefits:

The impact of gitcoin community is much wider by this type of token alliance.

If this didn’t work out (how do we define this?) - it is a phased approach so all can learn and change the direction.

)

Thanks for your comment. It’s interesting, but this ‘pre-proposal’ is not in any way about the Akita token. This is about a possible policy for similar receptions of tokens in the future so as to avoid the exact situation that your thoughtful comment is trying to solve.

If the policy was clear: “accept no unsolicited incoming tokens,” these types of situations would not need to be fixed.

That’s the discussion I’m trying to elicit, not solutions to the Akita issue.

3 Likes

yeah realised that so I will made some amendments. I meant to use the example to propose the approach for ‘semi-consent-donation-some-hodl/speculator-expect-Vitalik-address-equal-to-burnt-then-found-not’ situation.

Sorry about my misunderstanding @tjayrush.

I could help you for the proposal if you need some help. I also think that in the near-by future, unsolicited incoming tokens should be audited.

This is :100: thought of and I support this whole heartedly… The wish to keep what the rightful owner didn’t give isn’t something to be proud of.

I have seen some ugly comments from akita community and I must say I wasn’t proud of it being a gitcoin member.

I believe going forward gitcoin will always make a right decision.

1 Like

By token drop I mean that someone from outside of the Gitcoin community (if there is such a thing) simple assigns ownership of one or more tokens to the GitCoin multisig address (making the GitCoin wallet the owner of those tokens). Of course, it’s not possible to disallow this – anyone can transfer the ownership of a token to anyone else (although, I do think there are ways to handle this). My concern is that if ‘unwanted’ (or ‘unexpected’ or ‘unsolicited’ tokens – call them what you will) show up, then the GitCoin community has to make an ad hoc decision on what to do with them. If there’s a pre-stated policy about what do with unsolicited tokens (sell them immediately, send them back, whatever), the crazy ad hoc nature of the “Akita incident” might be avoided.

Plus, if there was a very clear policy like - we will immediately sell unsolicited tokens - there may be less of an reason to send them in the first place.