you mean that 2 mystery addresses who own 12m tokens？I think they will show up at last minute and pass your ideas.
5 Likes
Option 4 seems well measured: A+B in parallel, using ⅓ of unredeemed tokens for A and ⅔ for B
- It rewards members who followed the original claim period’s rules without giving them “too much” additional token power.
- Provides a majority portion of tokens to help further decentralize the number of users receiving SAFE which seems important for the long-term health of the SafeDAO.
3 Likes
I’ve voted on Option 2 & Option 3.
I don’t think many who didn’t claim in time will become active governors - as this action was minimal and had enough time IMO. With the initial user distribution being relatively small given the timeframe of the snapshot (the start of Gnosis Safe until late last year), I think it’s okay to distribute most left-over tokens to initial claimers.
I don’t think a combination of A + B (or any inclusion of Option B) is productive, as the " alternatives" are not specified. Therefore, completing the first contributor reward distribution and returning anything left to the DAO for potential future distributions is the best next step.
6 Likes
I agree with you. I think all or all of them should be allocated to the active addresses that have been received, which are originally airdropped to users. The airdrop of addresses such as the future l2 layer or the Gitcoin donation should be allocated from the development foundation address, not from 50000000. The share of safe foundation is too large.
5 Likes
I don’t think many who didn’t claim in time will become active governors
This is a fair point @LuukDAO. With some form of option B (Explore other ideas for allocations), it is not specifically stating that tokens will be allocated to “extend” claims for those who did not claim originally.
For instance, if any form of option B passes, the next step is to decide what to do with these tokens. One potential route is to apply the same parameters from the original snapshot of time to a new snapshot of time. For example, a new snapshot could be Safe account usage from the end of the last snapshot threshold up until now. This second snapshot of time is significant because the amount of activity farming is likely low due to no token claim being expected after the first snapshot time period ended.
This could help improve the diversity of token holders and future decentralization.
4 Likes
This is a really important point. Option A basically is the “lazy” approach (the laziest approach would be to do nothing with these tokens). Option B allows for some nuance. We could, for instance, drop a portion to those who have actually voted on snapshot (if we wanted to attract more governors) or drop a portion to those who have been active in forums/discord (if we want to attract more contributors), or (as @adamhurwitz.eth stated in his post) drop a portion to those who have been using Safe recently.
Or we could do all 3…and more! It’s for this reason I voted for Option 9 (All B)
4 Likes
Through the voting of sep2 and sep3, it can be seen that the voting rights of safe have been controlled by two mysterious addresses, and the community has no right to speak. The number of safe voting addresses of 1,000 people is not as large as that of two people. The safe team seems to be I also acquiesced in this situation. Although I want to participate in the governance of safe, it seems that the opinions of ordinary voters are not important.
Suǒyǐ bǎ safe fēnpèi jǐ huóyuè de rén hěn zhòngyào, dànshì bù zhīdào zhège tí’àn zuìhòu de zǒuxiàng, yīnwèi chí yǒu 1200 wàn gè safe dì dìzhǐ zài wéihù zìjǐ de lìyì. Xiànzài kàn qǐlái tāmen bìng bùxiǎng ràng shèqū huòdé gèng duō de dài bì, yě zài zǔzhǐ dài bì de zhuǎnyí
So it is very important to allocate safe to active people, but I don’t know the final direction of this proposal, because the addresses holding 12 million safe are protecting their own interests. Now it looks like they don’t want the community to get more tokens and are also blocking token transfers
11 Likes
Hi! When we can begin the official vote? Should we wait for another month?
3 Likes
Hi Daniel,Wen we start the vote ???
4 Likes
Have I missed something? Is this vote closed???
3 Likes
Not yet voted on, it is temperature check to decide the options to be used that was voted on
Kindly hold on for this proposal to be officially posted to snapshot for final voting
3 Likes
Is final vote planned for this week Daniel ? cheers
2 Likes
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 
7 Likes
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
5 Likes
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)
5 Likes
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)
@lukas @tschubotz kindly help us with what @Daniel requested.
1 Like
@theobtl @adamhurwitz.eth Anyone good at coding? Daniel is in trouble and he needs help.
1 Like
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.
7 Likes