[SEP #3] Towards clarity on milestones before voting on enabling transferability again

Proposals Phase 2: Voting
1
  • Title: Towards clarity on milestones before voting on enabling transferability again
  • Authors: @theobtl
  • Created: 2022-12-05

Abstract

This proposal serves as a signal on milestones to be met before the question of enabling transferability of SAFE is put up for a vote again. Using single choice voting, the winning option will be considered the minimum set of milestones to be met. Due to time constraints, this proposal should be discussed conclusively by mid December.

Proposal details

Purpose and Background

After SEP-2 was voted down, various arguments have been brought up on when to vote on enabling transferability of SafeDAO’s governance token, SAFE, again.

The purpose of this SEP is to condense these arguments into distinct options in the form of milestones and give the community clarity on when a second vote on enabling transferability is supposed to take place. By providing such clarity in terms of a timeline of milestones, this proposal also serves the purpose of focusing the DAO’s attention on enabling transferability at a given time, and on other workstreams in the meantime.

List of Milestones

The initial and current summary of milestones is as follows:

  • Milestone A: The claim period has passed
  • Milestone B: An SEP on a constitution has been ratified
  • Milestone C: An SEP on a governance framework has been ratified
  • Milestone D: An SEP on a resource allocation framework has been ratified
  • Milestone E: An SEP on token utility has been ratified

Not included above but assumed to be in place:

  • Activities around liquidity provision and market making have been aligned on
  • A future proposal on enabling transferability include a complete documentation of its SafeSnap specification in the proposal text

Context on the list of milestones and why they are included

This list of milestones includes several workstreams that are not yet formally being discussed on the forum in the form of proposal, but are considered upcoming milestones based on comments in the forum and elsewhere.

  • Milestone A “The claim period has passed” refers to the ongoing period to claim the Safe token ($SAFE) which ends on December 27, 2022, 12PM CET.
  • Milestone B “An SEP on a constitution proposal has been ratified” refers to this proposal which, as of writing, is in phase 0.
  • Milestone C “An SEP on a governance framework has been ratified” refers to a proposal revising the SafeDAO Governance Process document suggesting a strategic, high-level approach to SafeDAO’s governance principles, processes and choice of tooling. ´
  • Milestone D “An SEP on a resource allocation framework has been ratified” refers to this proposal which, as of writing, is in phase 0.
  • Milestone E “An SEP on token utility has been ratified” refers to remarks by several community members to align on the utility of the Safe token.

A governance roadmap for SafeDAO outlining these and other governance-related milestones will be discussed independently from this proposal in detail with the appropriate level of attention which this proposal intends to free up and channel to each milestone in due course.

Summary of the Snapshot proposal

The initial and current summary of options (i.e., combinations of milestones) is as follows:

  1. Option 1: Milestones A and B
  2. Option 2: Milestones A, B, C and D
  3. Option 3: Milestones A, B, C, D and E

The Snapshot proposal should be set up as follows:

  • Voting options:
    – 1. Option 1
    – 2. Option 2
    – 3. Option 3
    – 4. Make no changes
    – 5. Abstain
  • Type of voting system: Single choice voting
  • The default settings and norms apply
  • No use of SafeSnap

Note on the timeline of this proposal

To serve its purpose, this proposal should be ratified before any single milestone itself. Especially milestones A and B could be reached relatively soon. Milestone A (‘Claim period’) passes after Dec 27, 2022, while milestone B (‘Constitution proposal’) could be ratified as early as 14 days after it becomes an SEP, and eight days before it is uploaded to Snapshot. Consequently, this proposal should be uploaded to Snapshot by whichever of the following two dates is sooner:

  • Dec 18, 2022 (milestone A)
  • Eight days before the constitution proposal is uploaded to Snapshot (milestone B)

As a reminder, this proposal must also remain unchanged as an SEP for six days before it can be uploaded to Snapshot. Due to these time constraints, I encourage the community to review and suggest potential changes to this proposal within the first few days of its publication, so that the community can align on a proposal draft by no later than Dec 11, 2022.

By including the (default) options of ‘make no changes’ and ‘abstain’, every voter should in principle be able to vote in accordance with their preferences, no matter the list of voting options.

Effects and Impact Analysis

While this proposal itself does not comprise a vote on enabling transferability nor any on-chain executable components through SafeSnap, this proposal is supposed to have a signaling function. Specifying a SafeSnap specification including an oracle that would effectively represent the various options included in this proposal is complex, if not impossible.

Instead, it seems much more straightforward to follow a two-step process: The first being this proposal resulting in a signal, and in response to that signal a second, future proposal which includes a SafeSnap specification to enable transferability in a trustless manner.

Merely having a signaling function makes this proposal less binding, as it would be straightforward to ignore this proposal and put the question of enabling transferability up for a vote anytime before this proposal would signal it should be. However, this proposal does not introduce any additional risk as any future proposal would still need to undergo the usual governance process and be subject to the security of a Snapshot vote.

Alternative Solutions

Use multiple-choice voting on individual milestones

Instead of limiting options to a few combinations of milestones, the Snapshot vote could make use of multiple choice voting (approval voting system) to allow for greater individuality in the bundling of milestones. However, SafeDAO’s initial governance process only allows the use of single-choice voting. Introducing other voting systems requires an SEP in itself and is not feasible within the timeframe of this proposal. A future governance framework proposal should revisit the question of allowing approval voting and/or other voting systems supported by Snapshot.

Have this proposal be a vote directly on enabling transferability

Instead of voting on a variety of milestones to be met, this proposal could also simply pose the question once again whether transferability should be enabled and include a SafeSnap specification to do so immediately in a trustless manner. This option was discarded because the discussion around SEP-2 revealed a variety of reasons why one would vote for, against or abstain from voting. While yet another simple vote on whether to enable transferability or not would result in a simple yes/no result, this proposal at hand provides more granular and contextual information. By having more clarity on which milestones are supposed to be met before voting on enabling transferability again, any future vote on enabling transferability will be more likely to occur at an appropriate time when it is likely to get traction among the community and can be expected to pass.

Not to have this proposal at all

If we do not consider and vote on this proposal, the community will have less clarity on when the question of enabling transferability should be put up for a vote again. Future votes on enabling transferability could be instantiated any time and after each discussed milestones, without any idea on the likelihood of that proposal to pass. While the various milestones have already been discussed in the forum, on Twitter and elsewhere, there has never been a meaningful and representative analysis on the preferences of token holders. By having this proposal at hand voted on by SAFE holders and consequently have an on-chain representation of preferences on when to vote on enabling transferability again, the community won’t be left in the dark about a roadmap towards enabling transferability and can focus its attention and resources more productively in the meantime.

Technical Implementation

This proposal will not include any on-chain executable components through SafeSnap.

Open Questions

Due to the single choice voting system, the poll provides a limited number of combinations of milestones. Do the options of milestones and combinations thereof reflect the most relevant ones?

Copyright

Copyright and related rights waived via CC0.

27 Likes
2

Note: I see this SEP having much more of a moderating function based on previous comments, as well as having a signalling function compared to other SEPs so far and in the future. To make sure this proposal is being moderated and updated appropriately within our short timeframe (finalisation by Dec 11), I welcome moderator support from our Guardians and other experienced community members to make sure my roles as moderator and proposal author are not conflicting.

6 Likes
3

Clarifying question before engaging further:

does this proposal assume milestones must be done sequentially? For example, if a vote is cast for Milestone C, does that indicate that Milestone A and Milestone B must also be accomplished?

1 Like
4

Your question does in fact not really apply since the proposal is not to vote on these milestones individually, but on only the options of combined milestones:

To be clear, the Snapshot vote would only include these five options as listed above. These options include combinations of milestones. The order in which these milestones would be achieved would not matter.

I intentionally listed the individual milestones first individually to make it easier to comprehend the process of coming up with combinations. However, if that is actually confusing and we’re better off keeping it simple with describing the options (combined milestones) only, please comment or like this post and I’ll rephrase the proposal accordingly.

2 Likes
5

I like this structure!

While I’m in favor of Option 3, my impression of the community sentiment is that changing Option 1 to require only Milestone A might make it representative of a more widely held opinion on what should happen before the unpause. It seems a lot of people would support that minimal requirement because they don’t want a delay in ratifying the constitution to extend the unpause timeline.

7 Likes
6

Understood. Thanks for the clarification. In hindsight, I misunderstood those options to be possible examples, rather than the concrete voting options.

I agree that an SEP outlining when to revisit enabling transferability is important, and these options serve as a good starting point.

Because governance is still limited to single choice voting, I agree that it’s impractical to pass an SEP to enable multiple-choice voting before voting on this SEP.

I anticipate that there will be some confusion as to how the winning option is determined. It would be helpful to include an example of how the winning option will be determined using the lowest common denominator of milestones met.

4 Likes
7

The winning option will simply be the option that receives the most votes. In the unlikely event that two options will receive the same number of votes, we would probably have to vote again on just those two options.

The phrase ‘lowest common denominator’ is probably misleading and originates from an earlier draft when this proposal was using multiple choice voting. That seems like another phrase to clarify. What is meant is just that the winning option and the milestones included must be in place as a minimum level of progress, but there is no maximum level of progress defined. I.e., in a future SEP about enabling transferability, the proposal author and the community could align on additional milestones or other factors that are not explicitly defined in the winning option of this SEP.

1 Like
8

I think this is well written and agree with moving forward with the vote

5 Likes
9

Let me start by saying that I agree with the milestones to enable token transferability, and that I appreciate that the desires of the Safe team have been so clearly articulated.

That being said, I am confused. The previous vote to enable token transferability was not defeated because the majority of the community didn’t want to enable, it was defeated because two whale wallets voted against the SEP. So you can make as many milestones as you wish, but unless you understand why those two wallets voted against it, any subsequent vote will fail.

I’m going to make an assumption: these two wallets are known to the Safe team, and likely are members/investors. If so, the milestones you have laid out here are what the Safe team wants to accomplish before token transferability.

So why are we voting on this? Why doesn’t the Safe team just state that this is what their vision is, gather feedback, and keep moving? If the assumption that the two whale wallets are controlled by the Safe team is true, the there isn’t any need to vote, and in fact going through the song and dance of a vote just smells like DAO theatre.

The Safe team has built an amazing product, and garnered a lot of interest from potential contributors. I think the team (including investors) have a right to progressively decentralize as they ensure that the vision of Safe is well-understood and adopted by the community. I agree with waiting to enable token transferability. But if my assumption about the whale wallets is correct, I wish the Safe team would just be transparent about the situation.

Transparency is a virtue of blockchain, and it is a virtue of DAOs. If the Safe team TRULY wants to decentralize, then they too must be transparent.

8 Likes
11

The winning option will simply be the option that receives the most votes.

This voting structure may need to be reconsidered because it would not necessarily reflect the desired outcome of the voters.

If the voting options remain the following:

  1. Option 1: Milestones A and B
  2. Option 2: Milestones A, B, C and D
  3. Option 3: Milestones A, B, C, D and E
  4. Option 4: Make no changes
  5. Option 4: Abstain

Then a vote for Option 3 should also count towards Option 1 and Option 2, because the voter’s intent includes that the Milestones in Option 1 and Option 2 are met.

You can see how this changes the outcome if you run through voting scenarios using concrete values.

For example, if you assume 100 wallets vote and that the votes look like this:

  1. Option 1: 25
  2. Option 2: 15
  3. Option 3: 10
  4. Option 4: 30
  5. Option 5: 20

Then the intent of the voters is really this:

  • Milestone A: 50 votes (from votes for Options 1, 2, and 3)
  • Milestone B: 50 votes (from votes for Options 1, 2, and 3)
  • Milestone C: 25 votes (from votes for Options 2 and 3)
  • Milestone D: 25 votes (from votes for Options 2 and 3)
  • Milestone E: 10 votes (from votes for Option 3)
  • No milestones: 30 votes (from votes for Options 4)

In other words, the intent of the voters is for Milestones A and B to win, but the current single-choice voting options will result in no milestones having to be met.

3 Likes
12

Thank you for writing in such detail. I agree that this should be done.

13

Thank you for putting the proposal together. Creating more clarity for the community is definitely important and I like the steps outlined. One issue I see in this proposal as well as I saw in SEP#2 proposal (although I missed the participation window) is that it is economically unfriendly to allow transferability in a current economic environment.

Currently, the token acts as a private equity investment and allowing transferability would create the true effect of an IPO. It is no surprise that the IPO market in tradfi has been frozen for the better part of the year - it is economically disadvantageous to freely trade in a depressed market sentiment. The only rationale imo in allowing transferability right now is to fire sale tokens, all other holders will either wait for better time to exit (when risk asset sentiment has improved if it’s a speculative investment for them) or will not participate in selling at all (if they are invested in governance participation and long-term vision for SAFE). Nonetheless, nobody likes their investments decrease in value (which will be caused by marking to market depressed by fire sales) which may result in even higher sale pressure from investors that will panic sell. How ever you look at it, the price of the token will affect the economic perspective of the protocol and therefore the timing needs to be carefully considered.

As such, I would think that any proposal dealing with transferability should include a milestone that incorporates the view of the economic environment. The question then becomes what a good indicator is. Happy to brainstorm on ideas on how to check the health of the crypto ecosystem.

2 Likes
14

That was exactly my thought too. In order for the vote to be fair, the options should reflect all opinions across the spectrum as accurately as possible. That could mean changing option 1 as you say.

However, the poll also includes the options ‘make no changes’ and ‘abstain’. ‘Make no changes’ would effectively mean to accept none of the milestones, while the envisioned timeline for this proposal is be ratified shortly before milestone A. My take was that ‘Make no changes’ is effectively the same as milestone A, just due to the fact that this proposal cannot be ratified more than a day or two earlier than milestone A.

Assuming that ‘make no changes’ broadly means ‘milestone A’, it seemed reasonable to not include another option for ‘milestone A’ for fairness. That is, because the more options represent a similar part of the opinion spectrum, the less likely it is for that opinion to be the winning option. Practically speaking, if the “minimal requirement” group spreads their votes across ‘make no changes’, ‘A+B’ and an additional option for ‘A’, their votes would be split into three groups. In that case, the other end of the spectrum that prefers maximum requirements would have an unfair advantage because their votes would likely be concentrated in just one option, option 3.

Since we’re unfortunately constrained to single choice (see here), we have to make a lot of compromises but keeping the options as is would hopefully be the fairest option to all opinions across the spectrum. Does that make sense?

1 Like
15

You’re raising an extremely important point, of course. What you’re also getting at is the distribution of voting power which is being discussed at length in this thread, and far from being conclusively discussed. In short, this issue to me is extremely important but on a different timeline/scope than SEP-3, simply because the token distribution and definition of voting power has been defined in the past and any changes to that practically couldn’t be ratified before this proposal is envisioned to be ratified. Meaning, we can talk but not change the distribution of voting power during the scope and timeline of SEP-3.

That said, we can talk about it and we should. By the end of next week, I intend to share a list of wallets, their voting power and which stakeholder group they belong to. Most of that information is on-chain data and can be retrieved by anyone, e.g. on GitHub and on this forum. The upcoming blog post will present them in a more approachable way and enrich the list of accounts and their voting power with a categorisation whether they are investor wallets, Guardian wallets or other wallest. Based on that initial information, it will be easier to analyse voter participation in previous and future SEPs and have a more informed discussion on a comprehensive governance framework for SafeDAO.

That said, about the two whales you mentioned:

They are investors indeed and they surely did have a major impact, but they did not decide the vote. Without these two wallest, the result would not have changed and “Make no changes/Decide later” with theoretically 11M votes would still have surpassed “Enable transferability” with 8.3M votes.

This is simply to say that SEP-2 was not flipped by these two accounts but, of course, this does not mean that the criticism you and others in the thread linked above raised is irrelevant – quite the contrary.

Again, your assumption is correct that these wallets are investor wallets. Although I don’t follow the other part of your assumption that these investor wallets are controlled by the Safe team. They are investor wallest who are separate from the core team, have their own opinions and vote independently, of course. What makes you think that control would be in place?

Surely, there are aligned incentives, like there are aligned incentives among every single holder of SAFE. Surely, there are informal communications channels among individuals, including Safe team member ↔ Investor team member. The general principle which I’m pushing for as hard as I can is that every discussion that is vital to governance and the decision-making process in SafeDAO must take place in this publicly accessible governance forum.

If you are referring to this point by @raynemang, I can reassure you that this has nothing to do with any control the Safe team exercises. I have yet to inquire and write up the full story which will be part of a wider transparency initiative, but the short story is that investor wallets are set up as a Safe (yes, Safe is dogfooding :slight_smile: ) with the Safe Ecosystem Foundation as one signer next to the investors’ wallets. @raynemang refers to Stefan George being involved, when in fact he is just involved as a formality through the Safe Ecosystem Foundation. Further details are yet to be inquired and written up when we go more into the legal setup of SafeDAO and the Safe Ecosystem Foundation.

I couldn’t agree more. We’ve seen way too many DAOs recently that don’t deserve to be called one and crypto Twitter is slowly waking up to realise that too. I’m convinced that SafeDAO absolutely is on a journey to becoming a DAO and still at the beginning of progressively decentralising. You’re right that this process can only be effective with an appropriate level of transparency. The post on accounts per stakeholder group mentioned above must just be the start here.

7 Likes
16

Thanks for flagging that. I certainly agree that the use of single choice-voting is suboptimal.

Ideally, we would use multiple choice-voting but, regretfully, that is not possible at this time due to a shortcoming in our current governance framework.

This leaves us with making the best out of single choice-voting.

To your point, I can absolutely see that scenario where a certain voter would like their vote to be counted towards less exhaustive options, too. Although I wonder whether that is strictly true across all scenarios. There could be a voter who feels strong about milestone E and votes for option 3 purely because milestone E is included, but if option 3 would not pass, they would rather vote for ‘make no changes’ or ‘abstain’ instead of option 2. That just seems like an assumption that is hard to generalise and, again, falls back to the constraints of single-choice voting which we’re bount to, when ranked choice-voting could be applicable here.

As dissatisfying as it may seem, due to these constraints in the current governance framework, the current draft appears like the best possible option in this suboptimal solution space we’re constrained to. At the end of the day, this proposal will merely serve as a signal and not take any on-chain action in itself. By the time future SEPs like the actual vote on enabling transferability will be voted on, we will have had a chance to improve our governance framework in the meantime – which is why milestone C is such a crucial one IMO to make sure that the proposals ratified by SafeDAO are maximally legitimate and accepted.

1 Like
17

That’s a fair point which others have brought up too.

That’s precisely what kept me to include this milestone in the initial proposal. The most interesting indicator to me was the Bitcoin Rainbow Chart V2 - Blockchaincenter since it dates back until 2014, but that argument alone wasn’t good enough to include it. That indicator had to be corrected in the past and obviously is no indicator of future developments. All in all, it didn’t seem useful to me to specify any kind of indicator on the economic environment that is specific enough to be meaningful. My thought was really to not even try to define it here but assume the proposal author and community at the time of a future vote on enabling transferability to implicitly or explicitly take the market environment into account. Including a milestone on that could actually do harm if we choose a poorly defined indicator and artificially constrain our options in the future, unless you have an indicator in mind that the community can align on?

1 Like
18

In order for us to align on a final draft of this proposal by Sunday, I wonder whether you agree with my take that the previous discussions do not require the proposal to change.

That is except @ittaisvidler’s earlier point to clarify the phrasing ‘least common denominator’ which I’ve changed to ‘minimum set of milestones’:

Screenshot 2022-12-10 at 02.18.58
Screenshot 2022-12-10 at 02.18.582198×340 71.1 KB

19

My point wasn’t that I have an issue with token distribution - I don’t. As stated before, the Safe team and investors have contributed to the project up to now and I think they SHOULD have the primary say in how the token rolls out.

My point was that most token holders are privy to the same information as Safe team members yet, and that transparency would help bridge that gap. The blog post you mention would be a welcome info drop.

What’s the rush with this proposal?

Is this why the Safe team has resisted opening up a Discord channel for governance despite the community making it clear that we want one?

As you have identified, the largest current information asymmetry is between the community and the Safe team/investors. It feels like the Safe team and investors have a vision towards enabling token transferability. My criticism isn’t against that vision (outlined in this post) or the fact that the team/investors are setting this vision with their token weight (I’m glad for it, in fact).

My criticism is that this is being framed as a community vote when the options and outcome are all being set by the team/investors. I’d rather the team and investors set the vision, communicate it, and save community votes for things upon which the community can actually have an impact.

Again - what’s the rush?

1 Like
20

I see,

Fully agree. That’s coming, it’s just a huge chunk of data that needs quite some work to keep it accurate (query token balances, calculate voting power for all snapshot voting strategies, include delegated voting power, etc.)

I don’t think that’s an accurate accusation. The team doesn’t resist, I’ve brought it up to colleagues managing the Discord and I’ve asked us to specify the purpose. The community has made it clear to have one but not the purpose. I’m totally up for it but hesitate to demand even more time from DAO participants‘ time and attention if the purpose of a Discord channel goes beyond optional, non-governance, decision-making related discussions.

1 Like
21

Simply to be meaningful. Two milestones are imminent.

That was part the proposal since the beginning and there weren’t any requests to change that until now. Do you disagree?

If any further changes to the proposal are required and we can align on them within the next few days, I think that’d be desirable.

So far, most issues seemed (super important! but) out of scope, such as using weighted voting which requires a separate governance SEP, more transparency on distribution of voting power which is part of a post in the making, and discussion around other voting mechanism’s such as QV which are also part of a governance SEP.

Based on your concerns, how specifically would you change the proposal?

Otherwise, I’m not aware of specific changes needed and would consider the proposal final from my POV that could go to snapshot six days after the last change which was yesterday.