| aip | title | author | discussions-to (*optional) | Status | last-call-end-date (*optional) | type | created | updated (*optional) | requires (*optional) |
|---|---|---|---|---|---|---|---|---|---|
(this is determined by the AIP Manager, leave it empty when drafting) |
(AIP title) |
<a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.> |
<a url pointing to the official discussion thread> |
<Draft | Last Call | Accepted | Final | Rejected> |
<mm/dd/yyyy the last date to leave feedbacks and reviews> |
<Standard (Core, Networking, Interface, Application, Framework) | Informational | Process> |
<mm/dd/yyyy> |
<mm/dd/yyyy> |
<AIP number(s)> |
(Please give a temporary file name to your AIP when first drafting it, such as aip-x.md. The AIP manager will assign a number to it after reviewing.)
(Please remove the questions in the "quote box". Provide complete context to the questions being asked in the content that you provide.)
Summarize in 3-5 sentences. Define the problem we're solving. How does this document propose solving it. What are the goals and what is in scope? Any metrics?
...
What are we committing to not doing and why are they scoped out?
...
Define the strawman solution with enough details to make it clear why this is the preferred solution. Please write a 2-3 paragraph high-level overview here and defer writing a more detailed description in the specification section.
...
Which audiences are impacted by this change? What type of action does the audience need to take? What might occur if we do not accept this proposal? List out other AIPs this AIP is dependent on ...
Explain why you submitted this proposal specifically over alternative solutions. Why is this the best possible outcome?
...
How will we solve the problem? Describe in detail precisely how this proposal should be implemented. Include proposed design principles that should be followed in implementing this feature. Make the proposal specific enough to allow others to build upon it and perhaps even derive competing implementations.
...
This is an optional yet highly encouraged section where you may include an example of what you are seeking in this proposal. This can be in the form of code, diagrams, or even plain text. Ideally, we have a link to a living repository of code exemplifying the standard, or, for simpler cases, inline code. What is the feature flag(s)? If there is no feature flag, how will this be enabled? ...
- What is the testing plan? (other than load testing, all tests should be part of the implementation details and won’t need to be called out. Some examples include user stories, network health metrics, system metrics, E2E tests, unit tests, etc)
- When can we expect the results?
- What are the test results and are they what we expected? If not, explain the gap.
...
- Express here the potential risks of taking on this proposal. What are the hazards? What can go wrong?
- Can this proposal impact backward compabitibility?
- What is the mitigation plan for each risk or drawback?
- How can this AIP potentially impact the security of the network and its users? How is this impact mitigated?
- Are there specific parts of the code that could introduce a security issue if not implemented properly?
- Link tests (e.g. unit, end-to-end, property, fuzz) in the reference implementation that validate both expected and unexpected behavior of this proposal
- Include any security-relevant documentation related to this proposal (e.g. protocols or cryptography specifications)
...
Think through the evolution of this proposal well into the future. How do you see this playing out? What would this proposal result in one year? In five years?
...
Describe how long you expect the implementation effort to take, perhaps splitting it up into stages or milestones.
...
Optional: Describe the plan to have SDK, API, CLI, Indexer support for this feature, if applicable.
...
Optional: Indicate a future release version as a rough estimate for when the community should expect to see this deployed on our three networks (e.g., release 1.7). You are responsible for updating this AIP with a better estimate, if any, after the AIP passes the gatekeeper’s design review.
- On devnet?
- On testnet?
- On mainnet?
...
Q&A here, some of them can have answers some of those questions can be things we have not figured out but we should
...