UMIPs (“UMA Improvement Proposals”) are the design documents used to propose changes to the UMA ecosystem. They provide information to the UMA community that describes a new feature for the UMA protocol, or its ecosystem. The UMIP should provide a concise technical specification of the feature and a rationale for the feature. They are modeled after EIPs and ZEIPs. See here for an EIP template and ZEIP template.
We intend UMIPs to be the primary mechanism for proposing new features, collecting community technical input on an issue, and for documenting the design decisions that have gone into the UMA protocol. UMIPs are a convenient way to track the progress of an implementation.
A successful UMIP will move along the following stages: Draft ⟶ Last Call ⟶ Approved ⟶ Final. Unsuccessful states are also possible: Abandoned and Rejected.
A UMIP that is open for consideration and is undergoing rapid iteration and changes. In order to proceed to “Last Call,” the implementation must be complete. Every UMIP author is responsible for facilitating conversations and building community consensus for the proposal.
A UMIP that is done with its initial iteration and ready for review by a wide audience. If upon review, there is a material change or substantial unaddressed complaints, the UMIP will revert to "Draft". If the UMIP requires code changes, the core devs must review the UMIP. A successful UMIP will be in "Last Call" status for a reasonable period of time for comments and be merged (if necessary) before moving to a tokenholder vote.
A UMIP that successfully passes the "Last Call" will be put to UMA tokenholder vote. If tokenholders approve the proposal, the live protocol will be updated to reflect it. At this time, any code changes (if relevant) should be merged into the core protocol repository so that the core protocol repository always reflects the live code that is running.
If tokenholders approve the proposal, the live protocol will be updated to reflect them. The UMIP is then considered to be in the "Final" state.
If at any point during the UMIP Finalization Process, a UMIP is abandoned, it will be labeled as such. Grounds for abandonment include a lack of interest by the original author(s), or it may not be a preferred option anymore.
If tokenholders do not approve a proposal, or the UMIP is fundamentally broken or rejected by the core team, it will not be implemented.
Author (name or username and email)
Status: <Draft, Last Call, Approved, Final, Abandoned, Rejected>
"If you can’t explain it simply, you don’t understand it well enough." Provide a simplified and layman-accessible explanation of the issue.
The motivation is critical to change the UMA protocol. It should clearly explain why the existing protocol specification is inadequate with respect to the issue raised.
The technical specification should describe the syntax and semantics of the proposed solution for the issue raised. If a suggestion is proposed, provide sufficient details so that an implementation would be possible (Proof of Concepts are acceptable).
The rationale should flesh out the specification by describing what motivated the design and why particular design decisions were made, as well as any alternative designs that were considered.