[SEP # ] Make The Safe Token Transferable

[b1k00]

• Title: Make The Safe Token Transferable
• Authors: b1k00
  inspired by Daniel (danftz.eth, Co-founder@Decenra), 0x4Graham, netrunner.eth, Melodic_Platypus, pdiomede, nodeE, CaptianTee, qianwan_lv, lukas, papa_raw, BraveNewDeFi, Nully, kdowlin, Bruce, ross
• Created: 2022-10-21

Abstract

The Safe Token is initially not transferrable.
Only the SafeDAO can enable transferability by the means of a successful governance proposal that unpauses the Safe token contract.
The Safe Token might be available on secondary markets if its transferability is enabled by SafeDAO.
This proposal aims to initiate a community vote(snapshot vote) on whether and when to enable token transferability.

Proposal details

Community members will vote on whether and when to enable token transferability based on their opinions after fully considering the details below.

Purpose and Background

This proposal was based on the community discussion initiated by Daniel. ([SEP #2] Community Initiative To Unpause Token Contract (Enabling Transferability))

It’s time to move this proposal to the next stage, because

• The relevant community discussions have been going on for almost a month, and most people’s opinions have been taken into account.
• Token claims have become slow and initial token holders have stabilized in line with the voting base.
• More than 500 people participated in the temperature check vote initiated by ross, and 99% of the votes were cast to unpause the Safe Token transfer function. (Snapshot)
  Enabling token transferability is in line with the opinions of most community members.
• SEP #1(Snapshot) is already in the snapshot voting stage, according to the current voting situation, it will be most likely passed on 2022-10-25, which means that everyone must agree to SafeDAO participation agreement before voting on this SEP.
  I will reconfirm the voting result of SEP #1 on October 25th and update this part of the content, this update will not cause the SEP to be delayed into the snapshot. (Unless SEP #1 does not pass, but I think it is almost impossible)

Effects and Impact Analysis

At present, based on the feedback from community members, the following views have been summarized.

About whether to enable token transferability or not:

Enable token transferability

• People will be able to freely manage and distribute their Safe Token, which is a fundamental function of a token. And enable token transferability will bring More Utility and Reduce Liability for Safe Token holders.
• Since the Safe Token are currently non-transferable, SafeDAO’s participation structure is fixed, without any new participants being able to come in, and enabling token transferability will improve this situation.
• Enables the SafeDAO treasury to use its native asset for ecosystem growth. There are already proposals under discussion about the use of SAFE tokens as an incentive for the SAFE ecosystem, and none of these proposals would be possible without enabling token transferability. ([Discussion] Safe DAO Resource Allocation Model (OBRA), Safe Grants Program (SGP))
• Imbues the Safe Token asset with value based on supply/demand dynamics.

Not enable token transferability

• In the current market situation, tokens should not be made transferable, which is not good for the token price.
• Transferable tokens may lead to some potential regulatory risks.
• The governance process is more resilient against malicious vote-buying at all participation rates. If a secondary market is created then malicious actors could accumulate tokens there.

About when to enable token transferability:

Enable immediately after the vote

• Without enabling transferability, almost all other proposals currently cannot proceed.
• Whether it enables transferability now or after the claim period, Those who want to sell their tokens for profit will always dump them without hesitation.
• Blindly delaying the unpause when there are no other proposals to engage/discuss will only kill people’s interest in participating in SafeDAO governance.

Enable after the claim period

• Need to wait for more people to claim their tokens before enabling transferability.
• Unlock too soon and users not interested in governance will dump.
• Should continue to wait until this proposal gets more feedback.

Alternative Solutions

This SEP takes into account the opinions of almost all community members and will set three options for voting

• Enable transferability immediately after the vote

• Enable transferability immediately after the claim period

• Make no changes

Explanation:
If “Make no changes” has more than 50% of the votes this will be accepted,
If these two options(“Enable transferability immediately after the vote” and“Enable transferability immediately after the claim period”
) combined get more than 50% of the votes, the option with more votes will be accepted.
There are different voting options for those with different opinions on enabling token transferability.

Technical Implementation

To make the token transferable no additional code is required, however, the owner of the token has to call the unpause method of the token contract. Once the token contract is unpaused (and therefore the token is transferable) it is not possible to pause the token contract again (e.g. once transferable forever transferable).

Source: safe-token/token.md at 6a1a4a99a7f3166b525cbd5469eaf0aea1c88e54 · safe-global/safe-token · GitHub

Open Questions

Although I think the current voting options have taken almost everyone’s opinion into account, there may still be other meaningful options, this SEP will be publicized for at least 6 days for community members to comment, if there are no major changes, this proposal will enter snapshot vote in 2022-10-27 at the earliest time.

The discussion of this proposal was initiated by Daniel, and most of the ideas came from this guy. At the same time, I saw many wonderful comments from community members, and finally, I sorted it out and summarized it, and got this proposal, this proposal is the work of many community members.(The authors includes all community members who commented more than 3 sentences in the Discussion and received at least three likes, recorded before the SEP was posted. ross initiated a temperature check vote on unpause Safe Token transfer or not, so ross is also included in the authors)

Copyright

Copyright and related rights waived via CC0.

[b1k00]

Why publish this SEP directly?

As mentioned in the rules of SEP([HOW TO] SafeDAO Governance Process), a proposal can go directly to the SEP stage without community discussion.
What’s more, this proposal is actually based on the community discussion initiated by Daniel, so the content of the proposal has adopted various opinions.

Why are there so many authors of this proposal?

In my opinion, all community members who participate in community discussions and leave deep feedback are in fact the authors of the proposal, which means that the community’s input is seriously considered and incorporated into the proposal. If anyone leaves other meaningful feedback before the proposal goes to snapshot, I’ll also list them as authors.

When will this proposal go to snapshot?

There will be a 6-day duration for community members to leave feedback, and if there are no major changes after 6 days, the proposal will go into the snapshot for voting.
My current definition of a major change is a change in voting options. Because this is the core of the proposal, and while I personally hope to enable transferability now, in fact the content of this proposal is to choose one of three options, not simply agree or disagree.

Please assign a SEP number to this proposal, which I think should be SEP #2. @theobtl

[Bruce]

Good idea , i think time to go !

[theobtl]

How is this proposal different from [SEP #2] Community Initiative To Unpause Token Contract (Enabling Transferability)?

@b1k00

In my opinion, all community members who participate in community discussions and leave deep feedback are in fact the authors of the proposal, which means that the community’s input is seriously considered and incorporated into the proposal. If anyone leaves other meaningful feedback before the proposal goes to snapshot, I’ll also list them as authors.

Isn’t this a bit of a stretch? Most of accounts you list as co-authors only commented, not co-authored a proposal. And they did not comment on your proposal, but on the original proposal by @Daniel. Did these people really co-author the proposal with you and are they aware that you list them as co-authors here?

From a process point of view, we should avoid creating several proposals on the same issue but rather discuss criticism and change requests in one thread. Would you mind taking the discussion here back into the original proposal and coordinate with the author how to proceed?

[b1k00]

Thanks for your reply, glad to see the team finally respond to this.

Unfortunately, your question is a bit too nitpicky in my opinion.

Daniel has not spoken on the forum for over a week, I contacted him via forum dm a few days ago and he has not responded.

I don’t know why he didn’t respond, but my posting this post is actually in line with the community’s wishes and doesn’t violate the rules for posting proposals, since proposals can have no phase 0.(just like SEP #1)

And the rules for authors in the proposal are
Authors: List all names of people contributing to this proposal (e.g. legal names, forum usernames, ENS names, email addresses).

You also mentioned, listing all who contributed.

I just want to give the respect they deserve to the community members who give deep feedback in the discussion and that this proposal summarizes their opinions, they are in fact the contributors to this proposal, if I don’t list their names, that’s disrespectful to them.

Well, if you think this is a serious question, I’ll remove everyone else’s names to be in line with the spec, but I’ll still make a special note in the proposal.

You can consider this proposal my own (for compliance, since I didn’t seek their input beforehand), but imo I’m not the only author of this proposal, their input plays a major role in the proposal effect.

[Bruce]

Haha, I also wrote to Daniel but he didn’t answer me, maybe he doesn’t like people. You can leave my name and I will place this proposal on my own, it seems to me that we are on the right track, DAO is almost accepted only 1 day left, people voted YES. Also, more than 599 people said yes to the temperature check, and I think that there is no point in delaying the resumption of the transfer of the token.

My opinion is this:

1. If there is a topic about the transfer of a token, then people want to talk about this topic
2. Then if people vote already in the temperature check FOR the renewal of the token contract, I consider this a sure sign that the discussion + temperature check needs a choice.

I suggest that after the 25th of October, after the adoption of the DAO, to create a vote. Let people decide which token they currently need.

[theobtl]

In that case, it seems more appropriate to go with the original proposal. Would you agree?

Daniel told me he’s unavailable currently but he did give his OK to move on. See also:

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

I’ve had a chance to briefly chat with @Daniel, the proposal author, who is currently unavailable. He agreed to move this proposal to the next phase and label it with an SEP number. Meaning, we have our second SEP now! According to our governance process, this proposal needs remain here unchanged and open for feedback for at least six days from now. From previous comments and the lack of change requests, the proposal seems quite mature. Let’s see if further changes will be pro…

I’ll close this thread if you don’t mind so that we continue the conversation around transferability in the SEP #2 thread.