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

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.


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.


Absolutely not! Where did you read this? I didn’t say that and certainly didn’t mean to imply that - I think we’re on the same page here. All I was arguing for is that the proposal was last changed a few days ago and undergoes a new review period until the end of Tuesday. The proposal currently includes a mandate to use SafeSnap. It does not include the specific instructions and I’d argue it doesn’t need to. Anyone who takes the liberty to upload the proposal to snapshot from Wednesday will either know how it works or ask here for feedback, I assume, but I’d argue this are only practical questions of operationalising the proposals as it is today - not changing it.

That said, now might be a good time to discuss the SafeSnap specification.

That’s a valid argument. In any case, the proposal currently does not include options to differentiate a point in time, does it? Currently, the proposal would result in a binary yes/no vote of enabling transferability immediately. That’s how it would go to Snapshot, unless the proposal is being changed once again.


Btw, here is the step by step guide on how to enable SafeSnap on a proposal, I thought it might be useful:

  • Propose via Snapshot with the correct title, timeframes, choices etc. according to the Safe governance process guidelines.

  • Before publishing, configure the SafeSnap tx as follows, which will ask the DAO Safe to call unpause() on the token contract.

  • Select “add transaction batch”

  • Select Type ”Contract interaction”

  • Input safe token contract 0x5afe3855358e112b5647b952709e6165e1c1eeee as the to address

  • Leave the value 0

  • Leave ABI field as is - it should should auto-populate

  • Select unpause from the function dropdown

  • Finally, publish the proposal just as one would normally

To double check, expand the Batch transaction JSON dropdown and compare it to the following JSON, it should match up.


The change does not materially change the proposal, and as such does not make much sense to reset the waiting period. A similar thing happened with SIP-1 where we both agreed it did not substantiate a reset.


Personally, I don’t think this change is not material or insignificant, just because it fundamentally changes the nature how this proposal is executed: from Wednesday on, anyone can run with it and the execution will happen automatically through SafeSnap which previously wasn’t the case.

The change in SEP-1 was quite different in nature as it really just fixed typos and a few phrases that were not left over from previous editing.

Of course, it is not about just you and me agreeing. As you’ve seen here in the comments and vote, even this small fraction of community members didn’t immediately agree on whether „not material changes“ as you call them should trigger a waiting period or not.

If you ask me, we should make it a priority to build up this DAO in a way results in effective decentralized governance. This include the perception of it, and if we now start to bend and tweak the rules at the very beginning, this DAO may lose credibility. I believe we should rather focus our efforts on introducing more fundamental proposals around governance and tokenomics (e.g., constitution, governance framework, OBRA/SGP) which will define these rules and let the DAO vote on them rather than us two try guess what might be in the interest of the DAO.

1 Like

Let’s get this snapshot #2 going, we’ve waited long enough.

1 Like

Does @Arseny’s step-by-step guide for creating the Snapshot transaction seem correct to you? I think we should give a few more people a chance to review that. In about 36h, the renewed review period will be over anyways so I still think this goes hand in hand.

Awesome, thanks @Arseny! Looks great to me, but I don’t consider myself a SafeSnap expert.

Does anyone else have feedback whether this is accurate and will result in what we expect from the proposal text?

1 Like

I thought the SafeSnap settings had been checked internally by your team members, now it doesn’t seem to be the case lol.

I’m now curious who will take the proposal to snapshot?

@Daniel didn’t say anything about this.
It looks like @Arseny is professional,
Or will the snapshot vote submit by the team?

Of course, team members check this forum and review @Arseny’s SafeSnap specs. However, this proposal is a community proposal and not led by any team member who currently have other priorities to work on. With all the attention and support this proposal received from the wider community, it just seems reasonable that a tech-savvy community member would be equally qualified to review these specs.

I’m not aware of any team member intending to take the proposal to Snapshot. SEP-1 was uploaded by a Guardian who took the initiative and had sufficient SAFE tokens themselves. I assume SEP-2 will undergo a similar process.


I may upload this to snapshot , but give me full text for need to snapshot , i want make all correct .


Thanks, Arseny. I noticed some updates are needed on your guide. The improved SafeSnap config is as follows:

  • Create a Snapshot proposal just as you normally would do with the correct title, timeframes, choices, etc., according to the Safe governance process guidelines.
  • On the last step before publishing, configure the SafeSnap tx as follows.
  • Click “Add Transaction batch with JSON”
  • Add this transaction batch json:
        "to": "0x8cf60b289f8d31f737049b590b5e4285ff0bd1d1",
        "operation": "0",
        "value": "0.0",
        "data": "0xe009cfde00000000000000000000000029067f28306419923bcff96e37f95e0f58abdbbe000000000000000000000000a0b937d5c8e32a80e3a8ed4227cd020221544ee6",
        "method": "disableModule(address,address)",
        "params": [
        "to": "0x8cf60b289f8d31f737049b590b5e4285ff0bd1d1",
        "operation": "0",
        "value": "0.0",
        "data": "0xe009cfde0000000000000000000000004ecefc422c98a096ed8b56ead67477c4b6e8702b00000000000000000000000029067f28306419923bcff96e37f95e0f58abdbbe",
        "method": "disableModule(address,address)",
        "params": [
        "to": "0x5afe3855358e112b5647b952709e6165e1c1eeee",
        "operation": "0",
        "value": "0.0",
        "data": "0x3f4ba83a",
        "method": "unpause()",
        "params": []
  • If you’d like, verify the added transactions.
  • That’s it. Now publish the proposal just as you would normally do it.

Here are basic explanations for what the codes do:

  • It enables global transferability by calling the unpause() function on the Safe token contract. Until that, only the SafeDAO Safe was allowed to transfer Safe tokens.
  • Due to the fact, that the right of token transfer was limited to the SafeDAO Safe, user and ecosystem airdrop contracts were implemented as modules enabled on the SafeDAO Safe. Once global transferability is enabled, this is not required anymore. The allocation contracts can just be used directly. Removing not required modules from the SafeDAO Safe is just basic security hygiene.

On a more technical level, this means the following 3 actions to be executed:

  • Remove the module facilitating the user allocation (0xA0b937D5c8E32a80E3a8ed4227CD020221544ee6)
  • Remove the module facilitating the ecosystem allocation (0x29067F28306419923BCfF96E37F95E0f58ABdBBe)
  • Call the unpause() function on the Safe token contract.

Note: This does not disable the claiming process or affect the ongoing allocation claiming in any way. The claiming can now be done just directly via the respective contracts.