@Daniel Maybe it’s worth recreating a vote? Just for confidence.
[SEP #2] Community Initiative To Unpause Token Contract (Enabling Transferability)
maybe, but I’m not sure about that
seems reasonable enough to assume
I went to look because that makes a lot of sense tbh
but, both of the voters—0xfB2aD9007F2D62a973f71Af206242eE4bD790b2C , 0x7c3d54Be8dD9946dA59feD648bfAD294ae17105E— haven’t claimed and the UI says that they were awarded the tokens
If recreate, you don’t have to do the actions to turn the modules on/off. Unpause only
Maybe voting should only be “tokens on hand” and “delegated”? Excluding the vesting?
Just idea for discussion.
That seems like a decent solution
I’m not trying to create any bad situations, but after what has happened with the industry I think it’s paramount that we as a community demand transparency
And this situation appears to be one that could use more transparency
i think recreating vote could be cool…
No , project RIP , 2000 users say Yes , 5 users Say NO . Not free token - no freedom .
Note that the daily collection of airdrop is about 25，maybe it’s time to make the forum active and discuss. guys, the enthusiasm of the World Cup cannot stop the enthusiasm of the safe token discussion.
my tokens dissapear when i make next safee in eth to clam then what now my voice is also gone > why ?
but if something i plan to be part not to throw it …
I support this. If we want the snapshot vote to happen after the claim is completed, then we need to create a new proposal in the near future.
this time it is worth creating a proposal without these two points, because because of them some people voted against.
I see where you’re coming from if you trying to improve the proposal, remove controversial parts and optimise it so that it would likely pass in the future.
Although, let me refer back to the reasoning behind including these two pieces:
In short, removing this modules makes absolute sense IMO, it has no risks but even reduces risks in the future. Just because these modules won’t be needed anymore and by reducing complexity, we can expect on-chain governance to be more secure.
Do you still see an argument against removing these two modules?
When it comes to what I assume is your intent and finding our how likely it is for a new proposal on enabling transferability to pass in the future, I’d suggest to instead revisit the arguments brought up and get a sense of what the community considers milestones to be met before voting on transferability again. That allows us all to have a much clearer idea on when such a proposal is put up for a vote again, so that we have clarity on that. In the meantime, that would also free up resources to work on other parts of a governance roadmap, such as the constitution, OBRA and other proposals. Does that make sense to you?
I’ve been writing up a new SEP based on these arguments for us to align on such a timeline. It’s almost ready to share, expect it to be live before the community call on Monday.
Hello. Thanks for the answer.
Yes, I understand what these modules are for. But, I’m a software engineer. And those who are not a developer, for example ([SEP #2] Community Initiative To Unpause Token Contract (Enabling Transferability) - #157 by MicahZoltu) are afraid of unnecessary offers. You see, here we are talking about something like the atomicity of operations. It is necessary either to explain in detail why these actions are and what they do, or not to add them to the sentences.
Many small sentences, or one big sentence, but having a detailed description of each action, based on my little experience, they work much more efficiently and people are not “afraid” that something is wrong with the “final large transaction”.
Yes, I understand the things that should be done before unlocking the token. Liquidity, pools and other activities are important, very good and useful. Simply, this thread is about unlocking and I’m writing here about unlocking. Those. one discussion, one topic.
Yes, complex solutions are good. But, it’s good if a large steak can be cut into pieces and eaten in small pieces. My post is about that. And that if we want to be able to do something with tokens in January, then we need to not sit back and work on this issue. (+ the lack of a process, it seems to me, can negatively affect the involvement of the community at the very start).
I’m sorry, English is not my native language and I don’t travel, so it’s far from ideal.
Makes absolute sense. That is also exactly the reason why it was proposed to remove these two modules! After transferability is enabled, these two modules serve no utility. They would only be add to unnecessary complexity of our setup which is why it was suggested to remove these:
Removing not required modules from the SafeDAO Safe is just basic security hygiene.
Aren’t we on the same page?
Have you decided to enable token transfer, will you start voting on Snapshot again?
We will see … for sure better make good decision than fast …
To continue and structure the conversation on next steps after this proposal and align on a shared understanding of milestones to be met before we vote on enabling transferability again, please see this SEP:
This proposal [SEP #2] Community Initiative To Unpause Token Contract (Enabling Transferability) has moved to phase 2 for a Snapshot vote:
Start date of the vote: Nov 3, 2022, 12:14 PM UTC
End date of the vote: Nov 10, 2022, 12:14 PM UTC
Following the Snapshot vote, the quorum was met and the proposal was not accepted.
Hello, The decision to not allow the transfer was taken several months ago. How long should it take before a new vote is held to see if people’s decision has changed? Thank you
Transferability will be enabled when all the 5 milestones listed here have been completed
Check it out.