[SEP #5] Redistributing Unredeemed Tokens From User Airdrop Allocation

[SH007]

cant agree all, it should not just look at the volume

[cedricoo]

really clear, thank you for taking time to write it ser ! i personally will agree with option 1

[Luah_Delgudo]

I agree with the first proposal too.

[og_go]

I agree with option A but change to this: distribute them average to all those who redeemed their allocated tokens before the deadline.

every one is fair and average. Make every faithful user of safe equal treatment.

[Andyhhh]

I hope this vote is fair and just and not the result of malicious manipulation

[xdog]

Daily crypto user here and somehow missed the claim period. Only use Gnosis as a cold wallet with a friend so don’t use the app a whole lot so guess its understandable, still would have thought i would have seen it on twitter though. Regardless would be cool to see it extended, more people to govern is better than having a select few with more control imo.

[gaojia001]

What I want to say is that the rules are set in advance and must be followed. It’s fair to everyone, if you don’t claim it by the deadline, it means you have given up. If you pay attention to this project, most of you will get it. The remaining tokens should be distributed to those who have been following the project and claiming success by the deadline.

[theobtl]

It seems this proposal has come quite far.

@Billion

Totally agree with @Daniel , the delays of votes and discussions are already long enough and what he suggests is unanimous and proposes a significant saving of time.

There is a point to keeping this proposal simple and not delay the process further. It’s just: I agree with others that we should make sure that an oversimplification of this proposal does not cause unnecessary delays elsewhere.

I’d also say that the latest revision is not unanimously supported, as it’s leaving out other options. That includes extending the claim period (be that instead or in parallel to this proposal), but also others like rewarding users on Gnosis Chain and other L2s.

@rimeissner

Personally I find it quite interesting that the focus of this SEP is to allocate more tokens to the users that already have tokens (which is ok, as it is rewarding active participation to some extend), rather than checking how the unredeemened tokens can be distributed further.

As it stands, the final Snapshot vote would be as follows:

• Option A: Use all unredeemed tokens and distribute them proportionately to all those who previously redeemed their allocated tokens
• Option B: Use 1/2 of all unredeemed tokens for the aforementioned cause
• Option C: Use 2/3 of all unredeemed tokens for the aforementioned cause
• Abstain
• Make no changes

The motivation for that seems to be:

@Daniel

I am not an opponent of extending the claim period, in fact I’m pretty neutral on this, and in the event of a vote, I would almost certainly abstain or vote in favor of it. However, we do need to talk about whether or not it’s worth delaying voting on redistributing tokens for what might be 3 months […] Only after that we could vote on redistributing tokens

I don’t think these initiatives necessarily depend on another and cannot be rolled out in parallel, if we come up with specific implementations and align them. This proposal just had to define its implementation (e.g., the amount of the 32M tokens used) and include options on which alternatives we should explore in parallel. That should be feasible, shouldn’t it?

That way, this proposal can still focus on redistributing to those who redeemed while it’s also a signal for us all what else to do (or not to do) in a more time-efficient manner:

@Melodic_Platypus

Your points on time management also brings up the issue of when these ideas would be rolled out. So, I see four potential use cases brought up here for the unclaimed tokens which if done one after another would take more than a year to conclude. Rather than focus on one us case like redistribute, lets focus on everything and prioritize the ones that are more important.

@CaptainTee

I’m in agreement with @Melodic_Platypus as regard finalizing all the proposed options in a single proposal rather than wasting time seperating the options to different proposals.

Let’s say, someone wants to redistribute unredeemed tokens to those who claimed, but also wants to extend the claim period in parallel.

• they might vote “make no changes” (=No) because they think the claim period should be extended first
• they might vote “abstain” because they’re for the proposal, but also for having clarity on the claim period and choose to vote neither for nor against it
• they might vote “B” or “C” to start redistributing unredeemed tokens to those who claimed, and work on extending the claim period separately

Unfortunately, we’ll only see the quantitative results of the final Snapshot vote, not the Why behind each vote. (Yes, you can add a comment in Snapshot, but very few do so and that had to be analysed manually.) Based on the result of the vote alone, it would be impossible at scale to tell which preference exactly is behind each voter in relation to other options. If you’re supporting this proposal, the best case scenario may be any of A-C, giving you clarity on redistributing to those who claimed. But you’d start fresh with exploring other options. The worst case scenario for proponents of this proposal would be “Make no changes” because we wouldn’t know whether people are decisively against redistributing unredeemed tokens to those who claimed, or generally for it but want clarity on other options, too.

So I’d join @Melodic_Platypus and @CaptainTee and ask:

Wouldn’t it be a low-hanging fruit to make the vote more meaningful and informative by including at least one more option to accounts for alternative measures?

[theobtl]

Sidenote:

@CaptainTee

(B) - Dedicate ⅓ of the unclaimed airdrop to Dev GRANTs

That can be left out here, given we have a separate budget for the Guardians programme and a grants programme is in the making.

[theobtl]

If my previous comments find support, I think it’s worth spending a few more days to refine the options – as the final sprint of this proposal to get it across the finish line.

Here’s just one possibility:

Types of Allocations

• Allocation A: Redistribute unredeemed tokens proportionately to all those who previously redeemed their allocated tokens
• Allocation B: Explore other ideas for allocations, including setting up a new claim period for those who were eligible for the initial claim but had not redeemed their allocations (“extend claim period”)

Voting Options

• Option 1: Only A, using all unredeemed tokens
• Option 2: A+B in parallel, using ⅓ of unredeemed tokens for A and ⅔ for B
• Abstain
• Make no changes

What do people think?

Is this an efficient compromise to not delay this proposal much further, but also not delay alternative options? cc @Daniel @Melodic_Platypus @CaptainTee

[RoundElephant]

@theobtl

Types of Allocations

• Allocation A: Redistribute unredeemed tokens proportionately to all those who previously redeemed their allocated tokens
• Allocation B: Explore other ideas for allocations, including setting up a new claim period for those who were eligible for the initial claim but had not redeemed their allocations (“extend claim period”)

Voting Options

• Option 1: Only A, using all unredeemed tokens
• Option 2: A+B in parallel, using ⅓ of unredeemed tokens for A and ⅔ for B
• Abstain
• Make no changes

I like it. Just to put some numbers on this: since only ~18M were claimed, and ~32M remain undistributed. So this would mean that those who claimed on time would get ~50% more SAFE than they originally claimed if we went with Option 2, and ~200% more with Option 1?

Option 2 seems like a fair hybrid solution to me, wondering if others see it that way, too?

[theobtl]

If we agree on the general direction of these new voting option, you’re right that the exact numbers are another discussion point.

I included the 100% option because it’s been part of this proposal all the time. Personally, I see many arguments for a more moderate increase for those who have already redeemed, like Option 2 now. We could also have three options, e.g. with 80%, 40% or 20% for A (and the rest for B). But that is up to us all and the proposal author @Daniel.

---

On a more conceptual note, we just have to keep in mind that the single choice voting mechanism can only be meaningful if the options are sufficiently different. To make this more tangible: Let’s say, there are 1.000 voters with preferences within 80%-100% for A. If there’s a single option in that spectrum, that option gets 1.000 votes. If there are options for 80%, 85%, 90%, 95% and 100%, each option might get only 200 votes. But in this single choice voting mechanism, only one option wins and you can only choose one.

So we have to balance granularity of voting options with fairness of various outcomes, if that makes sense.

[CaptainTee]

@theobtl

Types of Allocations

• Allocation A: Redistribute unredeemed tokens proportionately to all those who previously redeemed their allocated tokens
• Allocation B: Explore other ideas for allocations, including setting up a new claim period for those who were eligible for the initial claim but had not redeemed their allocations (“extend claim period”)

Voting Options

• Option 1: Only A, using all unredeemed tokens
• Option 2: A+B in parallel, using ⅓ of unredeemed tokens for A and ⅔ for B
• Abstain
• Make no changes

While I like this proposal, I still think it needs to be further discussed and clarified

For: Types of Allocation

I support leaving Allocation A the way it is proposed (i.e all unclaimed tokens gets distributed to those who has already claimed) because trying to spilt the ratio to be distributed will again bring further unnecessary delay and this is what we are trying to avoid

Allocation B needs to state the extension period (in weeks or months)

Also, Allocation B which say Explore other ideas for allocations sounds to me like isn’t finalised yet and there is still a need to discuss on what the unclaimed tokens are to be used for after the extension.

Will it not sound more clarifying if we rephrase the Allocation B to:

Extend Claim Period for 6 weeks and return unclaimed token to Treasury pending the time SafeDAO determines how it is used

For: Voting Options

I have no comment against Option 1 (i.e using all tokens for Allocation A)

But, Option 2 which talks about sharing the token between Allocation A and B doesn’t still give chance to those who doesn’t support Allocation A at all (i.e those who doesn’t want any part of the token to go to those who claimed their airdrop) to vote in support of their preferred Allocation B only.

Even though, I will gladly vote for Option (2) that supports both Allocation A and B but I still think those who would like to stick with Allocation B only shouldn’t be deprived of their choice

In view of the above, I’m suggesting we add option that will allow those who wants to support Allocation B only to vote their choice and here is my extended Options;

Voting Options

• Option 1: Only A, using all unredeemed tokens
• Option 2: Only B, extend claim period and return left over to Treasury
• Option 3: A+B in parallel, using ⅓ of unredeemed tokens for A and ⅔ for B
• Abstain
• Make no changes

[nanhanniu]

I prefer the first opinion

[Neo_Michael]

Isn’t this the best chance to gain users on L2?

[Neo_Michael]

So many l1 users did not claim rewards, should then focus on l2?

[Daniel]

@theobtl

I included the 100% option because it’s been part of this proposal all the time. Personally, I see many arguments for a more moderate increase for those who have already redeemed, like Option 2 now. We could also have three options, e.g. with 80%, 40% or 20% for A (and the rest for B). But that is up to us all and the proposal author @Daniel.

I’m supportive of the reasoning behind the alternative set of voting options you suggested, and I will update the proposal accordingly once there is some more feedback on it.

As for the 100% voting option: personally, I’m not a fan of that option either, so we should remove it and replace it with a more reasonable alternative (see below an example how this could look like).

Voting Options

• Option 1: Only A, using ⅓ of unredeemed tokens
• Option 2: Only A, using ⅔ of unredeemed tokens
• Option 3: A+B in parallel, using ⅓ of unredeemed tokens for A and ⅔ for B
• Option 4: A+B in parallel, using ⅔ of unredeemed tokens for A and ⅓ for B
• Abstain
• Make no changes

To make the implications of the proposed voting options clearer, we should add a disclaimer to the Allocation B explanation, clearly stating that voting for it serves “only” as a signal and any decision about specifics will require another vote:

Types of Allocations

• Allocation A: Redistribute unredeemed tokens proportionately to all those who previously redeemed their allocated tokens
• Allocation B: Explore other ideas for allocations, including setting up a new claim period for those who were eligible for the initial claim but had not redeemed their allocations (“extend claim period”) [Disclaimer: Voting to include Allocation B serves “only” as a signal; a final decision on extending the claim period and/or considering other ideas for allocations requires another SEP.]

[qianwan_lv]

I hope safe will be more generous. These 5% airdrops are not much. This 50 million is originally for users. It is recommended that all unclaimed tokens be allocated to the claimed addresses. There is no doubt that these 10000 addresses are of high quality and really high-quality users.
I support the allocation of A in the proposed way (that is, all unclaimed tokens will be allocated to the claimed tokens), because trying to allocate the proportion will again cause unnecessary delay, which is what we are trying to avoid.

[CaptainTee]

This extended Options seems to be better so far.

Anyone who thinks all unclaimed tokens should go to those who already claimed should vote for Option 2: (i.e ⅔ being shared, that’s fair enough)

The Disclaimer added to Allocation B clarifies my misunderstanding.

If there are no concrete views that seeks to have Option that will be in support of “Allocation B only” in the next few days , @theobtl should please assign a SEP number of let’s push this to voting on Snapshot.

[theobtl]

@CaptainTee

@theobtl should please assign a SEP number of let’s push this to voting on Snapshot.

Yes, let’s give the community a few more days to comment on the latest change and move it from phase 0 to phase 1 (SEP) next week.

Before moving it further to phase 2 (Snapshot), the proposal needs final voting options and a clear specification if and how it will make use of SafeSnap (especially for allocation A).