Skip to content

Latest commit

 

History

History
62 lines (38 loc) · 5.24 KB

stp-x.md

File metadata and controls

62 lines (38 loc) · 5.24 KB
Error in user YAML: (<unknown>): mapping values are not allowed in this context at line 4 column 152
---
stp: <to be assigned>
title: <STP title>
status: <Draft>
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)>
implementation-date:
discussions-to: <TC Discord Channel>
created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
---

This is the suggested template for new STPs. Note that an STP number will be assigned by an editor. When opening a pull request to submit your STP, please use an abbreviated title in the filename, stp-draft_title_abbrev.md. The title should be 44 characters or less.

Simple Summary

"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposal intends to achieve. This should be accessible to a casual community member.

Abstract

A short (~200 word) description of the proposal, the abstract should clearly describe the proposal. This is what will be done if the STP is implemented, not why it should be done or how it will be done. If the STP proposes sending X tokens to kain.eth each week, write, "we propose to send X tokens to kain.eth each week".

Motivation

This is the problem statement. This is the why of the STP. 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 STP proposes changing how something is calculated, you must address why the current calculation is inaccurate or wrong. This is not the place to describe how the STP will address the issue!

Specification

Overview

This is a high level overview of how the STP 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 this use of funds – what were the considerations. The rationale fleshes out the motivation and reasoning behind decisions that were made. It should describe any alternate ideas 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.

Financial Specification

The financial specification should outline the tokens, amounts, destinations, and schedule of funds to be moved. If appropriate, any technical considerations should also be included here – that is, changes to any of the interfaces Synthetix currently exposes or the creations of new ones.

Copyright

Copyright and related rights waived via CC0.