XIP#1 - Governance process and Proposal Format

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

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.