Is final vote planned for this week Daniel ? cheers
Are you still with us?
Happy 3 months anniversary to this proposal !!!
Dear @Daniel , let’s get this to snapshot and wrap it up to divert attention to another important proposal.
Indeed, this has been the most captivating proposal among the active proposals.
Thank you for all you do, @Daniel
Agree! The safe Dao has been set up for 7 months and we should solve the distribution immediately and move on to the next topic especially on the utility of the token
Yes agreee its been a long waiting for the final vote captain thank u
Everyone is always asking “Wen official vote?”, nobody is asking “How can I be helpful?”.
It is not my unwillingness that is holding up this proposal, but open questions when it comes to the technical implementation.
For example: Do we necessarily need to deploy new Airdrop contract(s), or can we simply create new vestings in the existing VestingPool via the addVesting() function? Who is the manager of the existing VestingPool?
Each vesting pool has a manager. The manager of a Vesting pool can create new vestings and can pause, unpause or cancel managed vestings.
When adding a new vesting it is required that enough tokens for the vesting are available for the vesting contract. Each time a new vesting is created the vesting contract will keep track of this, so that all vesting on the vesting contract are backed by the required amount of tokens. This ensured that there are enough tokens available for all vesting when they can be claimed.
Maybe I haven’t communicated that clearly enough, but I won’t be able to do this without the help of others, as this is not my area of expertise.
If anyone wants to help, here is a link to the GitHub repo, where the VestingPool and Airdrop contract from the initial airdrop can be found: GitHub - safe-global/safe-token: Safe Token
Of course, it would be ideal if the people behind Safe Foundation, who took care of the initial airdrop and therefore know more about it than anyone else, would help us make an informed decision by providing additional context about the technical implementation or perhaps even provide guidance on the best course of action.
In the last few days, I’ve exported the data showing the additional tokens each address is eligible for if any of the voting options that include Allocation A passes the official vote from Dune to Google Sheets, from where anyone can easily download them as CSV files:
- Only A, using all unredeemed tokens (Dune query, Google Sheets)
- A+B in parallel, using ⅔ of unredeemed tokens for A and ⅓ for B (Dune query, Google Sheets)
- Only A, using ⅔ of unredeemed tokens (Dune query, Google Sheets)
- Only A, using ⅓ of unredeemed tokens (Dune query, Google Sheets)
- A+B in parallel, using ½ of unredeemed tokens for A and ½ for B (Dune query, Google Sheets)
(Those are the top 5 choices of the temperature check)
I was actually thinking we will firstly vote out the proposal on snapshot before the Safe Team helps with the technical arrangements that will follow base of whatever that is decided from the vote.
I apologize for being naive in this regard. I have little to zero knowledge in coding
The aim of the pressure was never to inconvenience you but rather to ensure we are moving at the right pace.
You have indeed tried and I personally appreciate your efforts
Now, let’s turn to the right side (The Safe Team)
I know we did discuss and consider before to include an onchain execution in this proposal, at least for allocation A. Given the fact that we would have at least four different specifications for an onchain execution (*) as well as “Make no changes” which would not require any specification at all:
How do you feel about keeping this proposal as a signal to the Foundation which could then focus on the specified outcome, instead of preparing specifications for four/five outcomes ahead of time?
(*) If I’m not mistaken, the four specifications (next to “Make no Changes”) would be: 1/1 for A, 2/3 for A, 1/2 for A and 1/3 for A. AFAIK, allocation B was never supposed to be specified through onchain execution as part of this proposal, so I’m not including those options.
There are many options in this proposal, I don’t think it is necessary for community members to deploy contracts. This will only increase the workload of community members and the safe team at the same time. It is not an efficient way to deal with it, and it may not be feasible. As theobtl said, I suggest that we only need to submit the proposal directly to the snapshot for voting, and the voting results will be executed by the safe team.
Yes, that is acceptable.
I have now updated the proposal with the latest changes, and if no edits or other clarifications are requested, then we can put it on Snapshot in 6 days.
It is exciting to follow the development of this proposal. Watching SafeDAO grow has been thrilling, like a toddler taking its first steps. @Daniel has done a fantastic job presenting all possible token allocation options to the governors . However, let’s not ignore the elephant in the room - governors having the power to award themselves tokens is like putting a cookie jar in front of a kid and telling them not to eat it. So, it’s no surprise that Option 3, which allocates all the tokens to themselves, was the preferred choice during the Temperature Check.
Deciding the best way to distribute tokens is challenging, as highlighted in Messari Governor Note. There are several factors to consider. Whether those who missed out on the initial allocation would make suitable governors if they claimed their tokens and if those who have already claimed tokens would make better governors. Additionally, we should consider granting tokens to new potential governors from actual voting participants and DAO contributors.
It is worth avoiding the path of least resistance, which entails allocating all tokens to the governors themselves. Achieving a suitable distribution can be challenging, but starting with equity is an excellent way to begin.
Here’s what I’ve discovered before making any binding governance decisions, especially for everyone considering voting:
Option 4 is a top contender. It rewards early claimers and promotes decentralization, despite the low voter turnout of the temperature check. About 20% (or 8% including Ecosystem allocation) of redeemed tokens voted, which falls short of the 10 million required for a quorum. There is a need for new governors in the mix who will engage in more temperature checks in the future.
Combining A and B isn’t the best idea, though. B holds more nuanced, so allocating more tokens for other initiatives can greatly decentralize voting power.
Concentrated voting rights from a few addresses are a concern. A simple single-choice vote won’t fix this, and we can’t count on token holders to always vote as good actors without conflict of interest.
The utility of the SAFE token and how to scale it is a critical issue that only the best governors can tackle. It’s crucial to get this vote right now, don’t sit this one out.
Who will lead the charge? Daniel has taken the lead for this critical proposal from day zero, which is laudable, but the task for its implementation is enormous. Until more technical participants join the fray for community implementations, all proposals should be signals for execution to the Safe Foundation. They’re the primary guardians of the DAO at this stage, and seeing this alignment is good. [SEP #5] Redistributing Unredeemed Tokens From User Airdrop Allocation - #193 by Daniel
To sum up, Option 4 is a suitable choice for currently distributing unclaimed tokens. But we need to address the concentration of voting power and the token’s utility so the more skewed the vote outcome towards Allocation B, the greater balance between optimizing for decentralization and active voter participation.
B represents the governor who is not active. Have you ever thought about this problem? What if there are many gods who have not received the tokens allocated to B, and then there will be a large number of airdrops and no one to claim them? The scenario is that someone will not receive tokens before the time limit, and new proposals will appear.
In fact, your concerns will disappear after tokens are allowed to trade, and safe also has allocations for ecological development.
So I think currently assigning to A is the best choice. Option B will lead to more problems.
They even don’t want to claim their tokens and why you believe they will be enthusiastic about voting?
The crucial thing is that if you extend the period and after three months we still need to discuss the same proposal on how to deal with the tokens unclaimed.The community did not have enough tokens for voting and the trade is forbidden now.That’s the reason why the Dao is not decentralized.
Remember the sep 2? Two addresses(I believe the someone knows who they are) dominate the vote and we do not have other choices.
If you really want to make the Dao more decentralized and in my opinion we need to focus on finishing the 5 milestones and unpause the tokens to let the market to attract more participants on governance.
Options A and B cannot fundamentally solve the problem
Ps: I don’t like your cookie jar stuff. Your description makes me feel like we are criminals。Our power for voting origin from the Dao and the Team and the Project. They can get all the tokens or the power back and I have no opinion. But I dont like being called like that.
Everyone wonders “wen token”, but no one asks:
- why did we start creating a token, if in the end every time we talk about it, we look like starving people;
- why 2 addresses have (4 and 8 million safe, and can therefore decide alone the outcome of the votes);
- why everything seems long and complicated. Daniel criticizes us for not thinking about how the distribution will be done, but the safe team is full of very competent engineers. Isn’t it their job to know this?
I do not support the opinion of some people, especially the continued airdrop l2, optimism Arbitrum most of the users are airdrop farmers, many of them using hundreds of accounts sniping SAFE airdrops
totally agree Safe lfg
Is it still okay to receive an account that has not been received before?
Indeed, I don’t agree with you. I agree that all of them should be allocated to the active users who have received them. If you want to really decentralize, you must open the safe token transfer. Only after the market test can you find the real safedao members. I hope you can see the safe token transfer question in Proposal 6 or 7.
It is true that too many people have forgotten, and it would be unfair to erase the rewards of those who have participated in the project just because they forgot