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

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!


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


inefficiency of safedao, terrible


Hi @Daniel , kindly take a look at the suggestions after your last edit and see which can be incorporated into the the proposal.

It’s almost a week you last updated the proposal.

Let’s move forward please.


Any update on this ??

I saw a proposal from ENS DAO that was very similar to this one.

A large number of OGs oppose the redistribution proposal, which is understandable. After they have obtained a large amount of tokens and made money from the treasury, they will naturally not be willing to dilute their power, nor do they want their large amount of tokens to depreciate.

Almost all “OGs” forget that the original intention of launching and airdropping governance tokens is to achieve decentralized governance, not to allow a few people to control all voting rights. It is not a currency that is simply measured by economic value.

Even without discussing this proposal to redistribute “tokens with economic value”, It’s just a simple decentralization of governance rights to users, this discussion still doesn’t get any support from any OG.

This is completely different from the positivity they showed when they discussed selling 10,000 ETH for wages.

I also saw many “OG” objections in this proposal of SAFE DAO, most of them support the extension of the claim period or the distribution of tokens to developers (instead of redistribution of tokens to users who actually use the product).

In fact, most of the addresses that did not receive tokens during the claim period are addresses (or inactive addresses) that are not interested in SAFEDAO. Extending the claim period means that all these tokens will be locked, further avoiding the dilution of power.

And they want to distribute the tokens to developers. Of course, these OG (delegate) want to distribute the tokens to themselves, not the majority of users.

Both proposals are interesting, and while neither has yet reached a final vote, I’m sure both turn out to be satirical.


I don’t agree with your example. ens is a valuable governance token in circulation, while safe is a token in lock-up, which is not comparable.

Sorry, I’ve had quite a busy schedule in the last weeks.

But have now cleared my calendar for the rest of the week so we can finally get to the finish line with this proposal.


Wen Submit Proposals for Voting, Ser

For those that didn’t observe…!

This proposal has been updated about 24 hours ago and some of the suggestions has been incorporated, notably is:

  • Redemption start period changed to September 1st, 2022

I wonder if this is a major change that will make this proposal remain under discussion for another 6 days as laid down by the rules
Not a major change which means this proposal can be push to Snapshot for voting



Before this goes to Snapshot, we should explore adding an on-chain executable component to it.

While a successful vote for Allocation B should only be interpreted as “signal”, a successful vote for Allocation A should trigger a transaction.

For that, I guess we need to deploy two new vesting contracts:

One of these two should have correct vesting data for the outcome that one of the options that grants 1/3 for Allocation A gets the most votes. And the other one vesting data for when one of the options that grants 2/3 for Allocation A wins.

I’m having a little trouble deploying the new vesting contracts with the revised data. Will look into it again today, and also reach out to some more people I know.

But of course it would make things easier if someone from the forum would take a look at it…

Another open question is whether or not SafeSnap even allows for only one of the two tx-payloads (“sending either 1/3 of unredeemed SAFE tokens to the vesting contract #1, or 2/3 to vesting contract #2”) to be executed.

Because from what I’ve read it might very well be that those tx-payloads can only be executed sequentially. In that case, we would have to take a different approach.


Can we vote? We have waited for 2 months for this.

Hi Daniel, it’s been a week since you said you cleared the schedule to finalize the proposal, so can we start voting this week?

Hi Daniel, i know there is an event at the moment. But did we progress regarding this please ? regards

1 Like

Hello, @ Daniel
man. I want to ask when the 5th proposal can be voted. We have been discussing it for more than one month. It’s time to vote! Thank you for your proposal.

1 Like

Hello, @ Daniel
man. I want to ask when the 5th proposal can be voted. We have been discussing it for more than one month. It’s time to vote! Thank you for your proposal. :grinning: :grinning:

1 Like


Before proceeding with this proposal, I decided to do a temperature check since I understand that not everyone (including me) is completely satisfied with the current voting options:


I’ll limit the voting options in the official vote to what gets voted on the most here, and perhaps drop this proposal altogether if there appears to be a clear majority in favor of making no changes.

See below the 11 different voting options (a little confusing, I know, but it should cover all preferences):

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 but not limited to 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 ⅓ of unredeemed tokens
  • Option 2: Only A, using ⅔ of unredeemed tokens
  • Option 3: Only A, using all unredeemed tokens
  • Option 4: A+B in parallel, using ⅓ of unredeemed tokens for A and ⅔ for B
  • Option 5: A+B in parallel, using ½ of unredeemed tokens for A and ½ for B
  • Option 6: A+B in parallel, using ⅔ of unredeemed tokens for A and ⅓ for B
  • Option 7: Only B, using ⅓ of unredeemed tokens
  • Option 8: Only B, using ⅔ of unredeemed tokens
  • Option 9: Only B, using all unredeemed tokens
  • Abstain
  • Make no changes

Note: The voting system is Approval voting, meaning you can select (approve) any number of choices, each selected choice will receive equal voting power, i.e. if you select two choices, each choice will receive the total voting power from you.


Voted :white_check_mark:

Kudos to you @Daniel !
This is such a nice level of work from you


Good temp check, but I think there should be at least 10m votes to ensure the result of temp check vote aligned with the real situation, I remembered that we did a temp check in SEP#2, but the result was finally quite different.


@Daniel thanks for all of your work on this! I know it’s a lot of folks asking questions and demanding your time