What is an XIP?
XIP 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 XIP 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 XIP 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 XIP document should be directed to the XIP editors.
XIP Rationale
We intend XIPs 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 XIP contain a single key proposal or new idea. The more focused the XIP, the more successful it is likely to be.
An XIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement.
XIP WorkFlow*
Parties involved in the process are the author, the XIP 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 XIP is the NFTX Discord server or the NFTX Discourse forum.
Your role as the author is to write the XIP 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 XIP:
What belongs in a successful XIP?
Each XIP 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 XIP.
- Rationale - The rationale is critical for XIPs that want to change NFTX. It should clearly explain why the existing specification is inadequate to address the problem that the XIP will solve. XIP 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
XIP Editor Responsibilities
For each new XIP that comes in, an editor does the following:
- Read the XIP 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 XIP for language (spelling, grammar, sentence structure, etc.),
If the XIP isn’t ready, the editor will send it back to the author for revision, with specific instructions.
Once the XIP is ready, the XIP editor will:
- Send a message back to the XIP author with the next step.
The XIP editors monitor XIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
The editors don’t pass judgment on XIPs. 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 XIP. 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 XIP to Pass. For changes to the NFTX contract, more than 70% must vote in agreement for the XIP 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 XIP must be put to a snapshot vote for the community to accept or reject. The XIP 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 XIP has achieved discourse quorum requirements.
- The XIP 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 XIP 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 XIP to Pass. For changes to the NFTX contract, more than 70% of voting tokens must vote in agreement for the XIP to pass.
Post Voting Process
If a proposal is rejected the XIP 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 XIP 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.