| mip | title | status | stability | discussions-to | type | created |
|---|---|---|---|---|---|---|
x |
MIP Title |
Draft |
n/a |
Community |
2023-04-28 |
Note
Rename this file to mip-x.md in your proposal. If more than one MIP will be submitted, then a suffix can be added to each file as mip-x-foo.md, mip-x-bar.md, etc. MIP numbering will automatically be applied with renamed filenames when merged.
["Status" should be one of: Draft | Review | Last Call | Accepted | Implemented | Postponed | Declined | Discontinued]
["Stability" describes the stability of the implementation. Prior to implementation it should be left as "n/a". Once implemented, the stability will be one of: Experimental | Stable | Deprecated]
["Author(s)" should have a comma-separated list of the MIP authors. Each author MUST be written in the following format: Name Surname <email> (@github-username). If the author wants to maintain anonymity, they MAY provide only the username instead of their name and surname. The e-mail and github username are optional and MAY be provided. At least one of the authors MUST have a Github username provided in order to be notified of the changes concerning their MIP.]
["Type" should either be "Community" or "Maintainer". If you are not an API Maintainer, then please use "Community". You can learn more about the distinction between these types in the Process Guide.]
[Brief summary of the proposal]
[Explain why this proposal is necessary and what impact it would have for the developer ecosystem. What problem does it solve? What alternatives were considered (ex. extending via a Snap)? Why is this proposal preferred over alternative solutions or work-arounds?]
[Provide an illustrative example of the proposed API or feature in use]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" written in uppercase in this document are to be interpreted as described in RFC 2119.
[Provide detailed definitions for any new terms or concepts introduced in the proposal]
[Provide a detailed description of the proposed changes, including any relevant technical specifications or examples]
[Include a reference to the OpenRPC specification for any JSON-RPC APIs being proposed - this should be done by opening a PR on the api-specs repository]
[List any potential drawbacks, limitations, or risks associated with the proposal]
[Outline how the proposal will be implemented. Which party is expected to implement the proposal?]
[Explain any considerations that developers should take into account when adopting this proposal. For example, how will it affect compatibility, and what changes may need to be made to accommodate the proposal?]
[Explain any user experience implications of the proposal]
[Explain any potential security implications of the proposal]
[List any relevant resources, documentation, or prior art]
[Provide a way for interested parties to give feedback or make suggestions, such as a GitHub issue or discussion thread]
[List the names of developers who have committed to using this proposal in an experimental state. This will help gauge community interest and adoption.]
Note: This proposal template is meant to be adapted for different contexts and may require additional sections or information depending on the specific proposal.
Copyright and related rights waived via CC0.