[SEP #2] Community Initiative To Unpause Token Contract (Enabling Transferability)

I put some more of my conclusions here about the recent vote: Discussion about SafeDAO voting power - #4 by raynemang

1 Like

Thank you for this, i agree

perhaps we should encourage SAFE team (and ourselves) to label whale accounts if possible (not suggesting doxxing, just contextual info using and ENS domain or something)


People chose to delegate their voting power to these addresses man


@Daniel Maybe it’s worth recreating a vote? Just for confidence.

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


(post deleted by author)

1 Like

any update?
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 ?

(post deleted by author)

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.image

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.