• 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.