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

[memeb1t]

SEP5 took three months, and I am sure that allocation B will take us longer, and there is a high probability that it will not be completed through one proposal, but several proposals related to allocation B, Now obviously we should prioritize discussing DAO governance structure and OBRA and token utility, otherwise we may not even pass these proposals until 2025.

[Ritesh_Trivedi]

Its a nice idea. Redistribute remaining unclaimed tokens to all eligible addresses from the first drop. Same calculation, slightly less tokens.

[Daniel]

Due to the complexity of preparing for 4 different outcomes in advance, I refrained from including an onchain executable component to SEP-5.

Theo mentioned that the Safe Foundation is in principle open to seeing this proposal as a signal and implementing its result in their function as steward of SafeDAO.

If that doesn’t work due to whatever reason, and here it would be important to get clarification as soon as possible, we’ll have to do another SEP, as you mentioned, with an onchain executable component as part of it.

[theobtl]

@Daniel

Theo mentioned that the Safe Foundation is in principle open to seeing this proposal as a signal and implementing its result in their function as steward of SafeDAO.

That’s correct, certainly for the signalling part.

The implementation too, however the teams have already defined their sprints for Q2. Based on the requirements defined in the proposal for “Allocation A”, I’m checking with the teams whether and when they have the bandwidth to take care of the technical implementation of this proposal.

The main question is when that can be completed – and whether we would want to crowdsource this task here in the interest of time. In any case, the final implementation has to be audited by the ones most familiar with the matter, which is the Safe Ecosystem Foundation. That step, we cannot speed up.

For the future proposal defining “Allocation B”, we can optimise this process by defining the technical requirements, effort for implementation & auditing and who takes care of that as early as possible. That can be but doesn’t necessarily have to be the Safe Ecosystem Foundation, but could also involve other stakeholders, e.g. for this proposal the corresponding communities of these chains.

[bryanw]

@Daniel

Due to the complexity of preparing for 4 different outcomes in advance, I refrained from including an onchain executable component to SEP-5.

Theo mentioned that the Safe Foundation is in principle open to seeing this proposal as a signal and implementing its result in their function as steward of SafeDAO.

If that doesn’t work due to whatever reason, and here it would be important to get clarification as soon as possible, we’ll have to do another SEP, as you mentioned, with an onchain executable component as part of it.

Agree with your concern…

[pangtong]

I quite agree with you. I have always been a loyal user of SAFE. Today, I found that I am eglible to claim SAFE airdrop token, but I can no longer get it.
I think setting up a new claim period for those who were eligible for the initial claim but had not redeemed their allocations (“extend claim period”)* is best choice for SAFEDAO communtity. @Daniel @theobtl

[n00b21337]

“64,4% of the tokens from the user airdrop allocation not being redeemed” should tell you that initial distribution was poorly done, yet the main thing proposed here is how to get more tokens for those that already got it, very sad, pure greed. There shouldn’t be any option for people who already got them to get more, just put your efforts into a huge number of those that didn’t and find a way to give it to others like GNO holders etc

[adamhurwitz.eth]

I believe GNO holders had an opportunity to convert GNO to SAFE within a certain timeframe over the past year?

The good news is that Option 4 that passed allocates an amount of SAFE to a potentially new subset of users to be defined in a future proposal. A simple solution could be using the same parameters as the first air drop, but changing the timeframe to include more recent active users.

[ChingChongs194]

hey @Daniel @theobtl is it possible for you 2 to work together on getting this vote finalized and smart contracts built for the redistribution of unredeemed tokens. We all thank the both of you for getting it this far and i do feel its important to carry this proposal all the way to the finish line with a executed smart contract being the final move for the tokens to fall into the hands of the claimants. if money is an issue my team will gladly pay for your time to get this done as we feel its important.

[theobtl]

@ChingChongs194

hey @Daniel @theobtl is it possible for you 2 to work together on getting this vote finalized and smart contracts built for the redistribution of unredeemed tokens.

Now that the Safe team is back from ETHTokyo, I’m coordinating with them when my colleagues can take care of the technical implementation and related work (calculation of individual allocations, user interface, auditing, …). The Safe team is certainly best positioned to get that done – there’s a lot of overlap with the first airdrop after all, but my colleagues also have other workstreams and OKRs to deliver on. I’ll post an update on the timeline and next steps here as soon as I can.

[melai16]

Any update when is the final decision guys

[Ankarrr]

Hi guys, I find this proposal hasn’t been implemented. I’m a software developer with several years of experience in the crypto space. If you guys need more hands to build/test/review, I’m willing to help. Thank you!

You can find me on my Twitter: https://twitter.com/MrAndersonChen

[mmichel]

Muito Bom! Eu sinceramente achei muito bom!

parabens!

[Damboy]

I will suggest two potential solution: Allocation A, which redistributes the tokens to those who have already redeemed their allocations, and Allocation B, which explores alternative ideas, such as extending the claim period.
Open discussions and community involvement are crucial for making informed decisions. Active participation from community members will help shape the future of SafeDAO’s governance and ensure fairness.

[Binqq]

Hey can someone get this proposal done? It’s been two months since the vote passed, and it appears to have been completely ignored as a formal proposal.

[RSivakov]

Maybe it will be more effective if you start making a draft of a contract that solves this problem and publish a link here, and we will help with the help of pr in the github?

[Rich_Sports]

@Daniel

In total, around 32M out of 50M SAFE were not redeemed. Since this leads to an unintended imbalance in the distribution of voting power, I believe it’s important to e

Oh, wow. That’s a lot of unclaimed $SAFE.

This very low redemption figure indicate the airdrop communications campaign was inadequate and users did not know to redeem. I know many of those users. Despite using SAFE multiple times a month during the term, I was somehow unaware that I needed to redeem.

Extend the airdrop so legitimate users can redeem and participate in governance…

[Rich_Sports]

@n00b21337

“64,4% of the tokens from the user airdrop allocation not being redeemed” should tell you that initial distribution was poorly done, yet the main thing proposed here is how to get more tokens for those that already got it, very sad, pure greed. There shouldn’t be any option for people who already got them to get more, just put your efforts into a huge number of those that didn’t and find a way to give it to others like GNO holders etc

This. If you want the defensibility of a DAO you must enact a reasonable decentralized distribution.

[Ankarrr]

Solution

I have read the Airdrop contract, which was well-designed by @rmeissner. I believe we can use the same contract to redistribute the unredeemed SAFE tokens.

Here’s a draft process for setting up the Airdrop contract to redistribute unredeemed tokens:

1. Deploy a new Airdrop contract. When deploying the contract, we need to set the redeemDeadline. According to the Allocation A in SEP #5, the tokens should be redeemed before July 1st, 2023. Therefore, we should probably set the value as 1688255999 (July 1st, 2023 11:59:59 PM (GMT)).
2. Initialize the new Airdrop Contract. This requires the poolManager to call initializeRoot() to set the new Merkle Root.
3. Claim unredeemed tokens from the old Airdrop contract. This can be done by calling the claimUnusedTokens() function by poolManager.
4. Send unredeemed tokens to the new Airdrop contract.

The reason we are not able to reuse the old Airdrop contract instance is that redeemDeadline cannot be reset after the contract is deployed.

Issues

1. In addition to the smart contract, we will need support from both the backend and frontend. The backend needs to provide the token amount and Merkle Proof as inputs of redeem() to the frontend. The frontend needs to provide the UI for Safe users to check their eligibility and call redeem() of the Airdrop contract.
2. There are only about 27 days left before the redemption deadline on July 1st, 2023, so it sounds unrealistic. The original vesting start date is September 1st, 2022. I think we need to agree on a new start date and end date. I suggest we shift the start date to July 1st, 2023, and the end date to April 1st, 2024.

Please let me know if you have any feedback. Thanks!

[Daniel]

@Ankarrr

There are only about 27 days left before the redemption deadline on July 1st, 2023, so it sounds unrealistic. The original vesting start date is September 1st, 2022. I think we need to agree on a new start date and end date. I suggest we shift the start date to July 1st, 2023, and the end date to April 1st, 2024.

This deadline is unfortunately not optimal, and a relict of the original plan to add an onchain executable component to the proposal, which due to the multitude of different voting options was later discarded – but the delay this would cause was not foreseeable from my side and therefore I did not modify it. That was certainly an unfortunate decision, for which I must also apologize.

I personally don’t see anything against extending the redemption deadline. Since SEP #5 in its final form constitutes a signal to the Safe Ecosystem Foundation, it is at the discretion of the SEF to make changes to the specified vesting start dates and redemption deadlines. However, I think this is more of a formality as it doesn’t seem to be in the interest of SAFE token holders to have them vote a second time on the same proposal.

At the last community call I heard that at least from the side of the SEF this proposal is not forgotten. Theo has meanwhile, as far as I’m familiar with this, taken a career break and thus the person who probably had the broadest knowledge about this proposal is no longer present. This has certainly not helped to ensure the implementation of this proposal in a timely manner.