XIP#1 - Governance process and Proposal Format

Proposals
1

Author

  • Finesseboi

Glossary

  • DAO
  • Quorum

Summary

  • Implement standard operating procedures for governance.

Rationale

  • Goals of a Good Governance Process:
  • Make good decisions.
  • Governance process should be transparent and clear.
  • Encourage contribution and involvement.
  • Make sure opposing views can be heard and considered.
  • Make sure a proposal is technically feasible.
  • Keep the governance process moving and free of gridlock.

Effect

  • Opportunity
    • Proposals will be standardized and decision making can be more effective.
    • Increased Transparency and increased accessibility to “informed” Governance.
  • Risk
    • Opinions that are worth less than their voting weight can have a bigger influence.

Specifications

  • Implement format below as standard/required proposal format

  • Authors

  • Glossary

  • Summary

  • Rationale

  • Effect

    • Opportunity
    • Risk

  • Specifications

    • Explanation of process behind implementing proposed objective

  • Funding request - (y/n)

  • Communication

  • Proposed points of discussion.

  • Notes on required Quantity and time for Quorum

    • Where to discuss and requirements before the official proposal
    • Where and how to vote

  • Implement a standard Governance Process/Flow - Flow In the post below

  • What requires proposals/what doesn’t

  • Discord

    • Gauging for Opinion/Ideas.

  • Discourse

    • Write a concise title and understandable (aka non-tech/Eli-5) summary.
    • Formulate clear for and against positions for binary proposals, or a scale of options with an “Against” option for numerically based proposal. Try to get proposals down to the minimum amount of options
    • Include a poll to measure sentiment (public, results on vote).
    • Don’t rush submitting a snapshot proposal, keep the discussion going for at least 3 days.
    • Stick to proposal format.
    • Discussing proposed points.
    • Refining.
    • Final Draft (if first is a draft).
      • Proposal + Poll (Quorum required).

  • Snapshot

    • Pre-requisites: It is expected that the proposal has been discussed on Discord and the forums for approximately 3 days and “the community signals its interest.” Enforcement of this rule falls to social consensus.
    • Copy and paste from final discourse proposal with discussion points removed.

  • Aragon

    • What requires proposals/what doesn’t.
    • Quorum required?
    • Notes.

  • If a proposal does not follow these steps, it is invalid.

  • If a proposal does not get more than X votes in total, it is invalid.

  • All rules can be modified by a valid proposal, but “fully discussed with the community” should be the principle.

Funding request - No - Implementation does not require funding

  • No funds required.

Proposed Points of Discussion

  • I’ve changed the minimum quorum from 20% circulating to 10% based on ChopChop’s hiring proposal barely reaching the 20% (Even though 100% of votes are in agreement).

Communication

Quorum and Governance Notes

  • Minimum Quorum: More than 10% of circulating, non-treasury NFTX must participate for a proposal to Pass.
  • Passing Threshold: More than 50% of voting tokens must vote FOR for the XIP to Pass. For changes to the NFTX contract, more than 70% of voting tokens must vote FOR for the XIP to pass.
    • Yes: Implement governance process and proposal format
    • No: Disregard governance process and proposal format

0 voters

1 Like
2

What is an NIP?

NIP stands for NFTX Improvement Proposal, it has been adapted from the SIP (Synthetix Improvement Proposal), YIP (Yearn Improvement Proposal) and IIP (Index Improvement Proposal). The purpose of this process is to ensure changes to NFTX are transparent and precise. An NIP is a design document providing information to the NFTX community about a proposed change to the system. The author is responsible for building consensus within the community and documenting dissenting opinions.

History

The NIP document was derived heavily from the SIP Synthetix Improvement Proposal, the YIP Yearn Improvement Proposal and the IIP Index Improvement Proposal. The document in many places was simply copied and modified. Any comments about the NIP document should be directed to the NIP editors.

NIP Rationale

We intend NIPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and for documenting the design decisions for changes to NFTX.

It is highly recommended that a single NIP contain a single key proposal or new idea. The more focused the NIP, the more successful it is likely to be.

An NIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement.

NIP WorkFlow*

Parties involved in the process are the author, the NIP editors, and the NFTX community.

Before you begin, vet your idea, this will save everyone time. Ask community members first if an idea is original to avoid wasting time on something that will be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will have the intended effect. The appropriate public forum to gauge interest around your NIP is the NFTX Discord server or the NFTX Discourse forum.

Your role as the author is to write the NIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. The following is the process for an NIP:

What belongs in a successful NIP?

Each NIP should have the following parts:

  • Authors
  • Simple Summary - “If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the NIP.
  • Rationale - The rationale is critical for NIPs that want to change NFTX. It should clearly explain why the existing specification is inadequate to address the problem that the NIP will solve. NIP submissions without sufficient motivation may not find much support. The rationale may also provide evidence of consensus within the community.
  • Specification - The technical specification should describe the syntax and semantics of any new feature, what motivated the design and why particular design decisions were made. It should also describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.,
  • Funding Request - Does the proposal require funds, if so, in what quantity?
  • Points of discussion - discuss important objections or concerns raised during previous discussion.
  • Notes on Quorum

NIP Editor Responsibilities

For each new NIP that comes in, an editor does the following:

  • Read the NIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don’t seem likely to get to final status.
  • The title should accurately describe the content.
  • Check the NIP for language (spelling, grammar, sentence structure, etc.),

If the NIP isn’t ready, the editor will send it back to the author for revision, with specific instructions.

Once the NIP is ready, the NIP editor will:

  • Send a message back to the NIP author with the next step.

The NIP editors monitor NIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.

The editors don’t pass judgment on NIPs. They merely do the administrative & editorial part.

*Workflow

1600Ă—533 57.5 KB

Discord & Forum

The initial fielding research and discussions should be on Discord, Discourse, or any other venue. This is an informal process to gauge community interest and ideas in a potential NFTX improvement proposal.

Here are some questions the contributor might want to answer:

  • Am I able to informally get any traction for this proposal in the Discord?
  • How does this proposal get the community closer to achieving its stated goals?
  • What trade-offs are implicit in this improvement’s adoption?

Forum

The proposal category of the forum is used as a formal area to debate the merits of each NIP. All NFTX changes must go through snapshot voting.

  • Minimum Quorum: At least 5 votes
  • Passing Threshold: More than 50% of must vote in agreement for the NIP to Pass. For changes to the NFTX contract, more than 70% must vote in agreement for the NIP to pass.

Governance Calls

Governance calls may also be used to debate proposals and to gauge community sentiment on them. The governance calls DO NOT represent a formal venue to measure consensus.

Calling a Vote

An NIP must be put to a snapshot vote for the community to accept or reject. The NIP author is responsible for deciding a snapshot vote date with the following criteria in mind:

  • The snapshot voting period may not begin until at least 3 days after the NIP has achieved discourse quorum requirements.
  • The NIP has a voting period of 3 days where token holders may vote FOR or AGAINST.

Snapshot Voting

When a snapshot voting date has been decided, an NIP editor will create a snapshot vote page with the following criteria:

  • Minimum Quorum: More than 10% of circulating, non-treasury NFTX must participate for a proposal to Pass.
  • Passing Threshold: More than 50% of voting tokens must vote in agreement for the NIP to Pass. For changes to the NFTX contract, more than 70% of voting tokens must vote in agreement for the NIP to pass.

Post Voting Process

If a proposal is rejected the NIP may be moved to rejected or back to being a work in progress to be revised for future consideration.

If a proposal is passed the NIP author/editor/team/contributors may work towards the implementation of the proposal on a case-by-case basis.

Copyright

Copyright and related rights waived via CC0.

3

Instead of having this as a vague guideline, I propose requiring a FCP (Final Comment Period) - a 5 day period in which no more changes are made to the proposal (hence, past its feedback stage) and stakeholders/members can weigh in on its final iteration (and of course object if something seems way out of line).
Or maybe FCP should only be required for critical decisions, where attention to details is important.

2 Likes
4

Yeah the way I worded mind sound a bit vague but in essence this is what I’m proposing.

Publish a draft proposal to discourse that is open to feedback and changes → Publish a final proposal that receives no changes and have people vote with a poll → Copy/Paste the final proposal to snapshot as that was what people voted on.

The final proposal published to the forum will have 3 days at least before being published to snapshot. This would be the time where stakeholders/members would weigh in after having provided feedback in the draft proposal.

2 Likes
5

I think this makes sense. It seems standard and mirrors the protocol used by other DAOs.

1 Like
6

NIP #2: Refer to NIPs as XIPs :stuck_out_tongue:

3 Likes
7

I’ve changed NIP to XIP and will be pushing to snapshot to formalize this!

1 Like