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

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.

6 Likes

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.

6 Likes

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.

2 Likes

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.

2 Likes

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

2 Likes

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": [
            "0x29067F28306419923BCfF96E37F95E0f58ABdBBe",
            "0xA0b937D5c8E32a80E3a8ed4227CD020221544ee6"
        ]
    },
    {
        "to": "0x8cf60b289f8d31f737049b590b5e4285ff0bd1d1",
        "operation": "0",
        "value": "0.0",
        "data": "0xe009cfde0000000000000000000000004ecefc422c98a096ed8b56ead67477c4b6e8702b00000000000000000000000029067f28306419923bcff96e37f95e0f58abdbbe",
        "method": "disableModule(address,address)",
        "params": [
            "0x4ECeFC422c98a096eD8b56EaD67477c4B6e8702b",
            "0x29067F28306419923BCfF96E37F95E0f58ABdBBe"
        ]
    },
    {
        "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.

7 Likes

Fantastic @0xAA! :100:

This should do the job, unless anyone notices anything that’s wrong or missing? Anyone please make sure to give any feedback by Tuesday EOD.

Given there’ll be no further changes, it seems the proposal may move to phase 2 from Wednesday 9am UTC, based on @Daniel’s proposal text (with formatting and links) and following @Arseny’s and @0xAA’s instructions for automatic execution through SafeSnap.

The finish line is close, still let’s please give everyone a last chance to review for another 24h and adhere to the review period of six days. :pray:

4 Likes

Hi, first of all, I’d like to apologize to everyone who messaged me in the last two weeks and didn’t get a reply, as I’ve been hit pretty hard by Covid and had to ruthlessly prioritize who I reply to – at the end of the day, my recovery came before everything else and I didn’t always have the energy to communicate with those who’ve reached out to me via all kinds of channels.


As some of you may have seen, I changed the proposal a little bit a few days ago to make it clear that the SafeSnap module should be used. I would like to thank @Arseny and @0xAA for the great input on this.


I’m also glad to see that there was a lot of discussion in the time I was away, because the intention behind this proposal was always to engage the community.

And I’m looking forward to seeing the voting process begin tomorrow. This is a key moment as now the SAFE token’s transferability or non-transferability (depending on the outcome of the vote) gets its legitimacy from all of us voting.

Maybe this proposal will go through, maybe we will have to revisit unpausing the token contract in a few months. In the end, no matter how the vote goes, it is a victory for the autonomy of SafeDAO.

9 Likes

So sorry to hear Daniel, wishing you a full recovery very soon!

Thank you for being so engaged in our community, even despite your recent and presumably still ongoing process with Covid! The quality and attention to detail in this proposal clearly resonated with a lot of community members.

The last days also demonstrated how well this community can work together, discussing a proposal and coordinating next steps even in your absence. That was an interesting and useful test, if you will. :slight_smile: I wonder how we can improve the design our governance process here, keen to hear anyone’s thoughts (in a separate thread) or even organise a retro call!

5 Likes

One more thing … for the sake of being able to use the SafeSnap module and to avoid ambiguous results, I back off from my previous stance that we should have 3 voting options (immmediate unpausing, unpausing after claim period, make no changes/decide later) and I recommend limiting ourselves to two options:

  • Enable transferability
  • Make no changes/Decide later
2 Likes

On that earlier note, @lukas just published a phase 0 proposal „SafeDAO constitution“.

While the constitution is of course quite high-level and this proposal at hand quite specific, they do relate to another. May be worth reviewing the constitution proposal before making up your mind about the upcoming vote on this SEP-2.

2 Likes

The constitution should be discussed when those who agree with it can buy a token and not consonants can sell it.

Now, we can say that all token holders are held hostage by the bureaucracy and, if we talk about real things, cannot do anything. At all.

There is a possibility that someday unlocking will occur, but maybe not. Maybe there will continue to be new reasons not to put this issue to the vote in a snapshot.

The Constitution is beautiful. Thank you for the great work. But in order to work collectively on it, I think it is necessary to first solve the issue of basic freedom of action of participants.

I apologise for my English.

2 Likes

If your question is whether SEP-2 and the constitution proposal are separate proposals, then yes, absolutely!

They are being discussed independently and neither of them are currently approved by a DAO vote. SEP-2 seems to be much closer to that (currently in late phase 1) while the constitution proposal has just been put up for discussion (phase 0) and is not even an official SEP yet.

With my previous comment, I just wanted to raise awareness here for the constitution proposal and encourage everyone to review whether they think that SEP-2 would be in line with the constitution (in its current form). I personally think so but everyone should make up their mind themselves.

Strictly speaking, the constitution would arguably only apply to proposals and other activities happening from the time of when it passes a Snapshot vote, not retrospectively. Although practically speaking, we’d probably want to make sure that any SEP that passes before the constitution does is already aligned to avoid contradictions in the future.

2 Likes

Hello ! DAY X IS DONE . Today we may upload to snapshot SEP #2 , Who upload this ? I may upload or maybe Daniel or maybe other , pls reply , i need know this .

Can we Just have someone post a proposal with the safesnap plugin vote this in and run a quick vote seeing as though this was already approved?

What was the point of the snapshot if it wasn’t in there in the first place?

I don’t get it it already passed so can we just put it live? I doubt the team doesn’t have the ability to do that no one would entirely trust that feature to the community alone. So can someone from the team either just flip the switch seeing as though it passed. In lieu just run another vote rn with the safesnap plugin enabled. And turn it live rn. Am I wrong thats literally what the “DAO” just voted on. And it passed so… Either respect the governance or rerun the vote with the features enabled.

Anyone with enough tokens can do it. I have a few safes so… i think im just a bit below threshold on individual tokens in each safe or i would do it.