LIVE - Snapshot migration

Abstract/Executive Summary:

Herein I propose migrating all votes that do not require on-chain voting to modify SC parameters to Snapshot.


High gas fees present an onerous burden on small holders of YFL who wish to participate in governance. This proposal seeks to resolve this issue by migrating voting on proposals that do not require SC-execution to Snapshot’s off-chain voting system, with a few small rule modifications to prevent abuse of Snapshot’s greater amount of control around voting parameters.

Voters should appreciate the following new aspects of voting:

  • Proposals can now have more than two options
  • Individuals cannot stake yYFL to gain voting power for a particular vote after the snapshot block. This means that individuals wishing to vote on a proposal need to have staked before vote start.


  • Unless otherwise stated, all previous rules regarding proposal drafting, submission, and voting shall apply to proposals submitted for voting on Snapshot. Proposals not following these rules, or the following rules shall be rendered void.

  • All proposals that do not require execution of a smart-contract function shall be submitted for voting via the YFL Snapshot (Snapshot)

  • Cooldown Period

    • A proposal that fails to pass on Snapshot cannot be resubmitted on Snapshot for a vote within 72h of failure.
  • Duration of Voting

    • Proposals without the expedited designations outlined in Prop12 shall be required to set an End-Time that is exactly 72h from Start-Time.
      • Proposals with expedited designations are required to set Start and End-times congruent with the rules outlined in Prop12.
    • Snapshot Block Number shall be set to a block that is estimated to be at least 3, but no more than 9 hours before vote start .
  • Formatting

    • Proposal titles shall be of the format “Proposal [NUMBER] – [Proposal name as it appears on forum].”
      • If using expedited designations, include the designation in the title as well.
    • The body of the proposal shall, at a minimum, include a link to the forum post containing the text of the proposal.
  • Voting Options

    • As users are now permitted to select the description of voting options, the following rules apply:
      • Options must be written in English.
      • The wording of options must make it clear what the outcome of selecting that particular option means with respect to the proposal (e.g. You cannot attempt to obfuscate which option would approve the proposal and which would deny it)
        • Proposals are permitted to use single words, letters, or numbers to reference more detailed voting options within the proposal itself (E.g. Option A, Option 2), so long as the other rules contained within the Voting Options section are followed and those options are reproduced in the body of the text on Snapshot.
      • Exactly one voting option must be to “Reject the Proposal”
    • Proposals are now permitted to include more than two options to voters
      • For an option to Win, it must receive >=50% of the total vote.
        • If two options receive exactly 50% of the vote the option to reject the proposal in its entirety wins by default.
        • If no option receives >= 50% of the total vote, the option to reject the proposal in its entirety wins by default.

Voting Options

For: Approve the above rules

Against: Maintain current voting rules and mechanism


LFG :fire: :classical_building: