I like these options. It’s clear and should allow all votes to get accounted for. I lean toward the extended option because it seems fair to me. I’m in the field of spreading the token around and giving people additional time to claim.
It’s clear based on the interactions in this thread, there are likely more situations where projects wanted to claim but missed the window— it would be a shame for them to miss out on an allocation allowing them to govern SafeDAO because it’s a critical component of infrastructure for the ecosystem.
I like Option B or C so that some tokens can be researved for future airdrops and some will be given back to existing users. We may work out future plans to do another round of airdrop to attract more users.
Safe is a really great product. In terms of token distribution, I think that unclaimed airdrop tokens should not flow to the already wealthy, which completely deviates from the spirit of Crypto. What’s more, we all know very well that a large number of them are sibyl or airdrop hunters, but it doesn’t matter, they have already won the airdrop.
For this part of unclaimed airdrop tokens, I think it is more necessary to allocate them to real safe users who have not received airdrops. They only understand and use safe after the airdrop is over. There are very few people, but they are real users rather than airdrops Hunters, we should assign tokens to them a little bit!
I’ve been meaning to ask this, is our snapshot only programed for single vote options? ie. can we split out vote between two options? the idea behind this is that u won’t need to decide the single options like 80/20, 40/60, etc. You can take the total votes between the two options and calculate the percentage that way. it might end up as an average and look something like 72.9857/27.0143 but it will represent the average preference.
I approve of the detailed voting options but I still feel that Allocation B should be more concrete in that it approves the extended claim but requires a separate SEP to iron out the details. Seeing as we are using a single vote system, we are limited in what we can included in a vote. If we have the option to included more, we should do that. This will cut down the clutter when it comes time to vote for the SEP.
To clarify more, using the extended voting options above would not approve the claim extension, the next SEP would determine if we should extend the claim or use the token on another option (whatever is decided at that time). If approval is given to extend the claim then we would need to vote on how many tokens and how long a claim period will be.
My proposal is to include extending the claim period as part of Allocation B rather than referencing it for future proposals.
If a voter wishes that the claim period not be extended, they would vote for Options 1, 2 or make no change. If they approve the claim extension, they vote for Options 3 or 4.
Allocation B would read something like this.
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”) Declaimer: Voting to include Allocation B serves as a signal to considering other ideas and as an approval to extending the claim period; final details on extending the claim period and/or considering other ideas for allocations requires another SEP.]
Also, for Options 1 and 2, what happens to the remaining tokens? they go to treasury?
I am more inclined to option A. The reasons are: 1. This part of the redeemed users is continuing to pay attention to safe, so many people in the market will feel that this project is very reliable, and the use or payment has finally been rewarded; 2. This part After users get more tokens, they will definitely expand the publicity, which is more conducive to improving the popularity of the project; 3. Oppose to open this part to unredeemed users again. They are likely to be harvesters and unfaithful fans. Can’t remember the project, so they didn’t redeem it, even if they got the tokens again, they just threw it away without thinking about the development of the project;
Quick note: I have revised the proposal again, thanks here to @theobtl, as well as everyone else participating in this discussion, for the constructive feedback and suggestions.
The SEP is still a work in progress, among other things the part concerning the technical implementation is still missing.
However, I think that now, after a good month, the time has come to move the proposal into Phase 1 and turn it into an official SEP.
The last small modifications as well as adding the part about the technical implementation will be done during the weekend and early next week.
Thanks @Daniel! I’ve moved the proposal to the SEP section, this proposal is number 5.
Makes sense to me. Once we have a specific definition of recipients and a draft of the technical implementation including SafeSnap, we should probably give the community time to review these (the stakes are high after all!) and audit them, including Safe team members who set up the initial airdrop and are most familiar with the details.
i believe its a good initiative for safe dao if you can extend the snapshot date and also include the ones who have created their wallet on other chain like polygon, arbitrum etc
Why you are giving tokens to users they already having?
Add more chains to airdrop crietarea, it will help to onboard More users to safe governance.
Make it more decentralized by onboarding new members to Dao.
Recommended to add optimism, Bnb, polygon chains for these tokens.
I agree with some others that we should endeavor to exclude airdrop farmers. Reallocating based on product usage and governance participation is pretty key - these are the kinds of DAOs members we want
I worry the outcome of this vote using the existing choices won’t be very definitive. Seems like we would have to immediately have another proposal to refine the criteria for A and B
The ideas from some of the people above are valid and good. For instance, including other chains for a second drop sounds fair. As all these ideas would be considered under Allocation B, I will not go deeper into different options here though.
Question regarding The options: Why do we consider 1/3 or 2/3 of unredeemed tokens? Why not 100%, 50%, 0%, or more generally x%? How could a good percentage be determined? Also, I don’t really get what the difference between Option 1 and Option 3 is (and 2<->4). Abstaining from this vote and supporting Allocation Bwould mean the same thing, right?
If the current list of options are put up for a vote, the way I would see it:
“Make no changes” would mean none of the above. That could be “only B, not A” as in “only explore other ideas for airdrops, not reward those who have redeemed the first airdrop”. That could also be “no further airdrop at all for now”.
“Abstain” could be seen as a light version of that, but can go either way. “Abstain” counts towards the quorum, so practically “Abstain” indirectly supports whichever options wins by helping securing the quorum.
I agree. It’s not hard to figure out which addresses were airdrop farmers by looking at addresses that claimed $SAFE before the claim period ended.
I found multiple addresses that claimed the airdrop within minutes of each other that had a pattern of - deposit eth - create a Safe - deposit eth to Arbitrum - deposit eth to zkSync with almost identical transactions on each address.
I think airdrop farmers should be excluded if there are further distributions of $SAFE.
Makes sense, thanks!
So in the current version, we do not have a “Only A” version then, correct? I am not saying there should be one, I am just trying to understand what the meaning of one or two thirds is, and why other allocations are not considered here.