The purpose of Ampleforth is to obtain a token with a constant value, and to do this, the algorithm autonomously modifies the supply of tokens.

Step back

To better understand the intentions of the Ampleforth project, it is necessary to do a very brief review of the "history" of money.
As we all know, the first coins that were made for trade were coins which, obtained from precious metals, had an intrinsic value, i.e. the value of the coin corresponded to the quantity of precious metal of which the coin was made.
Subsequently, to limit counterfeiting, we came to paper money, whose nominal value was not linked to the material with which it was made but the value was defined by the various states.
It should be noted, however, that although paper money had a value separated from intrinsic value (hence non-commercial money), the total value of the coins in circulation was equal to the underlying precious metal kept in central banks.
We have to wait until 1971 when the fiat currency (so called because the reported value is used on the “trust” of governments) is separated from the underlying in precious metals.
Since then, inflation has made its appearance.

The concept.

Suppose Jenny owns 1 Ampl worth $ 1.
The demand increases and little by little Jenny finds herself always having 1 Ampl, but with a value equal to $ 2.
But if we wanted to keep the Token price constant how should we do?
Simple, increasing the supply; therefore:
Jenny will have 2 Ampls worth $ 1 each. So Jenny's capital didn't change.
That said, it's very simple, let's go deeper into the discussion.
We assume the variable Pt which indicates the price we want to keep constant, and the price range with Delta.
If we have that the value of Ampl is major of Pt plus Delta, then the algorithm increases the number of tokens in order to bring the value back to the predetermined target.
If we have that the value of Ampl is minor of Pt minus Delta, then the algorithm decreases the number of Tokens.
Let's say it's a kind of burn in the same way Dextoken applies it to keep volatility within a certain limit.
The protocol performs these corrections them only once a day.

Let's observe now the process with the agile mind of the Trader:
We said that Jenny has 1 Ample worth $ 2, the protocol activates the correction and Jenny has 2 Ampl worth $ 1 in her Wallet. Let's imagine that Jenny is an infallible Trader: as soon as she realizes she has more coins of equal value what could she do?
That's right, SELLS!
In this way, in addition to the protocol, to bring the system into balance there are also the users of the token, as long as they are Traders!
Let's see the situation in case the Ample value drops to 0.5. In this case Jenny will no longer have 1 Ampl worth $ 0.5, but 0.5 Ample worth $ 0.5.
Therefore?
BUY !!!
Buy at half the price and by increasing the demand it helps the protocol to recreate the equilibrium situation.
Let's go even deeper into the concept.
We call P the price per unit, with S the number of units in circulation and M the market capitalization. It follows that:
M = P x S.

Let's take the figure above:
Expanding market capitalization, given a fixed amount of Ampl, implies that the price goes up.
Through the appropriate adjustments, the protocol keeps the M1 capitalization in equilibrium, up to the peak O, after which the algorithm within 24 hours restores the equilibrium up to M2.
The observation on capitalization is necessary: if a user takes as a reference only the price, he notices a symmetry and fails to exploit the opportunity; while if you look at the capitalization more generally, a shrewd trader is able to capitalize on this price jump within 24 hours (the time it takes for the protocol to make the changes)
In practice, near O, when the algorithm changes the amount of owned tokens, the trader sells, to buy back when the processes have lowered the price to reach M2.
In this way, the capitalization of the token is best exploited.
With the same principle, the contraction on market capitalization can also be exploited.
As we can see in the following image, the capitalization has undergone a decline up to point O.
In the same way, as with expansion, the protocol cancels the tokens to bring them to the value of 1.
If a trader is very careful, instead of selling he will have to buy; in fact, it will purchase at a lower price and therefore will total more tokens at the end of the operation.
For the functioning of the protocol, the team has prepared 3 smart contracts that manage 3 very specific functions.
All smart contracts are built on Ethereum's Blockchain, and they are
1 - The Ampleforth ERC-20 token;
2 - The contract with the market oracles for the on-chain transfer of the token price;
3 - The supply contract.

1 - The smart-contract that manages the ERC-20 Ampleforth token has a specific procedure, which is called rebase (uint256 epoch, int256 supplyDelta); this function enables, only according to what is defined by the smart-contract of the supply, the variation of the supply of tokens both in times of expansion (increase in price, which corresponds to the increase in supply) and in times of contraction (decrease of the price, corresponds to a decrease in the supply).
Note that the balancing operations are not performed one for each leaflet.

2 - As regards the interface of the oracle designed to find the off-chain price, in order to transfer the data on-chain it must comply with these 3 rules:

1 - a whitelist of the sites where the price value can be found;
2 - The procurement policy can only be based on a market report published in the chain for at least 1 hour;
3 - A market report will expire in chain if none are published within 6 hours.

3 - smart-contract for supply, or rather supply management.
This Smart-contract has an external function - Rebase - not to be confused with the ERC-20 Ampleforth token function.
This rebase () method is publicly callable by anyone, but it will run at most once every 24 hours. Opening this method helps to remove us as a necessary core part in running the system. If we fail to call rebase () for any reason, others are free to make that call for us.
The rebase () method first queries Market Oracle to get the current price. If the price is within the priceThreshold of the target price, no change to the bid policy is applied. Otherwise, the absolute SupplyDelta is equal to (price-target) * totalSupply / target. For example, if Amples is trading for $ 1.15, the absolute increase in total supply will be 15%.
Next, apply a "rebase reaction delay" to dampen the change in supply. At launch, the reaction delay will be 30 days.

how do you say where is my meme? There he is!!!