| PIP | Title | Description | Author | Discussion | Status | Type | Date |
|---|---|---|---|---|---|---|---|
| To be assigned by PIP Editors | The title of the PIP consists of a limited number of words | One short sentence | Authors name + Github/email | URL to Forum | Draft | Core, Contracts, Interface or Informational | (yyyy-mm-dd) format |
This is the suggested template for new PIPs.
Note that an PIP number and status will be assigned by an editor. When opening a pull request to submit your PIP, please use an abbreviated title in the filename, pip-draft_title_abbrev.md.
Abstract is a short (~200 word) description of the technical issue being addressed. This should be a tense but readable version of the specification section. Someone should be able to get a gist of the specification by reading the abstract, without necessarily needing to read any further.
Motivation is critical for PIPs that want to change the Polygon protocol. The motivation section should describe the "why" of this PIP. What problem does it solve? Why should someone want to implement this standard? What are the benefits it provides to the Polygon ecosystem? What are the use cases for this PIP?
The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Polygon protocols.
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.
All PIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The PIP must explain how the author proposes to deal with these incompatibilities. PIP submissions without a sufficient backwards compatibility statement may be rejected by the community.
Test cases for implementation are required for PIPs that are affecting consensus changes. Other PIPs can choose to include links to test cases if applicable.
An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification.
All PIPs should contain a section that discusses the security implications/considerations relevant to the proposed change. It is advisable to include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. A PIP cannot proceed to status “Final” without a robust Security Considerations discussion.
All PIPs must provide a license compatible with the original code it modifies or make available and waive all copyrights and related right under CCO 1.0 Universal.