0000-template
(All lists should comprise comma-separated elements. All dates are in ISO 8601 format.)
This is a template GIP proposal showing the layout and formatting described in GIP 0001. Italicized writing are comments and should be removed or replaced. Sections marked optional may also be removed if left empty.
All GIPs MUST include preamble, in RFC 822 format, preceeded and followed by three dashes ("—-"). This formatting aids in compatibility with most static site generators.
Given the heterogeneous types of proposals that this template is meant to reflect, most sections below, with the exception of "Abstract" and "Motivation" may be treated as optional. The author, however, should exercise good judgement in deviating from the template, as they are reflective of the type of information, when relevant, that editors will look for in reviewing a proposal.
Abstract
A brief (roughly 5-10 lines) summary of this proposal.
Motivation
Why are you proposing this change? How will it's adoption benefit The Graph protocol or community? What problem does it solve?
Prior Art
(Optional) What solutions have been explored previously in this problem space? What prior art inspired or influenced this design?
High Level Description
(Optional) Describe your specific solution at a high level. Include diagrams, math formulas, pseudocode, and any other artifacts helpful in showing how your proposal works at a conceptual level. This type of information is requried for a proposal to reach "Proposal" stage.
Detailed Specification
(Optional) Include specific APIs, semantics, data structures, code snippets, etc. related to this proposal. This type of info is required for a proposal to reach the "Draft" stage.
Backwards Compatibility
(Optional) How does this protocol impact backwards compatibility? What breaking changes, if any, are included? Does the proposal have at least N-1 compatibility, or must it be deployed in a knife-edge rollout?
Dependencies
(Optional) How does this proposal depend on other GIPs or other engineering work?
Risks and Security Considerations
(Optional) What technical or security risks are there with impelementing this proposal? How might they be mitigated or addressed?
Validation
(Optional) How should this proposal be validated before being included in the protocol? Examples might include security audits, economic modeling, user research, running in testnet, etc.
Rationale and Alternatives
(Optional) What, if any, alternate designs or interfaces were considered while writing this proposal? Why was the current proposal chosen over any alternate designs? Justify the design decisions you made in writing this proposal.
Copyright Waiver
Last updated
Was this helpful?