Skip to content

Latest commit

 

History

History
69 lines (44 loc) · 4.36 KB

0000-template.md

File metadata and controls

69 lines (44 loc) · 4.36 KB
GIP Title Authors Created Updated Stage Discussions-To Category Depends-On Superseded-By Replaces Resolves Community-Polls Governance Proposals Implementations Audits
<The number of this GIP. To be assigned by editors. Put the number between quotes.>
<The title of this GIP>
<A list of authors. Include full name or pseudonym. At least one author must have valid contact information provided in angle brackets.>
<The date the GIP was created.>
<The date the GIP was last updated.>
<The current stage of the proposal. Specified by the author and confirmed by editors by virtue of a GIP being accepted into an editor's view of the repo.>
<The forum post where this proposal is discussed.>
<(Optional) The type of GIP or GRP. This field should be left blank for GRCs. Valid types are "Protocol Logic," "Protocol Interfaces," "Subgraph API," "Process," "Economic Parameters," and "Protocol Charters".>
<(Optional) A list of GIPs that this GIP depends on. If some other type of dependency exists, include a reference link here and an explanation in the body of the GIP.>
<(Optional) A GIP that supersedes the current proposal. If this field is specified, the stage of the GIP should be "Withdrawn".>
<(Optional) A GIP that this proposal is intended to supersede.>
<(Optional) If this GIP was written in response to an RFP, include it here.>
<(Optional) A list of URLs to community polls relating to this GIP.>
<(Optional) A list of URLs to governance proposals related to this GIP.>
<(Optional) A list of URLs to reference implementations for this proposal.>
<(Optional) A list of URLs to audits related to this proposal.>

(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 a preamble, in RFC 822 format, preceded and followed by three dashes ("—-"). This formatting aids in compatibility with most static site generators.

Given the heterogeneous types of proposals this template is meant to reflect, most sections below, except "Abstract" and "Motivation," may be treated as optional. The author, however, should exercise good judgment 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 its 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 required for a proposal to reach the "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.

Backward Compatibility

(Optional) How does this protocol impact backward 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 implementing 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

Copyright and related rights waived via CC0.