| lip | title | author | type | status | created | discussions-to | requires (*optional) | replaces (*optional) | part-of (*optional) |
|---|---|---|---|---|---|---|---|---|---|
<to be assigned> |
<LIP Title> |
<list of authors' names and/or username(s), or name(s) and email(s), e.g. (use with parentheses or triangular brackets) FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> |
<Standard Track | Parameter | Informational | Meta> |
Draft |
<date created on, in ISO 8601 (yyyy-mm-dd) format> |
<URL> |
<LIP number(s)> |
<LIP number(s)> |
<LIP number(s)> |
This is the suggested template for new LIPs.
Note: The LIP number will be assigned by an editor. When opening a pull request to submit a LIP, please use an abbreviated title in the filename using the
following format: LIP-<draft_title_abbrev>.md.
A short (~200 word) description of the technical issue being addressed.
The motivation for a LIP should clearly explain why the existing protocol specification is inadequate to address the problem that the LIP solves. LIP submissions without sufficient motivation may be rejected outright.
The technical specification should describe the syntax and semantics of any new features and the problems the LIP solves. The specification should be detailed enough such that an implementation can be created (both for the smart contracts and the clients interacting with the contracts).
The rationale describes the motivation behind the design of the specification and the reasoning for particular design decisions. Previous related work and alternate designs explored should be described as well. This section can also contain evidence of community consensus around aspects of the design and note important objections or concerns raised during discussion.
All LIPs that introduce backwards incompatabilities must describe the incompatabilities and their severity. The LIP must explain how the author proposes to deal with the incompatibilities. LIPs submitted without sufficiently addressing backward compatibility issues (either by offering solutions or explaining why the incompatibility is of low severity such that it is not a particular concern) maybe rejected outright.
Test cases for an implementation are mandatory for LIPs that make consensus related changes.
The implementation must be completed before a LIP is assigned the "Final" status, but it does not need to be completed before the LIP is accepted. However, in many cases, a basic implementation following the principle of "rough consensus and running code" may be useful in resolving discussions of API details.
Copyright and related rights waived via CC0.