---
dip: <to be assigned>
title: <DIP title>
network: <Ethereum | Optimism | Ethereum & Optimism | n/a>
status: <Draft | Approved | Implemented>
author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): FirstName LastName (@GitHubUsername), FirstName LastName <[email protected]>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
implementor: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): FirstName LastName (@GitHubUsername), FirstName LastName <[email protected]>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
release: (Release Name)
implementation-date: <date when implemented, in ISO 8601 (yyyy-mm-dd) format> (*optional)
discussions-to: <link to discussion thread on Dappnet Discord or Github>
proposal: <snapshot.org proposal link> (*optional)
created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
---
This is the suggested template for new DIPs. Note that an DIP number will be assigned by an editor. When opening a pull request to submit your DIP, please use an abbreviated title in the filename, dip-draft_title_abbrev.md. The title should be 44 characters or less.
"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed change intends to achieve. This should be non-technical and accessible to a casual community member.
A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what will be done if the DIP is implemented, not why it should be done or how it will be done. If the DIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".
This is a high level overview of how the DIP will solve the problem. The overview should clearly describe how the new feature will be implemented.
This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Dappnet currently exposes or the creations of new ones.
Test cases for an implementation are mandatory for DIPs but can be included with the implementation.
Please list all values configurable via governance under this implementation.
Copyright and related rights waived via CC0.