i am supporting of unpause token
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.
Hello , 30 oct , Daniel or other people may upload on spanshot ?
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 .
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?ā)
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
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.
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.
Just click on the āpenā icon and look at the top right hand corner where youāll see that time of the last edit.
Hereās also a screenshot of what was changed.
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.
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.
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.
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.
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.