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

i am supporting of unpause token

5 Likes

I also support unpausing the SAFE token.

In addition to the points raised before, if we want to grow a committed community and attract new DAO contributors, itā€™s better to have transferrable tokens while we are in a bear market. Bear markets are for builders and early believers, while bull markets are full of noise and speculation.
Itā€™s better to let potential dumpers dump tokens when itā€™s cheap, so the cost of entry for new participants is lower.

8 Likes

Hello , 30 oct , Daniel or other people may upload on spanshot ?

1 Like

The proposal was last changed two days ago, so the review period was reset and it could go to Snapshot on Oct 3, am I mistaken?

I think no , where change ? Pls help me find change) , i think its mistake .

3 Likes

But these changes do not apply to the subject matter of voting. They just clarify the nuances of performance. Realisation.

(This is, for example, like ā€œletā€™s choose a font for the title of the sentence and shift the date again?ā€)



4 Likes

I honestly am getting bored reading all these pro unpausing comments. They all say the same thing and nothing is being added to the conversation. This comment, however, adds an interesting point regarding the legality of claiming tokens with a value attached to them.

Agree with you.
Letā€™s make a poll

  • Delay
  • Donā€™t Delay

0 voters

3 Likes

The only change made this time around are changes to how voting results are excuted, not the content of the proposal itself.

Weā€™ve actually been waiting a long time, so waiting a few more days is not unacceptable personally. But I donā€™t see why such a change could cause delays, and I canā€™t understand if this boring process will bring any benefit to us. In fact this is not effective governance, just pointless procrastination.

1 Like

Helloa theobtl, I have a question. As far as I know, the controller of the SAFE token contract is actually the team, and the token contract is written by the team, It seems that only the team has the ability to submit this proposal to snapshot? (call SafeSnapModule in the snapshot vote)

And the proposal has two different time options for unpause (immediately/after claim period end), is this technically achievable if the module needs to be invoked?

100% agree. I do not see any reason why this hasnā€™t even gone to snapshot for a vote yet. If only a small minority of participants have enough tokens (delegated or otherwise) to decide what is even put to a vote, then the majority of participants are effectively censored.

If the participants currently holding these large quantities of tokens are concerned that unpausing will cause the token to underperform in the free market, then I believe there are very different agendas at play. I have seen many posts mentioning ā€œbear marketā€ conditions mentioned in arguments to keep transfers paused. Why would the current market price of tokens factor into this decision if at least some motivation to keep transfers paused is not to wait until they will fetch a better price? If thatā€™s your concern, please state it clearly.

As far as token trading being a distraction to some, that should be of little worry to those of use that wish to continue to build and maintain this project. I am certain those of us who contribute constructively have the discipline to avoid being distracted by the candles on the daily charts.

Finally, I donā€™t feel that having a minority of users ā€œdumpā€ their tokens on the market as soon as the token is transferable to even be a completely negative thing. If they are itching to sell, then I doubt they have or plan to participate constructively in the project. Their tokens will just move to the hands of those who do care to participate. I certainly would be a buyer of such tokens.

2 Likes

Just click on the ā€œpenā€ icon and look at the top right hand corner where youā€™ll see that time of the last edit.
Screenshot 2022-10-30 at 12.09.06
Screenshot 2022-10-30 at 12.09.20
Hereā€™s also a screenshot of what was changed.

1 Like

Weā€™ve discussed this before in SEP-1. Fact is, we donā€™t have a specific-enough governance framework (yet!) that defines when a delay period applies. As long we donā€™t have that, I believe we should interpret the rules in a more narrow sense and just reset the voting period. Making use of SafeSnap is also certainly not comparable to correcting a typo or changing fonts, but has a significant impact on the nature and implementation of this proposal, Iā€™d argue.

1 Like

This is a stretchā€¦just vote to unpause and let the sellers sellā€¦for those whoā€™re worried about the token underperforming you obviously donā€™t know how to trade nor know how momentum works.

Some of yā€™all over complicate everything.

You canā€™t time the market, you canā€™t stop sellers from selling.

1 Like

Lots of community members feel like you, it seems. Lots of community members also donā€™t see us needing to rush here. Judging by the comments in this thread only is certainly misleading due to the bias that those who donā€™t think we need to rush likely donā€™t bother commenting here.

IMO, if we look at our simple governance process, we should wait until Tuesday has passed and if no more changes were made by then, the proposal could be uploaded to Snapshot.

Although, if anyone feels strongly about uploading it sooner, they could upload it to Snapshot right now (themselves or coordinate with someone else who has the required amount of SAFE tokens). In that case, the token holders will judge not primarily about the contents of this proposal, but may vote it down purely because some think it didnā€™t follow the governance process. Thatā€™s a risk the uploader would have to take into account.

We could also use the remaining few days to align on the exact specification and proposal parameters that are required so that the Snapshot proposal can be executed through SafeSnap. This includes @LunaMaxiā€™s recent comment. Setting up SafeSnap isnā€™t that trivial, so we may anyways need until Tuesday to figure out the specification, give everyone time to review it and prepare it in a way so that on the proposal can be uploaded to Snapshot from Wednesday without any further delay, by whoever will take the initiative.

4 Likes

So what exactly was the waiting period for from SEP1 ā€˜til now?

Do you mean how long SEP-1 remained in a review period after its last change?

That was six days.

See also here:

And here:

Well Iā€™m glad theyā€™re only your opinion because bruhā€¦

Correct me if Iā€™m wrong but t should be the case that the SafeSnap Module controls the Safe that is the token owner. Meaning, anyone could trigger this proposal if they use the correct SafeSnap specification when setting up the Snapshot proposal.

2 Likes

Thanks for your explanation, itā€™s perfectly acceptable to put the proposal for a snapshot vote on Wednesday, and you mentioned that it takes some time to debug the SafeSnap parameters, which I also agree with.

But Iā€™m very worried that when the team edits the SafeSnap parameters into the proposal would trigger a new 6-day delay again, because you may say that the code needs to be reviewed by the community for another 6 days after the release, if this happens, that is really ā€¦

I have to point out that as the end of the claim period draws nearer, it makes less sense to have two time options for proposals, and you have to be mindful of that.

Finally, itā€™s Sunday, according to my observation, this should not be your work time, but you have spent a few hours reviewing and responding to these questions, thank you for your intentions and efforts, have a good day.

5 Likes