---
sr: <to be assigned>
title: <SR 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 <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
implementation-date:
discussions-to: <Discord Channel>
network: <Ethereum | Optimism | Base | Ethereum & Optimism | Ethereum, Optimism & Base | Ethereum & Base | Optimism & Base | Arbitrum | Ethereum, Optimism, Base & Arbitrum, Ethereum & Arbitrum >
created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
---
This is the suggested template for new SRs. Note that an SR number will be assigned by an editor. When opening a pull request to submit your SR, please use an abbreviated title in the filename, sr-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 proposal intends to achieve. This should be accessible to a casual community member.
A short (~200 word) description of the proposal, the abstract should clearly describe the proposal. This is what will be done if the SR is implemented, not why it should be done or how it will be done.
This is the problem statement. This is the why of the SR. 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 SR proposes changing how Synthetix operates, you must address why the current methods of operation appear inadequate. This is not the place to describe how the SR will address the issue!
This is a high level overview of how the SR will solve the problem. The overview should clearly describe how the new suggested changes will be implemented.
This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose these changes – 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.
The specification should outline the changes being proposed to the operations, structure or design of Synthetix. For example, changes to any operations of working, changes to governance, changes to the tokenomics, etc.
Copyright and related rights waived via CC0.