├── .codespell-whitelist ├── .gitignore ├── .sass-cache ├── 27601696a600f8c750bfb957d6267563e8022d5f │ └── minima.scssc └── 81a794e6149bb69272e907db97d7f50b54a1e9e5 │ ├── _base.scssc │ ├── _layout.scssc │ └── _syntax-highlighting.scssc ├── 404.html ├── ACCP ├── accp-1.md ├── accp-2.md ├── accp-3.md └── accp-4.md ├── AIPs ├── aip-1.md ├── aip-2.md ├── aip-3.md ├── aip-4.md ├── aip-5.md └── aip-6.md ├── CNAME ├── Gemfile ├── Gemfile.lock ├── README.md ├── _config.yml ├── _data └── statuses.yaml ├── _includes ├── accpnums.html ├── accptable.html ├── aipnums.html ├── aiptable.html ├── authorlist.html ├── head.html └── social.html ├── _layouts ├── accp.html └── aip.html ├── accp-X.md ├── aip-X.md ├── all-accp.html ├── all-aip.html ├── assets ├── additional-styles.css └── aip-5 │ ├── curves.png │ ├── formula.png │ ├── price_distribution.png │ ├── rebase_histogram.png │ └── sigmoid.png ├── combined_latexchart_withdeviation.png ├── favicon.ico ├── index.html ├── last-call.xml ├── mathjax-config.js └── test-jekyll ├── .gitignore ├── 404.html ├── Gemfile ├── Gemfile.lock ├── _config.yml ├── _posts └── 2020-10-07-welcome-to-jekyll.markdown ├── about.markdown └── index.markdown /.codespell-whitelist: -------------------------------------------------------------------------------- 1 | uint 2 | ith 3 | mitre 4 | readded 5 | crate 6 | developper 7 | ist 8 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # generated jekyl files 2 | _site 3 | .jekyll-metadata 4 | -------------------------------------------------------------------------------- /.sass-cache/27601696a600f8c750bfb957d6267563e8022d5f/minima.scssc: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/.sass-cache/27601696a600f8c750bfb957d6267563e8022d5f/minima.scssc -------------------------------------------------------------------------------- /.sass-cache/81a794e6149bb69272e907db97d7f50b54a1e9e5/_base.scssc: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/.sass-cache/81a794e6149bb69272e907db97d7f50b54a1e9e5/_base.scssc -------------------------------------------------------------------------------- /.sass-cache/81a794e6149bb69272e907db97d7f50b54a1e9e5/_layout.scssc: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/.sass-cache/81a794e6149bb69272e907db97d7f50b54a1e9e5/_layout.scssc -------------------------------------------------------------------------------- /.sass-cache/81a794e6149bb69272e907db97d7f50b54a1e9e5/_syntax-highlighting.scssc: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/.sass-cache/81a794e6149bb69272e907db97d7f50b54a1e9e5/_syntax-highlighting.scssc -------------------------------------------------------------------------------- /404.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 | 5 | 18 | 19 |
20 |

404

21 | 22 |

Page not found :(

23 |

The requested page could not be found.

24 |
25 | -------------------------------------------------------------------------------- /ACCP/accp-1.md: -------------------------------------------------------------------------------- 1 | --- 2 | accp: 1 3 | title: ACCP Purpose and Guidelines 4 | status: Implemented 5 | author: Tom Nash <@morelazers> 6 | discussions-to: https://discord.gg/6Amxhs4 7 | created: 2020-09-12 8 | --- 9 | 10 | ## What is an ACCP? 11 | 12 | ACCP stands for Ampleforth Configuration Change Proposal. ACCP's are documents to make a case for modifying one of the system configuration variables. The intent is to provide a clear and detailed history behind each configuration change and the rationale behind it at the time it was implemented. The author of the document is responsible for building consensus within the community and documenting dissenting opinions. 13 | 14 | ## ACCP Rationale 15 | 16 | We intend ACCPs to be the primary mechanisms for proposing configuration changes to Ampleforth. Because they are maintained as text files in a versioned repository, their revision history is the historical record of the configuration change proposal. 17 | 18 | It is highly recommended that a single ACCP contain a single variable change. The more focused the ACCP, the more successful it is likely to be. 19 | 20 | An ACCP must meet certain minimum criteria. It must be a clear and complete description of the proposed variable change. 21 | 22 | ## ACCP Work Flow 23 | 24 | Parties involved in the process are the *author*, the [*AIP editors*](#aip-editors), the [Ampleforth Core Contributors], and the Ampleforth Community. 25 | 26 | :warning: Before you begin, vet your idea, this will save you time. Ask the Ampleforth community first if the proposed change is original to avoid wasting time on something that will be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will have the intend effect. The appropriate public forum to gauge interest around your ACCP is [the Ampleforth Discord]. 27 | 28 | Your role as the champion is to write the ACCP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful ACCP will move along: 29 | 30 | ``` 31 | [ WIP ] -> [ PROPOSED ] -> [ APPROVED ] -> [ IMPLEMENTED ] 32 | ``` 33 | 34 | Each status change is requested by the ACCP author and reviewed by the AIP editors. Use a pull request to update the status. Please include a link to the [github issue](https://github.com/ampleforth/AIPs/issues) where people should continue discussing your ACCP. The AIP editors will process these requests as per the conditions below. 35 | 36 | * **Work in progress (WIP)** -- Once the champion has asked the Ampleforth community whether an idea has any chance of support, they will write a draft ACCP as a [pull request]. 37 | 38 | * **Proposed** If agreeable, AIP editor will assign the ACCP a number (generally the issue or PR number related to the ACCP) and merge your pull request. The AIP editor will not unreasonably deny an ACCP. Proposed ACCPs will be discussed on the [github issue](https://github.com/ampleforth/AIPs/issues). If there is a reasonable level of consensus around the change on the governance call the change will be moved to approved. If the change is contentious a vote of token holders may be held to resolve the issue or approval may be delayed until consensus is reached. 39 | 40 | * **Approved** -- This ACCP has passed community governance and is now being prioritised. 41 | 42 | * **Implemented** -- This ACCP has been implemented and the variable changed on mainnet. 43 | 44 | ## What belongs in a successful ACCP? 45 | 46 | Each ACCP should have the following parts: 47 | 48 | - Preamble - RFC 822 style headers containing metadata about the ACCP, including the ACCP number, a short descriptive title (limited to a maximum of 44 characters), and the author details. 49 | - Simple Summary - “If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the ACCP. 50 | - Abstract - a short (~200 word) description of the variable change proposed. 51 | - Motivation (*optional) - The motivation is critical for ACCPs that want to update variables within Ampleforth. It should clearly explain why the existing variable is not incentive aligned. ACCP submissions without sufficient motivation may be rejected outright. 52 | - Copyright Waiver - All ACCPs must be in the public domain. See the bottom of this ACCP for an example copyright waiver. 53 | 54 | ## ACCP Formats and Templates 55 | 56 | ACCPs should be written in [markdown] format. 57 | Image files should be included in a subdirectory of the `assets` folder for that ACCP as follows: `assets/accp-X` (for accp **X**). When linking to an image in the ACCP, use relative links such as `../assets/accp-X/image.png`. 58 | 59 | ## ACCP Header Preamble 60 | 61 | Each ACCP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. 62 | 63 | ` aip:` (this is determined by the AIP editor) 64 | 65 | ` title:` 66 | 67 | ` author:` 68 | 69 | ` * discussions-to:` \ 70 | 71 | ` status:` < WIP | PROPOSED | APPROVED | IMPLEMENTED > 72 | 73 | ` created:` 74 | 75 | ` * updated:` 76 | 77 | ` * requires:` 78 | 79 | Headers that permit lists must separate elements with commas. 80 | 81 | Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd). 82 | 83 | #### `author` header 84 | 85 | The `author` header optionally lists the names, email addresses or usernames of the authors/owners of the ACCP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be: 86 | 87 | > Random J. User <address@dom.ain> 88 | 89 | or 90 | 91 | > Random J. User (@username) 92 | 93 | if the email address or GitHub username is included, and 94 | 95 | > Random J. User 96 | 97 | if the email address is not given. 98 | 99 | #### `discussions-to` header 100 | 101 | While an ACCP is in WIP or Proposed status, a `discussions-to` header will indicate URL for the [github issue](https://github.com/ampleforth/AIPs/issues) where the ACCP is being discussed. 102 | 103 | #### `created` header 104 | 105 | The `created` header records the date that the ACCP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. 106 | 107 | #### `updated` header 108 | 109 | The `updated` header records the date(s) when the ACCP was updated with "substantial" changes. This header is only valid for ACCPs of Draft and Active status. 110 | 111 | #### `requires` header 112 | 113 | ACCPs may have a `requires` header, indicating the ACCP numbers that this ACCP depends on. 114 | 115 | ## Auxiliary Files 116 | 117 | ACCPs may include auxiliary files such as diagrams. Such files must be named ACCP-XXXX-Y.ext, where “XXXX” is the ACCP number, “Y” is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”). 118 | 119 | ## AIP Editors 120 | 121 | The current AIP editors are 122 | 123 | ` * Ahmed Naguib Aly (@ahnaguib)` 124 | 125 | ` * Nithin Krishna (@nithinkrishna)` 126 | 127 | ` * Brandon Iles (@brandoniles)` 128 | 129 | ## AIP Editor Responsibilities 130 | 131 | For each new ACCP that comes in, an editor does the following: 132 | 133 | - Read the ACCP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. 134 | - The title should accurately describe the content. 135 | - Check the ACCP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style 136 | 137 | If the ACCP isn't ready, the editor will send it back to the author for revision, with specific instructions. 138 | 139 | Once the ACCP is ready for the repository, the AIP editor will: 140 | 141 | - Assign an ACCP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this ACCP) 142 | 143 | - Merge the corresponding pull request 144 | 145 | - Send a message back to the ACCP author with the next step. 146 | 147 | Many ACCPs are written and maintained by developers with write access to the Ampleforth codebase. The AIP editors monitor ACCP changes, and correct any structure, grammar, spelling, or markup mistakes we see. 148 | 149 | The editors don't pass judgment on ACCPs. We merely do the administrative & editorial part. 150 | 151 | ## History 152 | 153 | The ACCP document was derived heavily from the EIP Ethereum Improvement Proposal document in many places text was simply copied and modified. Any comments about the ACCP document should be directed to the AIP editors. The history of the EIP is quoted below from the EIP document for context: 154 | 155 | * *"This document (EIP) was derived heavily from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use..."* * 156 | 157 | Oct 12, 2020: ACCP-1 has been drafted and submitted as a PR. 158 | 159 | 160 | See [the revision history for further details](https://github.com/ampleforth/**), which is also available by clicking on the History button in the top right of the ACCP. 161 | 162 | ### Bibliography 163 | 164 | [the Ampleforth Discord]: https://discord.gg/6Amxhs4 165 | [pull request]: https://github.com/Ampleforth/AIPs/pulls 166 | [markdown]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet 167 | [Bitcoin's BIP-0001]: https://github.com/bitcoin/bips 168 | [Python's PEP-0001]: https://www.python.org/dev/peps/ 169 | [Ampleforth Core Contributors]: https://github.com/orgs/Ampleforth/people 170 | 171 | ## Copyright 172 | 173 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 174 | -------------------------------------------------------------------------------- /ACCP/accp-2.md: -------------------------------------------------------------------------------- 1 | --- 2 | accp: 2 3 | title: Request for an Ampleforth:Ether:Wrapped-Bitcoin Balancer Liquidity Pool 4 | author: Shady El Damaty (@seldamat) 5 | discussions-to: https://github.com/ampleforth/AIPs/issues/19 6 | status: Implemented 7 | created: 2020-11-10 8 | requires (*optional): n/a 9 | --- 10 | 11 | 12 | 13 | ## Simple Summary 14 | 15 | This proposal requests the addition of a Wrapped Bitcoin :: Ethereum :: Ampleforth Balancer Pool 16 | 17 | ## Abstract 18 | 19 | The Ampleforth protocol best serves its function as a non-dilutive elastic synthetic commodity when paired with other major assets in sufficient liquidty. The Geyser program has incentivized deep liquidity of Ampl with Ether, however there is still a missing pairing with the number one cryptocurrency: Bitcoin. A balancer pool containing ample, bitcoin and ethereum would address this missing source of liquidity in the ecosystem. A simple 33:33:33 WBTC:AMPL:ETH weighted pool with a standard 0.3% fee is proposed in this ACCP. If passed by the community, then further work should be done to include this pool as supported asset on the Ampleforth Geyser. 20 | 21 | ## Motivation 22 | 23 | The motivation for this ACCP is simply that are no pairings of AMPL with the top cryptocurrency, Bitcoin. A balancer pool will bridge liquidity to include Ethereum, Bitcoin, and Ampleforth. 24 | 25 | ## Copyright 26 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 27 | -------------------------------------------------------------------------------- /ACCP/accp-3.md: -------------------------------------------------------------------------------- 1 | --- 2 | accp: 3 3 | title: "Include support for the kMPL/AMPL Uniswap liquidity pool in the Ampleforth sync() function call fired during rebase" 4 | author: Davoice321 (@davoiceamplesense) 5 | discussions-to: https://github.com/ampleforth/AIPs/issues/25 6 | status: Rejected 7 | created: 2020-11-19 8 | requires (*optional): N/A 9 | --- 10 | 11 | 12 | 13 | ## Simple Summary 14 | 15 | This proposal requests a configuration change that will enable the sync() function call that occurs at Ampleforth rebase to include the incentivized kMPL/AMPL Uniswap v2 token pair. 16 | 17 | ## Abstract 18 | 19 | We are requesting a configuration change so that the sync() function called on rebase includes the incentivized kMPL/AMPL Uniswap v2 pair. 20 | ## Motivation 21 | 22 | The AmpleSense DAO is an independent, community-powered [organization](https://amplesense.io). Its mission is to expand the ecosystem of products and services (including in the areas of education, lending, borrowing and elastic finance) surrounding the Ampleforth protocol. 23 | 24 | One of the DAO's critical initial activities was to distribute its governance token KiloAmple (kMPL) to the community via its "kGeyser" liquidity programs. The DAO has committed to distributing 73% of the token supply via these programs. The first kGeyser program, Zeus was launched in early November and rewards AMPL/ETH Uniswap liquidity providers with kMPL tokens. 25 | 26 | The second kGeyser liquidity mining program is called Apollo. The AmpleSense DAO’s two-stage governance process revealed ([vote](https://snapshotpage.b-cdn.net/#/amplesense/proposal/QmboVwWmDt8TJxnuMbjpt39io4z3x3Y3j4TmgvkT5yJAKQ)) that AMPL was the overwhelming choice of the community to be paired with the kMPL token in the Apollo kGeyser. 27 | 28 | The kMPL/AMPL Uniswap v2 pair is currently [live](https://info.uniswap.org/pair/0x53b784d0fb88f53c6af76839a7eaec8e95729375) on Uniswap and liquidity providers are receiving kMPL rewards for providing liquidity. 29 | 30 | However, kMPL/AMPL trading has not yet begun. To activate trading, a configuration change must be made within the Ampleforth protocol to ensure the kMPL/AMPL pair is incorporated into the sync() function call that is fired upon rebase. 31 | 32 | The motivation for this ACCP is to request this critical configuration change, which is required to initiate Uniswap trading on the kMPL/AMPL pair. 33 | 34 | - 35 | ## Copyright 36 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 37 | -------------------------------------------------------------------------------- /ACCP/accp-4.md: -------------------------------------------------------------------------------- 1 | --- 2 | accp: 4 3 | title: "Add Tellor oracle to provide AMPL/USD and US Personal Consumption Expenditures values" 4 | author: Tellor Team (@tellor-io) 5 | discussions-to: https://forum.ampleforth.org/t/proposal-to-add-tellor-as-additional-oracle/56 6 | status: Proposed 7 | created: 2021-05-21 8 | requires (*optional): N/A 9 | --- 10 | 11 | 12 | 13 | ## Simple Summary 14 | 15 | This is a proposal to add Tellor as an additional oracle to the Ampleforth system. The goal of this addition is to further decentralize the protocol and create a more robust, censorship-resistant price feed. Tellor is a decentralized oracle that uses a network of staked miners who compete to fetch off-chain data and place it on-chain. 16 | 17 | ## Abstract 18 | 19 | We propose that Ampleforth will use Tellor to bring on two values: the AMPL/USD value and the US Personal Consumption Expenditures (a key measure of inflation). The values will be medianized with the current price feeds provided by Chainlink and the Ampleforth team. 20 | 21 | ## Motivation 22 | 23 | In order for AMPL to do its daily “rebase,” it requires a price of AMPL/USD on-chain so that the protocol knows how to adjust the supply. It doesn’t peg directly to the dollar, but rather an inflation-adjusted dollar. Using the US Personal Consumption Expenditures Price Index, it can track the value of the US dollar versus costs. This means that AMPL will still hold a stable value versus goods and services, even if the US dollar collapses in value. There is no reliance on traditional banks or lenders of last resort to guarantee liquidity. 24 | 25 | As an oracle that specializes in decentralization and censorship-resistance, we believe adding Tellor into the system greatly helps Ampleforth’s own efforts of decentralization and adds further security and robustness to the price feed. 26 | 27 | ## Specification 28 | The supply change is referred to as supply rebase and is applied daily at 2 AM UTC. The price used to compute the deviation from the market price is the volume weighted average of AMPL trades over the 24 hours of the previous day from midnight to midnight UTC across all markets/exchanges and pairs. 29 | 30 | Tellor becomes the third oracle to power AMPL price feeds, joining Chainlink and Ampleforth itself. The median (or average, if there are only two) will determine the daily rebase to ensure the most accurate outcome each day. 31 | 32 | ## Rationale 33 | In order for the Ampleforth community to fulfill their vision as a decentralized financial primitive, the censorship resistance of the protocol must be the first and foremost priority. The communities of Tellor and Ampleforth have similar drives towards and beliefs as to what constitutes a decentralized protocol and the ability of the two projects to work together will help further the entire space. 34 | 35 | Tellor’s system is a completely on-chain data feed that can be accessed by Ampleforth smart contracts. The design for integrating Tellor into Ampleforth includes creating an adaptor that pulls values from Tellor and pushes them to Ampleforth's oracle medianizer, and configuring this adaptor as a new provider in the medianizer. Additionally, changes to Tellor are needed, which include an off-chain mechanism for both calculating the Ampleforth price and the CPI update as well as automated software for maintaining the liveliness of the oracle in a decentralized manner. 36 | 37 | Tellor added the AMPL/USD price calculation in mid 2020 and has been updating it since and they have also created scripts for automating the price updates before they are needed by the AMPL system. 38 | 39 | * [Tellor mining software (data providers)](https://github.com/tellor-io/telliot) 40 | * [Tellor tipping scripts](https://github.com/tellor-io/tipperTemplate) 41 | 42 | ## Technical Specification 43 | Tellor is a fully on-chain oracle, so all data is publicly accessible. By creating a small interface for interacting with the Tellor contracts, values from the Tellor oracle can be utilized by the Ampleforth market-oracle. The AMPL system will simply need to add Tellor to its list of oracles and medianize/average the prices accordingly. 44 | 45 | The integrator pieces and contracts can be found here: https://github.com/ampleforth/Tellor/pull/1 (AMPL can make this public when they see fit, or we can make it into a PR on the market oracle, up to them) 46 | 47 | ## Test Cases 48 | In the pull request are various test cases for locally testing the pull request. To follow best practices, the Tellor team will assist in testing on an Ethereum testnet before launch to mainnet. Things that can be examined and solidified are the automation of the updates on Tellor and the analysis of the security and liveness of the system. 49 | 50 | ## Copyright 51 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 52 | -------------------------------------------------------------------------------- /AIPs/aip-1.md: -------------------------------------------------------------------------------- 1 | --- 2 | aip: 1 3 | title: AIP Purpose and Guidelines 4 | author: Tom Nash (@morelazers) 5 | discussions-to: https://discord.gg/6Amxhs4 6 | status: Implemented 7 | created: 2020-09-12 8 | requires: N/A 9 | --- 10 | 11 | ## What is an AIP? 12 | 13 | AIP stands for Ampleforth Improvement Proposal, it has been adapted from the EIP (Ethereum Improvement Proposal). The purpose of this process is to ensure changes to Ampleforth are transparent and well governed. An AIP is a design document providing information to the Ampleforth community about a proposed change to the system. The author is responsible for building consensus within the community and documenting dissenting opinions. 14 | 15 | ## What is an ACCP? 16 | 17 | ACCP stands for Ampleforth Configuration Change Proposal. ACCP's are documents for making a case for modifying one of the system configuration variables. The intent is to provide a clear and detailed history behind each configuration change and the rationale behind it at the time it was implemented. The author of the document is responsible for building consensus within the community and documenting dissenting opinions. 18 | 19 | ## AIP & ACCP Rationale 20 | 21 | We intend AIPs and ACCPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and for documenting the design decisions for changes to Ampleforth. Because they are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. 22 | 23 | It is highly recommended that a single AIP contain a single key proposal or new idea. The more focused the AIP, the more successful it is likely to be. 24 | 25 | An AIP or ACCP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. 26 | 27 | ## AIP Work Flow 28 | 29 | Parties involved in the process are the *author*, the [*AIP editors*](#aip-editors), the [Ampleforth Core Contributors], and the Ampleforth Community. 30 | 31 | :warning: Before you begin, vet your idea, this will save you time. Ask the Ampleforth community first if an idea is original to avoid wasting time on something that will be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will have the intend effect. The appropriate public forum to gauge interest around your AIP or ACCP is [the Ampleforth Discord]. 32 | 33 | Your role as the champion is to write the AIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful AIP will move along: 34 | 35 | ``` 36 | [ WIP ] -> [ PROPOSED ] -> [ APPROVED ] -> [ IMPLEMENTED ] X [ REJECTED ] 37 | ``` 38 | 39 | Each status change is requested by the AIP author and reviewed by the AIP editors. Use a pull request to update the status. Please include a link to the [github issue](https://github.com/ampleforth/AIPs/issues) where people should continue discussing your AIP. The AIP editors will process these requests as per the conditions below. 40 | 41 | * **Work in progress (WIP)** -- Once the champion has asked the Ampleforth community whether an idea has any chance of support, they will write a draft AIP as a [pull request]. Consider including an implementation if this will aid people in studying the AIP. 42 | * **Proposed** If agreeable, AIP editor will assign the AIP a number (generally the issue or PR number related to the AIP) and merge your pull request. The AIP editor will not unreasonably deny an AIP. Proposed AIPs will be discussed on a [github issue](https://github.com/ampleforth/AIPs/issues). If there is a reasonable level of consensus around the change on the governance call the change will be moved to approved. If the change is contentious a vote of token holders may be held to resolve the issue or approval may be delayed until consensus is reached. 43 | * **Approved** -- This AIP has passed community governance and is now being prioritised for development. 44 | 45 | * **Implemented** -- This AIP has been implemented and deployed to mainnet. 46 | 47 | * **Rejected** -- This AIP has failed to reach community consensus. 48 | 49 | ## What belongs in a successful AIP? 50 | 51 | Each AIP or ACCP should have the following parts: 52 | 53 | - Preamble - RFC 822 style headers containing metadata about the AIP, including the AIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details. 54 | - Simple Summary - “If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the AIP. 55 | - Abstract - a short (~200 word) description of the technical issue being addressed. 56 | - Motivation (*optional) - The motivation is critical for AIPs that want to change Ampleforth. It should clearly explain why the existing specification is inadequate to address the problem that the AIP solves. AIP submissions without sufficient motivation may be rejected outright. 57 | - Specification - The technical specification should describe the syntax and semantics of any new feature. 58 | - Rationale - 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. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. 59 | - Test Cases - Test cases may be added during the implementation phase but are required before implementation. 60 | - Copyright Waiver - All AIPs must be in the public domain. See the bottom of this AIP for an example copyright waiver. 61 | 62 | ## AIP Formats and Templates 63 | 64 | AIPs should be written in [markdown] format. 65 | Image files should be included in a subdirectory of the `assets` folder for that AIP as follows: `assets/aip-X` (for aip **X**). When linking to an image in the AIP, use relative links such as `../assets/aip-X/image.png`. 66 | 67 | ## AIP Header Preamble 68 | 69 | Each AIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. 70 | 71 | ` aip:` (this is determined by the AIP editor) 72 | 73 | ` title:` 74 | 75 | ` author:` 76 | 77 | ` * discussions-to:` \ 78 | 79 | ` status:` < WIP | PROPOSED | APPROVED | IMPLEMENTED > 80 | 81 | ` created:` 82 | 83 | ` * updated:` 84 | 85 | ` * requires:` 86 | 87 | ` * resolution:` \ 88 | 89 | Headers that permit lists must separate elements with commas. 90 | 91 | Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd). 92 | 93 | #### `author` header 94 | 95 | The `author` header optionally lists the names, email addresses or usernames of the authors/owners of the AIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be: 96 | 97 | > Random J. User <address@dom.ain> 98 | 99 | or 100 | 101 | > Random J. User (@username) 102 | 103 | if the email address or GitHub username is included, and 104 | 105 | > Random J. User 106 | 107 | if the email address is not given. 108 | 109 | #### `discussions-to` header 110 | 111 | While an AIP is in WIP or Proposed status, a `discussions-to` header will indicate the URL for the [github issue](https://github.com/ampleforth/AIPs/issues) where the AIP is being discussed. 112 | 113 | #### `created` header 114 | 115 | The `created` header records the date that the AIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. 116 | 117 | #### `updated` header 118 | 119 | The `updated` header records the date(s) when the AIP was updated with "substantial" changes. This header is only valid for AIPs of Draft and Active status. 120 | 121 | #### `requires` header 122 | 123 | AIPs may have a `requires` header, indicating the AIP numbers that this AIP depends on. 124 | 125 | ## Auxiliary Files 126 | 127 | AIPs may include auxiliary files such as diagrams. Such files must be named AIP-XXXX-Y.ext, where “XXXX” is the AIP number, “Y” is a serial number (starting at 1), and “ext” is replaced by the actual file extension (e.g. “png”). 128 | 129 | ## AIP Editors 130 | 131 | The current AIP editors are 132 | 133 | ` * Ahmed Naguib Aly (@ahnaguib)` 134 | 135 | ` * Nithin Krishna (@nithinkrishna)` 136 | 137 | ` * Brandon Iles (@brandoniles)` 138 | 139 | ## AIP Editor Responsibilities 140 | 141 | For each new AIP that comes in, an editor does the following: 142 | 143 | - Read the AIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status. 144 | - The title should accurately describe the content. 145 | - Check the AIP for language (spelling, grammar, sentence structure, etc.), markup (Github flavored Markdown), code style 146 | 147 | If the AIP isn't ready, the editor will send it back to the author for revision, with specific instructions. 148 | 149 | Once the AIP is ready for the repository, the AIP editor will: 150 | 151 | - Assign an AIP number (generally the PR number or, if preferred by the author, the Issue # if there was discussion in the Issues section of this repository about this AIP) 152 | 153 | - Merge the corresponding pull request 154 | 155 | - Send a message back to the AIP author with the next step. 156 | 157 | Many AIPs are written and maintained by developers with write access to the Ampleforth codebase. The AIP editors monitor AIP changes, and correct any structure, grammar, spelling, or markup mistakes we see. 158 | 159 | The editors don't pass judgment on AIPs. We merely do the administrative & editorial part. 160 | 161 | ## History 162 | 163 | The AIP document was derived heavily from the EIP Ethereum Improvement Proposal document in many places text was simply copied and modified. Any comments about the AIP document should be directed to the AIP editors. The history of the EIP is quoted below from the EIP document for context: 164 | 165 | * *"This document (EIP) was derived heavily from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use..."* * 166 | 167 | Oct 12, 2020: AIP 1 has been drafted and submitted as a PR. 168 | 169 | 170 | See [the revision history for further details](https://github.com/ampleforth/), which is also available by clicking on the History button in the top right of the AIP. 171 | 172 | ### Bibliography 173 | 174 | [the Ampleforth Discord]: https://discord.gg/mptQ49m 175 | [pull request]: https://github.com/ampleforth/AIPs/pulls 176 | [markdown]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet 177 | [Bitcoin's BIP-0001]: https://github.com/bitcoin/bips 178 | [Python's PEP-0001]: https://www.python.org/dev/peps/ 179 | [Ampleforth Core Contributors]: https://github.com/orgs/Ampleforth/people 180 | 181 | ## Copyright 182 | 183 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 184 | -------------------------------------------------------------------------------- /AIPs/aip-2.md: -------------------------------------------------------------------------------- 1 | --- 2 | aip: 2 3 | title: Continuous Vesting Token Distribution 4 | author: Brandon Iles , Nithin Krishna 5 | discussions-to: https://discord.gg/6Amxhs4 6 | status: Implemented 7 | created: 2019-09-30 8 | --- 9 | 10 | ## Simple Summary 11 | 12 | A smart-contract based mechanism to distribute tokens over time, inspired loosely by Compound and Uniswap. 13 | 14 | 15 | ## Abstract 16 | 17 | The following is a smart-contract based mechanism for distributing tokens over time, inspired loosely by Compound's continuous interest accrual and Uniswap's liquidity pool tokens. 18 | 19 | Distribution tokens (in our case AMPL) are added to a locked pool in the contract and become unlocked over time according to a once-configurable unlock schedule. Once unlocked, they are available to be claimed by users. 20 | 21 | A user may deposit tokens (in our case AMPL-Uniswapv2 LP)to accrue ownership share over the unlocked pool. This owner share is a function of the number of tokens deposited as well as the length of time deposited. Specifically, a user's share of the currently-unlocked pool equals their "deposit-seconds" divided by the global "deposit-seconds". This aligns the new token distribution with long term supporters of the project, addressing one of the major drawbacks of simple airdrops. 22 | 23 | When the user redeems, they receive their share of the current unlocked distribution pool along with their previously deposited tokens. Users may deposit or redeem at any time, so aren't required to "lock up" tokens for any fixed period. However, to disincentivize continuous deposit/withdraw behavior there is a gradual bonus that's applied that reaches max after a configurable time frame. 24 | 25 | New distribution tokens may optionally be added to the locked pool by the owner along with an associated unlock time. However, the only way for distribution tokens to be removed from the system is by redeeming previously deposited tokens. User deposit tokens are only used to claim ownership and are never transferred to others. 26 | 27 | 28 | ## Motivation 29 | 30 | As described in the [Token Transparency Report](https://medium.com/ampleforth/ampleforth-ieo-and-token-distribution-transparency-report-d7b632bbc838), roughly 20% and 23% of the total AMPL supply are currently allocated to the Treasury and Ecosystem Fund. We need to eventually find a way to distribute these tokens to users in “as sensible” way as possible. We’d also like to maintain our commitment to a rules-based policy in all aspects of the project. To that end, we can encode the distribution schedule and rules into a smart contract that operates autonomously over time. 31 | 32 | Airdrops have shown limited success in aligning recipients and projects--many get lost, forgotten, or simply dumped on markets. This system shows proof of care through continued ownership through any market condition as well as rewards users who contribute positively to the ecosystem through providing liquidity. 33 | 34 | 35 | ## Specification 36 | 37 | This application will implement the EIP-900 Simple Staking Interface and will be general enough for use with any ERC-20 tokens. The deposit aka "Staking" token and distribution token may be the same or be different and are specified during initialization. 38 | 39 | ```solidity 40 | interface ContVestTokenDist is ERC20Detailed, IStaking { 41 | 42 | event TokensUnlocked(uint256 stage, uint256 numTokens); 43 | 44 | constructor(address stakingToken, address distributionToken); 45 | 46 | function getStakingToken() public view returns (address); 47 | function getDistributionToken() public view returns (address); 48 | 49 | // Unlock schedule & adding tokens 50 | function addUnlockStageTokens(uint256 numTokens, uint256 unlockTimestamp) public returns (bool); 51 | function numUnlockStages() public view returns (uint256); 52 | function unlockTimestampForStage(uint256 stage) public view returns (uint256); 53 | function unlockTokensForStage(uint256 stage) public view returns (uint256); 54 | 55 | // Pool info 56 | function getUnlockedPoolSize() public view returns (uint256); 57 | function getLockedPoolSize() public view returns (uint256); 58 | function totalDeposited() public view returns (uint256); 59 | function totalDepositedFor(address user) public view returns (uint256); 60 | 61 | function updateGlobal() public returns (bool); 62 | 63 | // EIP-900 Staking Interface for managing deposits and withdrawals 64 | event Staked(address indexed user, uint256 amount, uint256 total, bytes blockTimestamp); 65 | event Unstaked(address indexed user, uint256 amount, uint256 total, bytes blockTimestamp); 66 | 67 | function stake(uint256 amount, bytes _) public; 68 | function stakeFor(address user, uint256 amount, bytes _) public; 69 | function unstake(uint256 amount, bytes _) public; 70 | function totalStakedFor(address addr) public view returns (uint256); 71 | function totalStaked() public view returns (uint256); 72 | function token() public view returns (address); 73 | function supportsHistory() public pure returns (bool); 74 | 75 | function lastStakedFor(address addr) public view returns (uint256); 76 | function totalStakedForAt(address addr, uint256 blockNumber) public view returns (uint256); 77 | function totalStakedAt(uint256 blockNumber) public view returns (uint256); 78 | 79 | // ERC-20 Interface for internal CVTD tokens 80 | event Transfer(address indexed from, address indexed to, uint256 value); 81 | event Approval(address indexed owner, address indexed spender, uint256 value); 82 | 83 | function name() public view returns (string memory); 84 | function symbol() public view returns (string memory); 85 | function decimals() public view returns (uint8); 86 | function totalSupply() external view returns (uint256); 87 | function balanceOf(address account) external view returns (uint256); 88 | function transfer(address recipient, uint256 amount) external returns (bool); 89 | function allowance(address owner, address spender) external view returns (uint256); 90 | function approve(address spender, uint256 amount) external returns (bool); 91 | function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); 92 | function increaseAllowance(address spender, uint256 addedValue); 93 | function decreaseAllowance(address spender, uint256 subtractedValue); 94 | } 95 | ``` 96 | 97 | ## Rationale 98 | Many different kinds of distribution have been attempted by projects. One thing that's clear is the limited effectiveness of airdrops. Historically, most airdrops have been either ignored by recipients or immediately sold. 99 | 100 | Direct lockups would be the most straightforward, where a user locks up X tokens for Y time to receive X+Z tokens in return. This structure is easy to understand, but since we want to unlock in blocks there would be different tranches for tokens as they unlock through time. We'd end up having multiple concurrent airdrop contracts users interact with, which is confusing. Also, since there’s a limited number of total tokens to unlock, there’s a limited number of tokens that can be staked, so a single whale could conceivably take all the slots. 101 | 102 | Projects are still free to place educational material on the frontend to teach users about the application before they interact with the underlying system. If done properly, this solves a second problem with airdrops related to user education. 103 | 104 | 105 | ## Implementation 106 | 107 | The front-end is open to change during development, but the basic information to expose is: 108 | - Number of AMPL staked by user 109 | - Size of AMPL locked and unlocked pools 110 | - Current fractional ownership of unlock pool 111 | - "Stake" and "Unstake" functions 112 | - Unlock schedule 113 | 114 | Smart contracts will reside in https://github.com/ampleforth/token-geyser 115 | 116 | ## Copyright 117 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 118 | -------------------------------------------------------------------------------- /AIPs/aip-3.md: -------------------------------------------------------------------------------- 1 | --- 2 | aip: 3 3 | title: Disallow Contracts from calling Rebase 4 | author: Brandon Iles , Nithin Krishna , Ahmed Naguib Aly 5 | discussions-to: https://discord.gg/6Amxhs4 6 | status: Implemented 7 | created: 2020-03-26 8 | --- 9 | 10 | ## Simple Summary 11 | 12 | Proposal to disallow rebase from being called by contracts, to guard against flash loan attacks on liquidity providers. 13 | 14 | ## Abstract 15 | 16 | Flash loans can be leveraged in combination with a rebase call to effectively "steal" rebase awards from liquidity providers on trading and lending platforms. Liquidity providers can be negatively impacted on both expansionary and contractionary cycles. Without any change to address this, AMPL holders may be disincentivized from providing liquidity. This has a negative effect on the health of the AMPL ecosystem, and also counteracts the liquidity incentive program described in [AIP-1](AIPs/aip-1.md) 17 | 18 | A solution of preventing non-EOA addresses from calling rebase is proposed. 19 | 20 | ## Motivation 21 | 22 | Consider the following scenario. Alice deploys a contract onchain. It has one method that performs the following: 23 | 1) Takes out all AMPL from uniswap v2 via a flash swap. 24 | 2) Call rebase when in an expansionary period. 25 | 3) Return AMPL back to Uniswap, keeping rebase awards. 26 | 27 | While this does provide an incentive for callers to execute rebase, the net result is that liquidity providers lose out on all the AMPL tokens they would have received from an expansionary cycle. 28 | 29 | Similar attacks can be performed with non-AMPL flash loans and don't require AMPL to be available on lending platforms. 30 | 31 | 1) Take out an ETH flash loan from Dydx, Aave, and/or other platforms. 32 | 2) Buy as much AMPL as possible from Uniswap, Kyber, Bancor, ... 33 | 3) Calls rebase when in expansionary period 34 | 4) Sells AMPL back 35 | 5) pays off ETH loan 36 | 37 | Alice only has to overcome the following fees: 38 | - 2*0.3% uniswap fee 39 | - Dydx charges 0% on flash loans, Aave charges 0.09% 40 | 41 | Alice is profitable as long as the oracle rate is roughly > $1.06. With the existing deviation threshold of 5%, positive rebases start at $1.06155 42 | 43 | Shorts spanning contractionary rebases similarly impact liquidity providers by offloading more of the contraction adjustment to them. 44 | 45 | The most damaging effect of allowing flash loan users to call rebase is that it will discourage people from supplying liquidity on DEXs and lending platforms. This would lead to unnecessarily high volatility and unpredictability around supply adjustments. 46 | 47 | ## Specification 48 | 49 | To address this, the dev council proposes adding a single check at the top of our Supply Policy rebase function: 50 | 51 | `require(msg.sender == tx.origin);` 52 | 53 | This enforces that rebase is only called from EOA wallets, which removes the possibility of flash loans being used simultaneously with rebase calls. 54 | 55 | Note that `tx.origin` is NOT used for authentication. 56 | 57 | ## Rationale 58 | EOAs (Externally Owned Account) are unable to leverage flash loans, because flash loans require multiple steps within the same transaction: loan, do something, repay. Requiring rebases be called from EOA is the simplest way to bar flash loan attacks on rebases. 59 | 60 | While it's still possible to perform the same actions without flash loans, the user would be subjecting themselves to considerable market risk and also have to put a lot of their own capital at stake to do so. 61 | 62 | An alternative implementation would be to create a whitelist of ethereum addresses (EOA or contracts) allowed to execute rebases. There are two benefits: approved contracts (including multisigs) would be able to call rebase, and we would avoid using the relatively controversial `tx.origin`. 63 | 64 | The downsides are that it would expand the surface area of governance, add more complexity to the system, and remove the ability for "anyone" to call rebase. So far, the Ampleforth system only uses whitelists in the oracle where it's inherently part of the architecture. We'd prefer to not expand the use of whitelists if not absolutely necessary, especially in the token and policy. 65 | 66 | While enforcing EOA status breaks the general composability of contracts, we believe the proposed solution is the best tradeoff. Since rebase is meant to be "public", the use case for multisigs is basically non-existent, allowing all contracts is too dangerous, and whitelisting contracts brings too much governance requirements. 67 | 68 | One common way of disallowing flash loans around a critical operation is to make that operation span multiple transactions. We could, in theory, require rebase to occur in two phases, each in different blocks. However, this is not viable in our case since one step must affect the supply adjustment and this adjustment could still be wrapped with flash loans. 69 | 70 | ## Implementation 71 | The dev council will author the code change to the uFragments repo. The governance multisig will then be used to upgrade the policy's implementation code via the OpenZeppelin AdminUpgradeabilityProxy. 72 | 73 | [Github Release](https://github.com/ampleforth/uFragments/releases/tag/v1.0.1), deployed 2020-04-02. 74 | 75 | ## Copyright 76 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 77 | -------------------------------------------------------------------------------- /AIPs/aip-4.md: -------------------------------------------------------------------------------- 1 | --- 2 | aip: 4 3 | title: Remove Pause Functions from Token and Policy 4 | author: Brandon Iles , Nithin Krishna , Ahmed Naguib Aly 5 | discussions-to: https://discord.gg/6Amxhs4 6 | status: Implemented 7 | created: 2020-07-24 8 | --- 9 | 10 | ## Simple Summary 11 | 12 | Proposal to remove the pause functions in the AMPL ERC-20 and Supply Policy contracts. 13 | 14 | ## Abstract 15 | There are currently two admin-callable functions, *setRebasePaused* and *setTokenPaused*, that were included in the initial 16 | deployment as emergency controls. They were meant to: 17 | - Facilitate the launch itself 18 | - Guard balances in critical situations post-launch 19 | 20 | As stated in the pre-launch [governance post](https://www.ampltalk.org/app/forum/governance-20/topic/state-of-discretion-and-governance-in-ampleforth-6/): 21 | > We view both of these emergency switches as options of last resort and hope they never have to be enabled. We felt it was most responsible to launch with these in place, especially in the early days when the system is new and proving its worth in an adversarial environment. 22 | 23 | It has now been over a year. After unpausing the system at the time of launch with Bitfinex, there has been no need to enable either of these. 24 | Now that the implementation of the AMPL token and the Supply Policy have had time to prove themselves, we believe it's time they are removed. 25 | 26 | ## Motivation 27 | **setRebasePaused** fixes the supply of the token until rebase is unpaused--the supply stays constant and 28 | Amples are still freely tradable by anyone. This was to guard against unexpected problems in the supply policy or oracle system upstream 29 | of the token. 30 | 31 | **setTokenPaused** pauses all transfers on chain. This was meant to guard balances against 32 | unexpected problems in the token itself. It was also a guard used to help facilitate the launch before listing. 33 | 34 | Removing these two functions decreases both "Centralization Risk" and "Integration Risk". 35 | 36 | ## Rationale 37 | As long as these functions exist, they are open to misuse by whoever controls the admin key (currently a 2-of-n multisig wallet owned by the development team). 38 | 39 | Even as the Ampleforth governance process decentralizes, we'd like to keep the governance surface area as small as possible to 40 | avoid complexity and potential for exploits. 41 | 42 | Secondly, Pausability increases the risk for outside platforms which build with AMPL. Not every platform is willing (or able) to implement logic that safely 43 | handles failed transfers of paused tokens. This may harm AMPL's ability to support the wider DeFi ecosystem. 44 | 45 | ## Implementation 46 | The OpenZeppelin AdminUpgradabilityProxy will be used to update the implementation of UFragments. 47 | The two pause functions would be removed. 48 | Special care will be taken to ensure no changes are made to the storage layout. 49 | 50 | ## Copyright 51 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 52 | -------------------------------------------------------------------------------- /AIPs/aip-5.md: -------------------------------------------------------------------------------- 1 | --- 2 | aip: 5 3 | title: Sigmoid Rebase Function 4 | author: Ahmed Naguib Aly (@ahnaguib) 5 | discussions-to: https://forum.ampleforth.org/t/rebase-curve-upgrade-proposal/327 6 | status: Implemented 7 | created: 2020-12-1 8 | --- 9 | ## Summary 10 | 11 | Change the rebase factor function from a linear curve to an S-shaped curve. 12 | 13 | ## Abstract 14 | 15 | The proposal is to deploy a new contract that updates the current supply policy's linear rebase function with a Sigmoid function. 16 | 17 | ## Motivation 18 | 19 | The original Ampleforth linear rebase function was intended to make minimal assumptions about how price reacts to expansion and contraction--i.e. expansion would slow price increases by translating them into supply increases and contraction would slow price decreases by translating them into supply decreases. Hence the main purpose of the function is to point supply change in the right direction without trying to predict the exact magnitude of supply change needed for the fastest convergence to the price target. 20 | 21 | At this point in time there is history to analyze and use to improve the rebase curve accordingly. e.g, we can see that extreme market scenarios can have outsized effects on AMPL supply, which then require prolonged supply corrections. The linear curve is very limited on how it can be configured and an S-shaped curve can allow for more sophisticated tuning of the rebase function. 22 | 23 | The advantages of an Sigmoid curve: 24 | 25 | * Can be configured to have different slopes at different points of the curve. 26 | 27 | * It has bounds (asymptotes) 28 | * That makes AMPL supply changes relatively more predictable beyond the current day 29 | * Limits the potential effect from a bad oracle price. This makes AMPL more resilient to errors and attacks and also increases the feasibility of further oracle decentralization efforts. 30 | 31 | ## Specification 32 | 33 | The smart contract upgrade replaces the current linear rebasing function with a sigmoid curve that caps supply changes at its asymptotes 34 | 35 |

36 | 37 |

38 | 39 | ``` 40 | Rebase factor of 1.0 means no rebase. 41 | Normalized price = VWAP price / Target price 42 | ``` 43 | 44 | The proposed curve above is generated by the sigmoid function: 45 | 46 |

47 | 48 |

49 | 50 | F(x) : fraction of supply added or removed (supply change %) 51 | 52 | x : normalized price deviation 53 | 54 | NOTE: x in the formula above is normalized price deviation and F(x) is the fraction of change while the diagram for better visual representation shows the normalized price on the x-axis and the supply multiplier factor on the y-axis. 55 | 56 | It has shaping parameters that determine: lower asymptote, upper asymptote, and the steepness of the curve (ie: growth rate). 57 | 58 | ``` 59 | l = lower asymptote 60 | u = upper asymptote 61 | g = growth rate 62 | ``` 63 | 64 | ### Technical Specification 65 | 66 | This update creates no changes to external APIs. Clients, including exchanges that listen to AMPL’s rebase events, will still receive the absolute supply change integer as before. However, note that any external application that calculates the supply change independently will need to update their calculation logic. 67 | 68 | ### Parameter Values 69 | 70 | The parameters are chosen to be very similar to the current curve in the normalized price range of ($0.5 to $1.5) and caps the changes to 10% on the expansion side, and that caps the contraction side at -7.78% 71 | 72 | The proposed values are: 73 | 74 | ``` 75 | l (Lower) = -0.1 76 | u (Upper) = 0.1 77 | g (Growth) = 3 78 | ``` 79 |

80 | 81 |

82 | 83 | ### Implementation 84 | 85 | https://github.com/ampleforth/ampleforth-contracts/pull/226 86 | 87 | ### Test Cases 88 | 89 | Existing unit tests will be updated with the correct calculation results to maintain test coverage. 90 | 91 | ## Conclusions 92 | 93 | The Ampleforth protocol will maintain the same nature to change supply to match demand. And the new curve would allow further improvements by changing the sigmoid parameters, which is independent from this AIP.

94 | -------------------------------------------------------------------------------- /AIPs/aip-6.md: -------------------------------------------------------------------------------- 1 | --- 2 | aip: 6 3 | title: Additional interface methods to the token and policy 4 | author: Nithin Krishna (@nithinkrishna) 5 | discussions-to: https://github.com/ampleforth/AIPs/issues/31 6 | status: Implemented 7 | created: 2021-1-26 8 | --- 9 | 10 | ## Summary 11 | 12 | The following additions to Ampleforth ERC20 and policy smart contracts are proposed. 13 | 14 | * Elastic token interface methods `scaledBalanceOf`, `scaledTotalSupply`, `transferAll` and `transferAllFrom`. [#180](https://github.com/ampleforth/uFragments/pull/180), [#187](https://github.com/ampleforth/uFragments/pull/187) 15 | * Support for `permit` EIP-2612 (gasless approvals) [#181](https://github.com/ampleforth/uFragments/pull/181) 16 | * A convenience function (`globalAmpleforthEpochAndAMPLSupply`) on the policy contract for multi-chain integration [#190](https://github.com/ampleforth/uFragments/pull/190) [#189](https://github.com/ampleforth/uFragments/pull/189) 17 | * Minor gas optimizations [#186](https://github.com/ampleforth/uFragments/pull/186), [#182](https://github.com/ampleforth/uFragments/pull/182) 18 | 19 |
20 | 21 | ## Test Cases 22 | 23 | Unit tests have been added to test the additions. 24 | 25 | `scaledBalanceOf`, `scaledTotalSupply` and `globalAmpleforthEpochAndAMPLSupply` do not modify any smart contract state. 26 | 27 | The `permit` implementation is identical to existing audited implementations on the Aave's [AToken](https://github.com/ampleforth/protocol-v2/blob/master/contracts/protocol/tokenization/AToken.sol#L268) and [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/drafts/ERC20PermitUpgradeable.sol). 28 | 29 | `transferAll` and `transferAllFrom` are identical to the existing implementations of `transfer` and `transferFrom` on the AMPL ERC-20 token. 30 | 31 |
32 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | aips.ampleforth.org 2 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | 3 | # Hello! This is where you manage which Jekyll version is used to run. 4 | # When you want to use a different version, change it below, save the 5 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so: 6 | # 7 | # bundle exec jekyll serve 8 | # 9 | # This will help ensure the proper Jekyll version is running. 10 | # Happy Jekylling! 11 | gem "jekyll", "~> 3.9.0" 12 | 13 | # This is the default theme for new Jekyll sites. You may change this to anything you like. 14 | gem "minima", "~> 2.5.1" 15 | 16 | # If you want to use GitHub Pages, remove the "gem "jekyll"" above and 17 | # uncomment the line below. To upgrade, run `bundle update github-pages`. 18 | # gem "github-pages", group: :jekyll_plugins 19 | #gem "github-pages", "~> 208", group: :jekyll_plugins 20 | 21 | # If you have any plugins, put them here! 22 | group :jekyll_plugins do 23 | gem "jekyll-feed", "~> 0.15.0" 24 | end 25 | 26 | # Windows does not include zoneinfo files, so bundle the tzinfo-data gem 27 | # and associated library. 28 | install_if -> { RUBY_PLATFORM =~ %r!mingw|mswin|java! } do 29 | gem "tzinfo", "~> 1.2" 30 | gem "tzinfo-data" 31 | end 32 | 33 | # Performance-booster for watching directories on Windows 34 | gem "wdm", "~> 0.1.0", :install_if => Gem.win_platform? 35 | 36 | gem "html-proofer", '>=3.3.1' 37 | 38 | # kramdown v2 ships without the gfm parser by default. If you're using 39 | # kramdown v1, comment out this line. 40 | gem "kramdown-parser-gfm" 41 | -------------------------------------------------------------------------------- /Gemfile.lock: -------------------------------------------------------------------------------- 1 | GEM 2 | remote: https://rubygems.org/ 3 | specs: 4 | addressable (2.8.1) 5 | public_suffix (>= 2.0.2, < 6.0) 6 | async (2.2.1) 7 | console (~> 1.10) 8 | io-event (~> 1.1.0) 9 | timers (~> 4.1) 10 | colorator (1.1.0) 11 | concurrent-ruby (1.1.7) 12 | console (1.16.2) 13 | fiber-local 14 | em-websocket (0.5.2) 15 | eventmachine (>= 0.12.9) 16 | http_parser.rb (~> 0.6.0) 17 | ethon (0.12.0) 18 | ffi (>= 1.3.0) 19 | eventmachine (1.2.7) 20 | ffi (1.13.1) 21 | fiber-local (1.0.0) 22 | forwardable-extended (2.6.0) 23 | html-proofer (5.0.0) 24 | addressable (~> 2.3) 25 | async (~> 2.1) 26 | nokogiri (~> 1.13) 27 | rainbow (~> 3.0) 28 | typhoeus (~> 1.3) 29 | yell (~> 2.0) 30 | zeitwerk (~> 2.5) 31 | http_parser.rb (0.6.0) 32 | i18n (0.9.5) 33 | concurrent-ruby (~> 1.0) 34 | io-event (1.1.2) 35 | jekyll (3.9.2) 36 | addressable (~> 2.4) 37 | colorator (~> 1.0) 38 | em-websocket (~> 0.5) 39 | i18n (~> 0.7) 40 | jekyll-sass-converter (~> 1.0) 41 | jekyll-watch (~> 2.0) 42 | kramdown (>= 1.17, < 3) 43 | liquid (~> 4.0) 44 | mercenary (~> 0.3.3) 45 | pathutil (~> 0.9) 46 | rouge (>= 1.7, < 4) 47 | safe_yaml (~> 1.0) 48 | jekyll-feed (0.15.1) 49 | jekyll (>= 3.7, < 5.0) 50 | jekyll-sass-converter (1.5.2) 51 | sass (~> 3.4) 52 | jekyll-seo-tag (2.6.1) 53 | jekyll (>= 3.3, < 5.0) 54 | jekyll-watch (2.2.1) 55 | listen (~> 3.0) 56 | kramdown (2.3.1) 57 | rexml 58 | kramdown-parser-gfm (1.1.0) 59 | kramdown (~> 2.0) 60 | liquid (4.0.3) 61 | listen (3.7.1) 62 | rb-fsevent (~> 0.10, >= 0.10.3) 63 | rb-inotify (~> 0.9, >= 0.9.10) 64 | mercenary (0.3.6) 65 | mini_portile2 (2.8.0) 66 | minima (2.5.1) 67 | jekyll (>= 3.5, < 5.0) 68 | jekyll-feed (~> 0.9) 69 | jekyll-seo-tag (~> 2.1) 70 | nokogiri (1.13.9) 71 | mini_portile2 (~> 2.8.0) 72 | racc (~> 1.4) 73 | pathutil (0.16.2) 74 | forwardable-extended (~> 2.6) 75 | public_suffix (4.0.6) 76 | racc (1.6.0) 77 | rainbow (3.0.0) 78 | rb-fsevent (0.10.4) 79 | rb-inotify (0.10.1) 80 | ffi (~> 1.0) 81 | rexml (3.2.5) 82 | rouge (3.23.0) 83 | safe_yaml (1.0.5) 84 | sass (3.7.4) 85 | sass-listen (~> 4.0.0) 86 | sass-listen (4.0.0) 87 | rb-fsevent (~> 0.9, >= 0.9.4) 88 | rb-inotify (~> 0.9, >= 0.9.7) 89 | thread_safe (0.3.6) 90 | timers (4.3.5) 91 | typhoeus (1.4.0) 92 | ethon (>= 0.9.0) 93 | tzinfo (1.2.10) 94 | thread_safe (~> 0.1) 95 | tzinfo-data (1.2020.1) 96 | tzinfo (>= 1.0.0) 97 | wdm (0.1.1) 98 | yell (2.2.2) 99 | zeitwerk (2.6.1) 100 | 101 | PLATFORMS 102 | ruby 103 | 104 | DEPENDENCIES 105 | html-proofer (>= 3.3.1) 106 | jekyll (~> 3.9.0) 107 | jekyll-feed (~> 0.15.0) 108 | kramdown-parser-gfm 109 | minima (~> 2.5.1) 110 | tzinfo (~> 1.2) 111 | tzinfo-data 112 | wdm (~> 0.1.0) 113 | 114 | BUNDLED WITH 115 | 2.1.4 116 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # AIPs 2 | Ampleforth Improvement Proposals (AIPs) describe standards for the Ampleforth platform, including core protocol specifications, client APIs, and contract standards. 3 | 4 | WIP: A browsable version of all current and draft AIPs can be found on [the official AIP site](https://aips.ampleforth.org/). 5 | 6 | # Contributing 7 | 8 | 1. Review [AIP-1](AIPs/aip-1.md). 9 | 2. Fork the repository by clicking "Fork" in the top right. 10 | 3. Add your AIP to your fork of the repository. There is a [template AIP here](aip-X.md). 11 | 4. Submit a Pull Request to Ampleforth's [AIPs repository](https://github.com/ampleforth/AIPs). 12 | 13 | Your first PR should be a first draft of the final AIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new AIP and assign it a number before merging it. Make sure you include a `discussions-to` header with the URL to a new thread on [ampltalk.org](https://ampltalk.org) where people can discuss the AIP as a whole. 14 | 15 | If your AIP requires images, the image files should be included in a subdirectory of the `assets` folder for that AIP as follow: `assets/aip-X` (for aip **X**). When linking to an image in the AIP, use relative links such as `../assets/aip-X/image.png`. 16 | 17 | When you believe your AIP is mature and ready to progress past the WIP phase, you should ask to have your issue added to the next governance call where it can be discussed for inclusion in a future platform upgrade. If the community agrees to include it, the AIP editors will update the state of your AIP to 'Approved'. 18 | 19 | # AIP Statuses 20 | 21 | * **WIP** - a AIP that is still being developed. 22 | * **Proposed** - a AIP that is ready to be reviewed in a governance call. 23 | * **Approved** - a AIP that has been accepted for implementation by the Ampleforth community. 24 | * **Implemented** - a AIP that has been released to mainnet. 25 | * **Rejected** - a AIP that has been rejected. 26 | 27 | 28 | # Validation (WIP) 29 | 30 | AIPs must pass some validation tests. The AIP repository ensures this by running tests using [html-proofer](https://rubygems.org/gems/html-proofer) and [aip_validator](https://rubygems.org/gems/aip_validator). 31 | 32 | It is possible to run the AIP validator locally: 33 | ``` 34 | gem install aip_validator 35 | aip_validator 36 | ``` 37 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | # Welcome to Jekyll! 2 | # 3 | # This config file is meant for settings that affect your whole blog, values 4 | # which you are expected to set up once and rarely edit after that. If you find 5 | # yourself editing this file very often, consider using Jekyll's data files 6 | # feature for the data you need to update frequently. 7 | # 8 | # For technical reasons, this file is *NOT* reloaded automatically when you use 9 | # 'bundle exec jekyll serve'. If you change this file, please restart the server process. 10 | 11 | # Site settings 12 | # These are used to personalize your new site. If you look in the HTML files, 13 | # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on. 14 | # You can create any custom variable you would like, and they will be accessible 15 | # in the templates via {{ site.myvariable }}. 16 | # title: Your awesome title 17 | # email: your-email@example.com 18 | description: >- 19 | Ampleforth Improvement Proposals (AIPs) describe standards for the Ampleforth 20 | platform, including core protocol specifications, client APIs, and supporting 21 | applications. 22 | url: "https://aips.ampleforth.org" 23 | repository: ampleforth/AIPs 24 | twitter_username: "AmpleforthOrg" 25 | github_username: Ampleforth 26 | header_pages: 27 | - all-aip.html 28 | - all-accp.html 29 | twitter: 30 | card: summary 31 | username: "AmpleforthOrg" 32 | 33 | # Build settings 34 | markdown: kramdown 35 | theme: minima 36 | plugins: 37 | - jekyll-seo-tag 38 | # - jekyll-feed 39 | 40 | permalink: /:slug 41 | 42 | defaults: 43 | - scope: 44 | path: "AIPs" 45 | values: 46 | layout: "aip" 47 | - scope: 48 | path: "ACCP" 49 | values: 50 | layout: "accp" 51 | 52 | exclude: 53 | - Gemfile 54 | - Gemfile.lock 55 | - node_modules 56 | - vendor/bundle/ 57 | - vendor/cache/ 58 | - vendor/gems/ 59 | - vendor/ruby/ 60 | - accp-X.md 61 | - aip-X.md 62 | 63 | # Exclude from processing. 64 | # The following items will not be processed, by default. Create a custom list 65 | # to override the default setting. 66 | # exclude: 67 | # - Gemfile 68 | # - Gemfile.lock 69 | # - node_modules 70 | # - vendor/bundle/ 71 | # - vendor/cache/ 72 | # - vendor/gems/ 73 | # - vendor/ruby/ 74 | -------------------------------------------------------------------------------- /_data/statuses.yaml: -------------------------------------------------------------------------------- 1 | - WIP 2 | - Proposed 3 | - Approved 4 | - Implemented 5 | - Rejected -------------------------------------------------------------------------------- /_includes/accpnums.html: -------------------------------------------------------------------------------- 1 | {% assign accp=include.accp|split:"," %} 2 | {% for accpnum in accp %} 3 | {% if accpnum contains 'AIP' %} 4 | {{accpnum|strip}}{% if forloop.last == false %}, {% endif %} 5 | {% else %} 6 | {{accpnum|strip}}{% if forloop.last == false %}, {% endif %} 7 | {% endif %} 8 | {% endfor %} 9 | -------------------------------------------------------------------------------- /_includes/accptable.html: -------------------------------------------------------------------------------- 1 | 10 | {% for status in site.data.statuses %} 11 | {% assign accp = include.accp|where:"status",status|sort:"accp" %} 12 | {% assign count = accp|size %} 13 | {% if count > 0 %} 14 |

{{status}}

15 | 16 | 17 | 18 | 19 | {% for page in accp %} 20 | 21 | 22 | 23 | 24 | 25 | {% endfor %} 26 |
NumberTitleAuthor
{{page.accp|xml_escape}}{{page.title|xml_escape}}{% include authorlist.html authors=page.author %}
27 | {% endif %} 28 | {% endfor %} 29 | -------------------------------------------------------------------------------- /_includes/aipnums.html: -------------------------------------------------------------------------------- 1 | {% assign aips=include.aips|split:"," %} 2 | {% for aipnum in aips %} 3 | {% if aipnum contains 'MCCP' %} 4 | {{aipnum|strip}}{% if forloop.last == false %}, {% endif %} 5 | {% else %} 6 | {{aipnum|strip}}{% if forloop.last == false %}, {% endif %} 7 | {% endif %} 8 | {% endfor %} 9 | -------------------------------------------------------------------------------- /_includes/aiptable.html: -------------------------------------------------------------------------------- 1 | 10 | {% for status in site.data.statuses %} 11 | {% assign aips = include.aips|where:"status",status|sort:"aip" %} 12 | {% assign count = aips|size %} 13 | {% if count > 0 %} 14 |

{{status}}

15 | 16 | 17 | 18 | 19 | {% for page in aips %} 20 | 21 | 22 | 23 | 24 | 25 | {% endfor %} 26 |
NumberTitleAuthor
{{page.aip|xml_escape}}{{page.title|xml_escape}}{% include authorlist.html authors=page.author %}
27 | {% endif %} 28 | {% endfor %} 29 | -------------------------------------------------------------------------------- /_includes/authorlist.html: -------------------------------------------------------------------------------- 1 | {%- assign authors=include.authors|split:"," -%} 2 | {%- for author in authors -%} 3 | {%- if author contains "<" -%} 4 | {%- assign authorparts=author|split:"<" -%} 5 | "}}">{{authorparts[0]|strip}} 6 | {%- elsif author contains "(@" -%} 7 | {%- assign authorparts=author|split:"(@" -%} 8 | {{authorparts[0]|strip}} 9 | {%- else -%} 10 | {{author}} 11 | {%- endif -%} 12 | {% if forloop.last == false %}, {% endif %} 13 | {%- endfor -%} 14 | -------------------------------------------------------------------------------- /_includes/head.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | {% if page.aip %}AIP-{{page.aip}}: {% elsif page.accp %}ACCP-{{page.accp}}: 7 | {% endif %}{% if page.title %}{{page.title }}{% else %}{{ site.homeMetaTitle 8 | }}{% endif %} 9 | 10 | {%- seo -%} 12 | 13 | {%- feed_meta -%} {%- if jekyll.environment == 'production' and 14 | site.google_analytics -%} {%- include google-analytics.html -%} {%- endif -%} 15 | 16 | -------------------------------------------------------------------------------- /_includes/social.html: -------------------------------------------------------------------------------- 1 | 15 | -------------------------------------------------------------------------------- /_layouts/accp.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 | 5 | 6 |
7 |

8 | ACCP {{ page.accp | xml_escape }}: {{ page.title | xml_escape }} 9 | Source 10 |

11 | 12 | 13 | {% if page["discussions-to"] != undefined %} 14 | 15 | {% endif %} 16 | 21 | {% if page.category != undefined %} 22 | 23 | {% endif %} 24 | 25 | {% if page.requires != undefined %} 26 | 27 | {% endif %} 28 | {% if page.replaces != undefined %} 29 | 30 | {% endif %} 31 | {% if page["superseded-by"] != undefined %} 32 | 33 | {% endif %} 34 | {% if page.resolution != undefined %} 35 | 36 | {% endif %} 37 |
Author{% include authorlist.html authors=page.author %}
Discussions-To{{ page["discussions-to"] | xml_escape }}
Status{{ page.status | xml_escape }} 17 | {% if page.review-period-end != undefined %} 18 | (review ends {{ page.review-period-end | xml_escape }}) 19 | {% endif %} 20 |
Category{{ page.category | xml_escape }}
Created{{ page.created | xml_escape }}
Requires{% include accpnums.html accp=page.requires %}
Replaces{% include accpnums.html accp=page.replaces %}
Superseded by{% include accpnums.html accp=page.superseded-by %}
Resolution{{ page.resolution | xml_escape }}
38 | 39 | {{ content }} 40 | 41 | 42 | 45 |
46 | -------------------------------------------------------------------------------- /_layouts/aip.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 | 5 | 6 |
7 |

8 | AIP {{ page.aip | xml_escape }}: {{ page.title | xml_escape }} 9 | Source 10 |

11 | 12 | 13 | {% if page["discussions-to"] != undefined %} 14 | 15 | {% endif %} 16 | 21 | {% if page.category != undefined %} 22 | 23 | {% endif %} 24 | 25 | {% if page.requires != undefined %} 26 | 27 | {% endif %} 28 | {% if page.replaces != undefined %} 29 | 30 | {% endif %} 31 | {% if page["superseded-by"] != undefined %} 32 | 33 | {% endif %} 34 | {% if page.resolution != undefined %} 35 | 36 | {% endif %} 37 |
Author{% include authorlist.html authors=page.author %}
Discussions-To{{ page["discussions-to"] | xml_escape }}
Status{{ page.status | xml_escape }} 17 | {% if page.review-period-end != undefined %} 18 | (review ends {{ page.review-period-end | xml_escape }}) 19 | {% endif %} 20 |
Category{{ page.category | xml_escape }}
Created{{ page.created | xml_escape }}
Requires{% include aipnums.html aips=page.requires %}
Replaces{% include aipnums.html aips=page.replaces %}
Superseded by{% include aipnums.html aips=page.superseded-by %}
Resolution{{ page.resolution | xml_escape }}
38 | 39 | {{ content }} 40 | 41 | 42 | 45 |
46 | -------------------------------------------------------------------------------- /accp-X.md: -------------------------------------------------------------------------------- 1 | --- 2 | accp: 3 | title: 4 | author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> 5 | discussions-to: 6 | status: WIP 7 | created: 8 | requires (*optional): 9 | --- 10 | 11 | 12 | This is the template for ACCPs. 13 | 14 | Note that an ACCP number will be assigned by an editor. When opening a pull request to submit your ACCP, please use an abbreviated title in the filename, `accp-draft_title_abbrev.md`. 15 | 16 | The title should be 44 characters or less. 17 | 18 | ## Simple Summary 19 | 20 | If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the ACCP. 21 | 22 | ## Abstract 23 | 24 | A short (~200 word) description of the variable change proposed. 25 | 26 | ## Motivation 27 | 28 | The motivation is critical for ACCPs that want to update variables within Ampleforth. It should clearly explain why the existing variable is not incentive aligned. ACCP submissions without sufficient motivation may be rejected outright. 29 | 30 | ## Copyright 31 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 32 | -------------------------------------------------------------------------------- /aip-X.md: -------------------------------------------------------------------------------- 1 | --- 2 | aip: 3 | title: 4 | author: ", FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>" 5 | discussions-to: 6 | status: WIP 7 | created: 8 | requires (*optional): 9 | --- 10 | 11 | 12 | 13 | This is the suggested template for new AIPs. Note that an AIP number will be assigned by an editor. When opening a pull request to submit your AIP, please use an abbreviated title in the filename, `aip-draft_title_abbrev.md`. The title should be 44 characters or less. 14 | 15 | ## Simple Summary 16 | 17 | "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. 18 | 19 | ## Abstract 20 | 21 | 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 AIP is implemented, not *why* it should be done or *how* it will be done. If the AIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x". 22 | 23 | ## Motivation 24 | 25 | This is the problem statement. This is the *why* of the AIP. 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 AIP 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 AIP will address the issue! 26 | 27 | ## Specification 28 | 35 | 36 | ### Overview 37 | 38 | This is a high level overview of *how* the AIP will solve the problem. The overview should clearly describe how the new feature will be implemented. 39 | 40 | ### Rationale 41 | 42 | 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. 43 | 44 | ### Technical Specification 45 | 46 | The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Ampleforth currently exposes or the creations of new ones. 47 | 48 | ### Test Cases 49 | 50 | Test cases for an implementation are mandatory for AIPs but can be included with the implementation. 51 | 52 | ## Copyright 53 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 54 | -------------------------------------------------------------------------------- /all-accp.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: All ACCPs 4 | --- 5 | 6 | {% assign accp=site.pages|where_exp:"page","page.accp > 0" %} {% include 7 | accptable.html accp=accp %} 8 | -------------------------------------------------------------------------------- /all-aip.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: All AIPs 4 | --- 5 | 6 | {% assign aips=site.pages|where_exp:"page","page.aip > 0" %} {% include 7 | aiptable.html aips=aips %} 8 | -------------------------------------------------------------------------------- /assets/additional-styles.css: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | // Give headings a little breathing room. 5 | h2, h3, h4, h5, h6 { margin-top: 25px; } 6 | 7 | .center-image 8 | { 9 | margin: 0 auto; 10 | display: block; 11 | } 12 | -------------------------------------------------------------------------------- /assets/aip-5/curves.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/assets/aip-5/curves.png -------------------------------------------------------------------------------- /assets/aip-5/formula.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/assets/aip-5/formula.png -------------------------------------------------------------------------------- /assets/aip-5/price_distribution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/assets/aip-5/price_distribution.png -------------------------------------------------------------------------------- /assets/aip-5/rebase_histogram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/assets/aip-5/rebase_histogram.png -------------------------------------------------------------------------------- /assets/aip-5/sigmoid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/assets/aip-5/sigmoid.png -------------------------------------------------------------------------------- /combined_latexchart_withdeviation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/combined_latexchart_withdeviation.png -------------------------------------------------------------------------------- /favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ampleforth/AIPs/717c6298d6a434876dcac1dee1b0a55467ea452e/favicon.ico -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Ampleforth Improvement Proposals 4 | --- 5 | 6 |

7 | Ampleforth Improvement Proposals (AIPs) and Configuration Change Proposals (ACCPs) 8 | Discord 10 | 11 |

12 |

13 | Ampleforth Improvement Proposals (AIPs) describe standards for the Ampleforth 14 | platform, including core protocol specifications, client APIs, and contract 15 | standards. 16 |

17 |

18 | Ampleforth Configuration Change Proposals(ACCPs) are similar to AIPs, but concern modifications to system configuration values such as equilibrium_threshold and the orchestrator transactions list. ACCPs live in the same repository and website as AIPs do, but have a slightly different specification. 19 |

20 | 21 |

Contributing

22 |
    23 |
  1. Review AIP-1 or ACCP-1.
    2. 24 |
  2. Fork the repository by clicking "Fork" in the top right.
    3. 25 |
  3. 26 | Add your document to your fork of the repository. There is a template 27 | AIP 28 | and ACCP. 29 |
    4. 30 |
  4. 31 | Submit a Pull Request to Ampleforth's 32 | AIPs repository. 33 |
    5. 34 |
35 | 36 |

37 | Your first PR (Pull Request) should be a first draft of the final AIP. It must meet the 38 | formatting criteria enforced by the build (largely, correct metadata in the 39 | header). An editor will manually review the first PR for a new AIP and assign 40 | it a number before merging it. Make sure you include a 41 | discussions-to header with the URL to a discussion forum or open 42 | GitHub issue where people can discuss the AIP as a whole. 43 |

44 |

45 | If your AIP requires images, the image files should be included in a 46 | subdirectory of the `assets` folder for that AIP as follow: 47 | assets/aip-X (for aip X). When linking to an image in the 48 | AIP, use relative links such as ../assets/aip-X/image.png. 49 |

50 |

51 | When you believe your AIP is mature and ready to progress past the WIP phase, 52 | you should ask to have your issue added to the next governance call where it 53 | can be discussed for inclusion in a future platform upgrade. If the community 54 | agrees to include it, the AIP editors will update the state of your AIP to 55 | Approved. 56 |

57 | 58 |

AIP status terms

59 |
    60 |
  • WIP - a AIP that is still being developed.
    • 61 |
  • 62 | Proposed - a AIP that is ready to be reviewed in a 63 | governance call. 64 |
    • 65 |
  • 66 | Approved - a AIP that has been accepted for implementation 67 | by the Ampleforth community. 68 |
    • 69 |
  • 70 | Implemented - a AIP that has been released to mainnet. 71 |
    • 72 |
  • Rejected - a AIP that has been rejected.
    • 73 |
74 | -------------------------------------------------------------------------------- /last-call.xml: -------------------------------------------------------------------------------- 1 | --- 2 | layout: null 3 | --- 4 | 5 | 6 | 7 | Ampleforth AIPs Last Call Review 8 | All aips which are in the two-week "last call" status, please help review these and provide your feedback! 9 | {{ site.url }} 10 | 11 | {{ site.time }} 12 | {% assign aips = site.pages | sort: 'aip' %} 13 | {% for aip in aips %} 14 | {% if aip.status == "Last Call" %} 15 | {% capture description %} 16 |

aip #{{ aip.aip }} - {{aip.title }} is in Last Call status. It is authored by {{ aip.author }} and was originally created {{ aip.created }}. It is in the {{ aip.category }} category of type {{ aip.type }}. Please review and note any changes that should block acceptance.

17 | {% if aip.discussions-to %} 18 |

The author has requested that discussions happen at the following URL: {{ aip.discussions-to }}

19 | {% else %} 20 |

Please visit the [Ampleforth/aips issues to comment](https://github.com/Ampleforth/aips/issues/{{aip.aip}}).

21 | {% endif %} 22 |
23 | {{ aip.content }} 24 | {% endcapture %} 25 | 26 | {{ aip.title | xml_escape }} 27 | {{ description | xml_escape }} 28 | {{ aip.date | date: "%a, %d %b %Y %H:%M:%S %z" }} 29 | {{ site.url }}/{{ aip.url }} 30 | {{ site.url }}/{{ aip.url }} 31 | 32 | {% endif %} 33 | {% endfor %} 34 | 35 | 36 | -------------------------------------------------------------------------------- /mathjax-config.js: -------------------------------------------------------------------------------- 1 | MathJax = { 2 | tex: { 3 | inlineMath: [['\\(', '\\)']], 4 | displayMath: [['\\[', '\\]']] 5 | }, 6 | svg: { 7 | fontCache: 'global' 8 | } 9 | }; -------------------------------------------------------------------------------- /test-jekyll/.gitignore: -------------------------------------------------------------------------------- 1 | _site 2 | .sass-cache 3 | .jekyll-cache 4 | .jekyll-metadata 5 | vendor 6 | -------------------------------------------------------------------------------- /test-jekyll/404.html: -------------------------------------------------------------------------------- 1 | --- 2 | permalink: /404.html 3 | layout: default 4 | --- 5 | 6 | 19 | 20 |
21 |

404

22 | 23 |

Page not found :(

24 |

The requested page could not be found.

25 |
26 | -------------------------------------------------------------------------------- /test-jekyll/Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | # Hello! This is where you manage which Jekyll version is used to run. 3 | # When you want to use a different version, change it below, save the 4 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so: 5 | # 6 | # bundle exec jekyll serve 7 | # 8 | # This will help ensure the proper Jekyll version is running. 9 | # Happy Jekylling! 10 | gem "jekyll", "~> 4.1.1" 11 | # This is the default theme for new Jekyll sites. You may change this to anything you like. 12 | gem "minima", "~> 2.5" 13 | # If you want to use GitHub Pages, remove the "gem "jekyll"" above and 14 | # uncomment the line below. To upgrade, run `bundle update github-pages`. 15 | # gem "github-pages", group: :jekyll_plugins 16 | # If you have any plugins, put them here! 17 | group :jekyll_plugins do 18 | gem "jekyll-feed", "~> 0.12" 19 | end 20 | 21 | # Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem 22 | # and associated library. 23 | platforms :mingw, :x64_mingw, :mswin, :jruby do 24 | gem "tzinfo", "~> 1.2" 25 | gem "tzinfo-data" 26 | end 27 | 28 | # Performance-booster for watching directories on Windows 29 | gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin] 30 | 31 | -------------------------------------------------------------------------------- /test-jekyll/Gemfile.lock: -------------------------------------------------------------------------------- 1 | GEM 2 | remote: https://rubygems.org/ 3 | specs: 4 | addressable (2.8.0) 5 | public_suffix (>= 2.0.2, < 5.0) 6 | colorator (1.1.0) 7 | concurrent-ruby (1.1.7) 8 | em-websocket (0.5.2) 9 | eventmachine (>= 0.12.9) 10 | http_parser.rb (~> 0.6.0) 11 | eventmachine (1.2.7) 12 | ffi (1.13.1) 13 | forwardable-extended (2.6.0) 14 | http_parser.rb (0.6.0) 15 | i18n (1.8.5) 16 | concurrent-ruby (~> 1.0) 17 | jekyll (4.1.1) 18 | addressable (~> 2.4) 19 | colorator (~> 1.0) 20 | em-websocket (~> 0.5) 21 | i18n (~> 1.0) 22 | jekyll-sass-converter (~> 2.0) 23 | jekyll-watch (~> 2.0) 24 | kramdown (~> 2.1) 25 | kramdown-parser-gfm (~> 1.0) 26 | liquid (~> 4.0) 27 | mercenary (~> 0.4.0) 28 | pathutil (~> 0.9) 29 | rouge (~> 3.0) 30 | safe_yaml (~> 1.0) 31 | terminal-table (~> 1.8) 32 | jekyll-feed (0.15.1) 33 | jekyll (>= 3.7, < 5.0) 34 | jekyll-sass-converter (2.1.0) 35 | sassc (> 2.0.1, < 3.0) 36 | jekyll-seo-tag (2.6.1) 37 | jekyll (>= 3.3, < 5.0) 38 | jekyll-watch (2.2.1) 39 | listen (~> 3.0) 40 | kramdown (2.3.1) 41 | rexml 42 | kramdown-parser-gfm (1.1.0) 43 | kramdown (~> 2.0) 44 | liquid (4.0.3) 45 | listen (3.2.1) 46 | rb-fsevent (~> 0.10, >= 0.10.3) 47 | rb-inotify (~> 0.9, >= 0.9.10) 48 | mercenary (0.4.0) 49 | minima (2.5.1) 50 | jekyll (>= 3.5, < 5.0) 51 | jekyll-feed (~> 0.9) 52 | jekyll-seo-tag (~> 2.1) 53 | pathutil (0.16.2) 54 | forwardable-extended (~> 2.6) 55 | public_suffix (4.0.6) 56 | rb-fsevent (0.10.4) 57 | rb-inotify (0.10.1) 58 | ffi (~> 1.0) 59 | rexml (3.2.5) 60 | rouge (3.23.0) 61 | safe_yaml (1.0.5) 62 | sassc (2.4.0) 63 | ffi (~> 1.9) 64 | terminal-table (1.8.0) 65 | unicode-display_width (~> 1.1, >= 1.1.1) 66 | unicode-display_width (1.7.0) 67 | 68 | PLATFORMS 69 | ruby 70 | 71 | DEPENDENCIES 72 | jekyll (~> 4.1.1) 73 | jekyll-feed (~> 0.12) 74 | minima (~> 2.5) 75 | tzinfo (~> 1.2) 76 | tzinfo-data 77 | wdm (~> 0.1.1) 78 | 79 | BUNDLED WITH 80 | 2.1.4 81 | -------------------------------------------------------------------------------- /test-jekyll/_config.yml: -------------------------------------------------------------------------------- 1 | # Welcome to Jekyll! 2 | # 3 | # This config file is meant for settings that affect your whole blog, values 4 | # which you are expected to set up once and rarely edit after that. If you find 5 | # yourself editing this file very often, consider using Jekyll's data files 6 | # feature for the data you need to update frequently. 7 | # 8 | # For technical reasons, this file is *NOT* reloaded automatically when you use 9 | # 'bundle exec jekyll serve'. If you change this file, please restart the server process. 10 | # 11 | # If you need help with YAML syntax, here are some quick references for you: 12 | # https://learn-the-web.algonquindesign.ca/topics/markdown-yaml-cheat-sheet/#yaml 13 | # https://learnxinyminutes.com/docs/yaml/ 14 | # 15 | # Site settings 16 | # These are used to personalize your new site. If you look in the HTML files, 17 | # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on. 18 | # You can create any custom variable you would like, and they will be accessible 19 | # in the templates via {{ site.myvariable }}. 20 | 21 | title: Your awesome title 22 | email: your-email@example.com 23 | description: >- # this means to ignore newlines until "baseurl:" 24 | Write an awesome description for your new site here. You can edit this 25 | line in _config.yml. It will appear in your document head meta (for 26 | Google search results) and in your feed.xml site description. 27 | baseurl: "" # the subpath of your site, e.g. /blog 28 | url: "" # the base hostname & protocol for your site, e.g. http://example.com 29 | twitter_username: jekyllrb 30 | github_username: jekyll 31 | 32 | # Build settings 33 | theme: minima 34 | plugins: 35 | - jekyll-feed 36 | 37 | # Exclude from processing. 38 | # The following items will not be processed, by default. 39 | # Any item listed under the `exclude:` key here will be automatically added to 40 | # the internal "default list". 41 | # 42 | # Excluded items can be processed by explicitly listing the directories or 43 | # their entries' file path in the `include:` list. 44 | # 45 | # exclude: 46 | # - .sass-cache/ 47 | # - .jekyll-cache/ 48 | # - gemfiles/ 49 | # - Gemfile 50 | # - Gemfile.lock 51 | # - node_modules/ 52 | # - vendor/bundle/ 53 | # - vendor/cache/ 54 | # - vendor/gems/ 55 | # - vendor/ruby/ 56 | -------------------------------------------------------------------------------- /test-jekyll/_posts/2020-10-07-welcome-to-jekyll.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: "Welcome to Jekyll!" 4 | date: 2020-10-07 10:46:41 -0700 5 | categories: jekyll update 6 | --- 7 | You’ll find this post in your `_posts` directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run `jekyll serve`, which launches a web server and auto-regenerates your site when a file is updated. 8 | 9 | Jekyll requires blog post files to be named according to the following format: 10 | 11 | `YEAR-MONTH-DAY-title.MARKUP` 12 | 13 | Where `YEAR` is a four-digit number, `MONTH` and `DAY` are both two-digit numbers, and `MARKUP` is the file extension representing the format used in the file. After that, include the necessary front matter. Take a look at the source for this post to get an idea about how it works. 14 | 15 | Jekyll also offers powerful support for code snippets: 16 | 17 | {% highlight ruby %} 18 | def print_hi(name) 19 | puts "Hi, #{name}" 20 | end 21 | print_hi('Tom') 22 | #=> prints 'Hi, Tom' to STDOUT. 23 | {% endhighlight %} 24 | 25 | Check out the [Jekyll docs][jekyll-docs] for more info on how to get the most out of Jekyll. File all bugs/feature requests at [Jekyll’s GitHub repo][jekyll-gh]. If you have questions, you can ask them on [Jekyll Talk][jekyll-talk]. 26 | 27 | [jekyll-docs]: https://jekyllrb.com/docs/home 28 | [jekyll-gh]: https://github.com/jekyll/jekyll 29 | [jekyll-talk]: https://talk.jekyllrb.com/ 30 | -------------------------------------------------------------------------------- /test-jekyll/about.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: About 4 | permalink: /about/ 5 | --- 6 | 7 | This is the base Jekyll theme. You can find out more info about customizing your Jekyll theme, as well as basic Jekyll usage documentation at [jekyllrb.com](https://jekyllrb.com/) 8 | 9 | You can find the source code for Minima at GitHub: 10 | [jekyll][jekyll-organization] / 11 | [minima](https://github.com/jekyll/minima) 12 | 13 | You can find the source code for Jekyll at GitHub: 14 | [jekyll][jekyll-organization] / 15 | [jekyll](https://github.com/jekyll/jekyll) 16 | 17 | 18 | [jekyll-organization]: https://github.com/jekyll 19 | -------------------------------------------------------------------------------- /test-jekyll/index.markdown: -------------------------------------------------------------------------------- 1 | --- 2 | # Feel free to add content and custom Front Matter to this file. 3 | # To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults 4 | 5 | layout: home 6 | --- 7 | --------------------------------------------------------------------------------