What are XIPs?

Infinex Improvement Proposals (XIPs) are the primary mechanism for suggesting new features, collecting community input on an issue, documenting design decisions for changes to Infinex, and making adjustments to the Infinex system in a decentralized fashion. These proposals are an adaption from Ethereum Improvement Proposals (EIPs) and provide a structured way for the Infinex community to collaborate and contribute to the development and evolution of Infinex.

XIP Rationale

Once the first Infinex Council is established, XIPs are proposed as the primary mechanism for suggesting new features, collecting community input on an issue, documenting design decisions for changes to Infinex, and making adjustments to system parameters. By encompassing these aspects, XIPs help maintain clarity in Infinex's development roadmap, enabling stakeholders to collectively steer the course of the platform's growth.

XIP Work Flow

Parties involved in the process include the Author, the Operations Seat, the Infinex Council, and the Infinex Community.

• The Author is responsible for authoring and presenting XIPs.
• The Operations Seat is responsible for the formatting of XIPs, as well as scheduling of the presentation and council vote.
• The Infinex Council is responsible for voting on XIPs.
• The Infinex Community is responsible for giving feedback and engaging with XIPs.

Given the decentralized nature of the Infinex development process, anyone within the Infinex community is welcome to submit a XIP. However, to foster a collaborative environment, it is strongly encouraged that Authors engage in discussions within the Infinex Discord community before formally submitting their proposals. This preliminary discourse allows for the exchange of ideas, feedback, and refinement of concepts, ultimately leading to more robust and well-considered XIPs. The XIP workflow comprises three main stages:

1. Creation

Once submitted, every XIP will begin as a Draft. It must then meet specific formatting criteria (largely, correct metadata in the header which will be discussed later), and be manually approved by the Operations Seat to be published to the Proposals Website for further community discussion and consideration. The author of the XIP proposal is responsible for building consensus within the community and documenting dissenting opinions.

2. Voting

Once a XIP has been officially published on the Proposals Website, and marked as a Draft, for it to progress to the voting stage, the Author must:

• Consult with the existing Operations Seat. They will analyse the XIP, and notify the CWG and the Infinex Council, whilst ensuring that the XIP is technically feasible. XIPs that are currently in review will be placed in the In Review status.
• Once the review is concluded, and the Author is satisfied with the feedback gathered, the Author is required to present to the Infinex Council and community. If the Infinex Council is satisfied with the result of the presentation, they will inform the Operations Seat to put the XIP up for voting on snapshot, where the council will vote on it. Once the XIP is being voted on, it will be moved to the Vote In Progress status. The Infinex Council may also send the XIP back to the Draft or In Review stage if they believe more edits or research is required.

3. Approval

XIPs will be voted on by the Infinex Council. Each council member has five days to vote on a XIP, however, once enough councillors have voted on a XIP, its status may progress. Proposals will be only passed under a majority decision. Approved XIPs are moved to Approved, and then Implemented once executed by the Infinex Council, the CWG, or community members. Otherwise, it is Rejected. A XIP that has been previously Approved but replaced with a later XIP can be assigned the Supersededstatus.

XIP status terms

• Draft – The initial state of a new XIP before the Infinex Council and CWG have assessed it.
• In Review – a XIP that is being reviewed by a member of the CWG, or Infinex Council.
• Vote In Progress – a XIP currently being voted on by the council.
• Approved – a XIP that has successfully reached a majority Infinex Council vote in favour.
• Implemented – a XIP that has been released and implemented.
• Rejected – a XIP that has failed to reach a majority Infinex Council vote in favour.
• Superseded - an approved XIP that has been superseded by a later approved or implemented XIP.

What belongs in a successful XIP?

Each XIP should have the following parts:

• Preamble – RFC 822 style headers containing metadata about the XIP, including the XIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details.
• Proposal 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. Authors should aim for this summary to be one or two sentences.
• Specification – The Specification should describe the syntax and semantics of any new feature.
  • Overview- An overview of the changes proposed. This section should include all the details of the proposed changes, without the technical specification. Authors can think of this section similar to how litepapers are written.
  • Rationale – The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community and should discuss important objections or concerns raised during discussion.
  • Technical Specification- Authors should explain the technical details of their XIP in this section. This can include technical architecture, pseudocode, function descriptions, etc.
• Test Cases – Test cases may be added during the implementation phase but are required before implementation.
• Copyright Waiver – All XIPs must be in the public domain. See the bottom of this XIP for an example copyright waiver.

XIP Formats and Templates

XIPs should be written in markdoc (.mdoc) format. Image files should be included in a subdirectory of the assets folder for that XIP as follows: assets/xip-X (for xip X). When linking to an image in the XIP, use relative links such as ../assets/xips/xip-X/image.png.

XIP Header Preamble

Each XIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens (---). This header is also termed "front matter" by Jekyll. The headers must appear in the following order. Headers marked with "*" are optional, all other headers are required. Details about headers can be found below. title: <XIP title> id: <XIP number> (this is determined by the XIP editor) author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.> *type: <Core Upgrade | Integration Upgrade | Governance | Parameter Change | Community> network: <a list of the networks that this proposal is relevant to, e.g Ethereum Mainnet, Base, Solana> *type: <Core Upgrade | Integration Upgrade | Governance | Parameter Change | Community> *supersededby: <the proposals that supersede this XIP, if relevant> created: <date created on> *updated: <last updated date>

• Headers that permit lists must separate elements with commas.
• Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd).

author header

The author header lists the names, email addresses or usernames of the authors/owners of the XIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be:

Random J. Useraddress@dom.ain

or

Random J. User (@username)

if the email address or GitHub username is included, and

Random J. User

if the email address is not given.

type header

The type header specifies the category of the XIP to which it belongs. The categories are as follows:

• governance (for XIPs concerning governance matters)
• core-upgrade (pertaining to proposed protocol upgrades)
• integration-upgrade (for introducing new features to the protocol).
• parameter-change (used for XIPs proposing modifications to existing parameters)
• community (used for XIPs in regards to marketing/community events or programs)

created header

The created header records the date that the XIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.

updated header

The updated header records the date(s) when the XIP was updated with "substantial" changes. This header is only valid for XIPs of Draft and Active status.

Auxiliary Files

XIPs may include auxiliary files such as diagrams. Such files must be named XIP-XXXX-Y.ext, where “XXXX” is the XIP number, “Y” is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”).

Operations Seat Responsibilities

For every new XIP submitted, the Operations Seat has various responsibilities. During the drafting stage of the process, the Operations Seat will work closely with the XIP's Author to:

• Ensure the title accurately describes the content.
• 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.
• Check the XIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), and code style

If the XIP isn't ready, the Operations Seat will send it back to the author for revision, with specific instructions.

Once the XIP is ready for the repository, the Operations Seat will:

• Assign an XIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this XIP)
• Merge the corresponding pull request
• Assign a member of CWG to conduct a review on the XIP.
• Send a message back to the Author with the next step.

Whilst the Operations Seat holds an administrative and editorial role, it is also a councillor. This means they have one of the seven available votes which decide whether the XIP is approved or rejected.

The Operations Seat is also granted the ability to make changes to Approved or Implemented XIPs, as well as improve and edit XIP-1, as long as they do not change content within the proposal.

History

This XIP document was derived heavily from the Synthetix Improvement Proposal document and in many places, text was simply copied and modified. Any comments about the XIP document should be directed to the Operations Seat. The history of the SIP is quoted below from the SIP document for context:

• “The SIP document was derived heavily from the EIP Ethereum Improvement Proposal document. In many places text was simply copied and modified. Any comments about the SIP document should be directed to the SIP editors. The history of the EIP is quoted below from the EIP document for context:”
  • "This document (EIP) was derived heavily fromBitcoin's BIP-0001written by Amir Taaki which in turn was derived fromPython's PEP-0001. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use..." *

Copyright

Copyright and related rights waived via CC0.