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

I would suggest modifying Option 1 and Option 2 to:

  • Option 1: Only A, using 1/2 of unredeemed tokens
  • Option 2: Only A, using all of the unredeemed tokens

It makes no sense to me that we have 1/3 and 2/3, but not 50% and 100%.

Do we need to backdate the vesting period, is there special benefits in backdatingā“ if there is no major reason behind the backdated vesting, I would suggest we use future date which is more understandable to all

Iā€™m assuming the proposal will be finalised on or before 1 March, 2023
Therefore, Iā€™m proposing we change the vesting starts date to;

1st of March, 2023 or the date this proposal gets ratified via snapshot voting (whichever comes early)

The main distribution released 50% of the Airdrop while the remaining 50% vested for 4 years.
The unredeemed tokens should follow the same pattern and release 50% on the claim starts date.

If there are no reasonable amount of token available for claiming, many may keep postponing claiming for the token to accumulate and that may cause people to miss claiming in due time.

2 Likes

I agreed we could change Option 1 to: Only A, using 1/2 of unredeemed tokens

But, I personally not in favour of using all of the unredeemed tokens (100%), the ā…” is fair enough

It makes sense to use part of this unredeemed tokens for other promotional arrangements

I think arb,and op,maticā€™s users .other chains users need it.

1 Like

Iā€™d keep it super simple, either:

  1. Let the tokens be claimed by the current recipient indefinitely (no action)
  2. Reclaim them and use these for a future airdrop based on Safe usage, possibly on other chains

Worldcoin seems like they should get a nice allocation. :slightly_smiling_face:

1 Like

You should also consider to airdrop people holding the below NFTs proportionally;

  1. The Punk6529 Grail Gallary : power by safe.
  2. Launching SafeDAO and Safe Token ($SAFE) NFT
  3. Safe Community Roundup #1 NFT to ā€¦

I prefer the option 3 or 4.

Iā€™m not sure if I understand correctly, I think the voting options need some additional notes.

For example, If Option 1 get 15% vote, Option 2 get 15% vote, Option 3 get 15% vote, Option 4 get 20% vote, Option abstain get 5% vote, Option make no changes get 30%, what should we do in this situation?

Apparently more votes for redistribution, but make no changes will be the final result.

I suggest adding up the votes of options 1, 2, 3, and 4 and comparing them with the remaining two options. If one of abstain or make no changes gets more votes, the result will be the one with more votes among them. If 1,2,3,4 combined get more votes, then the result will be the option in 1,2,3,4 with the most votes.

1 Like

This is a good point. ā€œmake no changeā€ is included so that you can disagree with the allocation proposal but it is not properly weighted to represent to overall opinion of the community.

Itā€™s not clear how single-option votes are calculated with multiple options like ā€œdo nothingā€ and ā€œabstainā€ and i donā€™t see any other dao talking about it. Discussions on this with the LobsterDAO community showed that itā€™s a faulty system as the abstain option has no weight to the outcome of the vote. For example, if abstain gets more votes then wouldnā€™t it mean that the the community see the proposal as unacceptable or not worth deciding?

2 Likes

The voting system is definitely a challenge here, the more complex the options get.

KrauseHausDAO recently had a similar problem where they could not make sense of their voting result due to a suboptimal voting system design.

ā€žSingle choice votingā€œ works best with just one option. Then, the vote is most accurately balanced between ā€žforā€œ and ā€žagainstā€œ. Votes for ā€žabstainā€œ are ignored but do count towards the quorum.

That could mean here to have one option for rewarding those who had already redeemed, and ā€žmake no changesā€œ as not doing that and exploring all other options.

In either outcome, there would have to be another vote to specify the next steps. This still sounds better than voting on all at once with a faulty voting system, doesnā€™t it?

2 Likes

I agree. The way the current proposal reads is misleading because all the options are the same but with slight differences . Also, it is not necessary to put the allocated amount up for vote at this time.

Allocation B, as proposed, will require another vote to determine what to do with the remaining tokens after redistribution so we will end up having to separate the voting for each proposed option. Those proposed/accepted options at them moment are, claim extension and return to treasury. The more that there are the longer it will drag on.

If the options for this proposal were to just be ā€œyesā€ and ā€œnoā€ then we can move onto voting for Allocation B and decide how much to allocate later. Only then will it make the most sense to vote on the allocation amount because we have the full scope of the distribution options.

On a site note.

I personally donā€™t think it is necessary to vote on the allocation amount because it doesnā€™t really matter at the end of the day. The internal safe team can come up with these numbers that best balance all the options voted for. Furthermore, these amounts can be as arbitrary as needed in order to fairly account for every option. I am specifically referring to the fact if claim extension, if agreed upon in a future vote, will conflict with redistributing tokens unless the original claim amounts for the extension can be reserved in some way. I mentioned opening up a forum in my previous posts in order to determine the exact amount that will be included in the claim extension.

To reiterate my position on this matter, i am in agreement with this comment. I would also like to make clear that neither of these options agree to leave the tokens in the treasury so there will be future proposal on the remaining tokens regardless.

Agreed on your last statement that there should be another vote soon. Could you expand on your perspective on why itā€™s a faulty voting system?

The outcome from the second vote should be a good indicator of which token holders are active participants and whether or not delegates are contributing to proposals.

1 Like

Are you able to share any of your research or feedback on how to better identify airdrop farmers?

1 Like

the claim period is too short, and thats not what a real airdrop is, dont forget what the purpose of airdrop is, try to cover as many as users as possible and and i suggset Extend the claim date to give everyone who didnt claim a second chance and make sure only dormant addresses are left out

:+1:
this one looks very interesting

Since I have read some constructive feedback here regarding the voting options:

Yes, of course the voting options are not ideal. Iā€™m not a fan of them myself, but I donā€™t see that there is any better alternative.

At least not until a new governance framework for SafeDAO is proposed (and ratified) that allows us to use ranked-choice voting and also gives us more flexibility in other questions.

If we add 2 more voting options (to cover other preferences), we are already at 8 possible choices. And this then becomes so complex that I no longer know whether the option that was voted for the most corresponds to the will of the majority.

But I think that the way the proposal is structured now, it accommodates everyone at least to some extent. And we have to think of a vote for one of the options that includes Allocation B as a two-step process: With this proposal a signal is sent out, and as a response to this signal hopefully different proposals surface ranging from re-opening the claim period to allocating tokens for an airdrop to L2 Safes. Or perhaps even an experimental ā€œliquidity mining programā€ that rewards users with SAFE tokens for holding assets in Safes.

Those are fair points. At the same time, having a linear vesting schedule over 4 years without half of them upfront is perhaps an even better way to align interests for the long-term.

I think a compromise could be to extend the redemption period to 6 to 9 months, giving more time for tokens to accumulate and then be claimed/redeemed in one.

2 Likes

If the original redemption period lasted for only 3 months, it would be unfair if extension period (grace period) is lasting for Ɨ2 (6 months) or Ɨ3 (9 months) of the original redemption period.

It is also important we note that this proposal is one of the Milestones that determines when and if $SAFE transferability will be enabled.

If the claim period doesnā€™t elapsed and unredeemed tokens gets returned to treasury, $SAFE transferability will only be a discussion not a reality.

Delaying transferability for another 6 - 9 months will not sit well with many (including myself)

I understand this has been a very tough proposal so far and it is difficult to arrive at a perfect solution but in order not to waste time on this, I will suggest:

(A) we stick to original claim period as written in the proposal (i.e claim period starts 1st January, 2023 and vested for 4 years)

But, let 10% - 15% of the token be available for claiming immediately and other remaining 90% - 85% vested for 4 years

(B) the redemption start period could be set back to September 27th, 2022 (same date as the initial claim start period) but with no percentage released (i.e all tokens gets vested for 4 years starting from that date).

Any of the above should ensure reasonable amount of tokens are available for claiming and at the same time align interest for the long-time

And like I once said, Claim Period should only last for 4 - 6 weeks since this is just a grace period for those who miss the initial claiming due date.
6 - 9 months will only cause unnecessary delay

7 Likes

I agree with you, but I donā€™t know what causes the inefficiency of safedao. Itā€™s really too low. Such an inefficient discussion canā€™t solve any problems. This proposal should have been voted as a snapshot long ago, so that we can proceed to the next step!

2 Likes

Redistribute to active users that have voted on snapshot thus far.

6 Likes

inefficiency of safedao, terrible

2 Likes