BIP Template
This is the suggested template for new BIPs. Note that a BIP number will be assigned by an editor.
Status: [WIP, Proposed] Author(s): [a list of author(s) names, usernames] Discussions-to: [Create a new thread on https://gov.buzzedbearhideout.com/ and drop the link here] Created: [date created on] Requires (optional): [BIP number(s)] Implementation (optional): [Added if BIP passes]
Buzzed Summary
"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.
Abstract
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 BIP is implemented, not why it should be done or how it will be done. If the BIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".
Motivation
This is the problem statement. This is the why of the BIP. It should clearly explain why the current state of the protocol is inadequate. It is critical that you explain why the change is needed, if the BIP proposes changing how something is calculated, you must address why the current calculation is innaccurate or wrong. This is not the place to describe how the BIP will address the issue!
Specification Overview
This is a high level overview of how the BIP will solve the problem. The overview should clearly describe how the new feature will be implemented.
Rationale
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.
Technical Specification
The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces of the Buzzed Bear Hideout currently exposes or the creations of new ones.
Test Cases
Test cases for an implementation are mandatory for BIPs but can be included with the implementation.
Copyright
Copyright and related rights waived via CC0.
Last updated