| code | title | description | author | created | url | results |
|---|---|---|---|---|---|---|
<DIP-xx, use sequential numbering for new proposals> |
<The DIP title is a few words, not a complete sentence> |
<Description is one full (short) sentence> |
<a comma separated list of the author's or authors' names> |
<date created on, in ISO 8601 (yyyy-mm-dd) format> |
<URL with the proposal and voting results> |
<a summary of voting results showing XX% YES, XX% NO, XX addresses, XX votes> |
Use the following template to draft new DAO resolutions.
Refer to the Diva Staking DAO Community Guidelines for additional context.
The Description is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
This section is optional.
The motivation section should include a description of any nontrivial problems the DIP solves. It should not describe how the DIP solves those problems, unless it is not immediately obvious.
The Specification section should describe the new feature or DAO resolution.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
Where necessary, sections will be adding considering:
- Backwards Compatibility
- Test Cases
- Reference Implementation
Discuss the security implications/considerations relevant to the proposed change.
Include a risk classification based on Impact, as described in the Community Guidelines
Copyright and related rights waived via CC0.