Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Core: involves improvements requiring a consensus fork as well as changes that involve governance governing board decisions.
  • Networking: includes improvements around devp2 and Subprotocol as well as network protocols involving whisper and swarm.
  • Interface: involves improvements around client API/RPC specification standards.
  • ERC: involves application-level standards and conventions, including contract standards such as token standards, name registries, and wallet formats.

...

  • Preamble: This includes the Title, IP Author, and Number.
  • Summary: The summary provides a brief summary of the proposal and its purpose.
  • Specification: This describes the syntax of the new feature. It should be detailed enough to allow competing, interoperable implementations for any current Casper platforms.
  • Motivation: Any IP proposing a change to the network must be able to persuasively describe why the current process is inadequate to solve the problem your IP will effectively solvefix.
  • Rationale: This should detail why certain design decisions were made. It could outline alternative designs, describing why they weren’t chosen, and compatibility in multiple languages. It must also show community consensus and discuss important objections and concerns.
  • Stakeholders: This section should detail how the IP will affect different stakeholder groups on the chain, and what their stance may be towards the proposed update.
  • Backwards Compatibility: All Casper CasperLabs IP’s that suffer from backwards incompatibility must describe these incompatibilities and their severity. The author must explain how they intend to solve these incompatibilities.
  • Test Case: These are mandatory for IP’s that intend to change consensus.
  • Implementation: Must include the test code and documentation appropriate for the Casper CasperLabs protocol. This must be completed before the IP moves into the last status.
  • Copyright: All Casper CasperLabs IP’s must be in the public domain, and must be explicitly licensed under those terms.

...

During Last Call, the IP will be displayed on Casper’s CasperLabs's Governance Website. By this point, the IP is expected to have been debated in the community and developed significant community consensus.

Accepted (Standard Core IP): If there are no technical or material issues and the IP has engaged in significant community discussion. At this point, the IP proceeds to ‘Accepted’.

Accepted (Meta & Informational IP): If there are no technical or material issues and the IP has engaged in significant community discussion. At this point, the IP proceeds to ‘Final’.

...

Significant Community Consensus is defined as constant, open discussion on popular forums of discussion for the CasperLabs community (ie. Mailing List, Reddit, Github, etc…) for at least one month. No person should have any unaddressed, substantiated objections to the IP. Addressed or obstructive objections may be ignored or overruled by general agreement if they have been sufficiently addressed, but clear reasoning must be given in such circumstances.

Accepted (Core IP)

Standard Core IP’s move to the CLX Client Developers. At this point, Client Developers must decide whether to implement the change to the protocol. Consensus is believe to be met if a significant amount of Developers decide to update the software.

...

IP Editors will be nominated by the community and appointed by the Governance BoardCore Team. The community will have the opportunity to nominate candidates as IP Editors, and those with significant community consensus will be chosen by the Governance Board Core Team for review. After review of multiple candidates, the Governance Board Core Team will vote. The vote must be unanimous and each member of the board has the ability to exercise a single veto per election.

...