Ben Bernanke is an American economist, who’s work on monetary policy and macroeconomics earned him positions as a professor of Economics at Princeton, Stanford, and MIT, as well as led him to become Chairman of the Federal Reserve from 2006 to 2014. He was tasked with navigating the housing crisis and recession of 2008, a task which many experts believe he performed well.
The 2008 banking crisis led to a lack of confidence in the banking system as a whole, but Beranke’s aggressive and largely experimental approach to the crisis helped restore confidence to the financial system, as seen by the longest expansionary market in US history following the crisis. One of Bernanke’s most notable moves was to slash the interest rates to almost 0%, allowing banks to lend to each other and customers at lower rates, stimulating the economy.
Besides his policy moves, Bernanke made a highly controversial decision to bail out a few of the huge financial institutions that were about to go bankrupt during the crisis, fearing their failure would only serve to worsen the crisis. For example, the Fed incentivized companies like JP Morgan to take control of Bear Stearns or Merrill Lynch. Bernanke wrote about how close the global economy came to collapsing in his 2015 book, which would have occurred if not for the Fed’s moves. However, contrarians believe Bernanke should have foreseen the crisis and is in part responsible for the events. Overall, Bernanke was the most influential person in the US during the crisis due to his control over Fed policies, which is a place that naturally brings critics.
Bernake's control over Fed policy highlights the room for interpretation created with a discretion based monetary policy. With the housing crisis, people and policy makers showed that it is very possible for those in charge to miss markers that point towards the downfall of a market and it is very clear that they can fail to act in time to prevent or reduce the impact of downswings. With Ampleforth, the protocol acts on market forces in a rules based format, removing the likelihood of human emotion, biases, and political alignment in times of crisis. Rules based systems are not without their challenges. However, if a rules based system like Bitcoin or Ampleforth were used as a globally prior to 2008 the great recession may have played out much differently.
A key element to how Ampleforth’s unique protocol functions is the supply rebase. The supply rebase is something that happens every 24 hours for the $AMPL token. Once a day, tokens are equally distributed to all wallets, or equally taken away from all wallets in direct response to the token's trading price activity over the previous 24 hours.
With the launch and listing of Ampleforth, we are approaching the very first supply rebase event - this rebase will occur on Sunday, June 30th at 8pm UTC. Tokens will either expand for all holders, or contract, based on the price of $AMPL. To better understand how the expansion and contraction works with Ampleforth, please read the Red Book, in particular chapter 1.6 which you can find here. For the first rebase, there are two special considerations. First, the volume weighted average price (VWAP) is based off of the previous 72 hours for the first supply rebase only. Be sure your contest entries reflect the prior 72 hour time period as the contest falls under this unique circumstance. Second, CPI which provides the equilibrium price target is shifting during this 72 hour period. Be sure to take into account the minor adjustment in equilibrium price target to make your guess as precise as possible.
This contest is for the most accurate guess of how many tokens are distributed to a holder if he or she hypothetically held 10,000 AMPL at the time of rebase.
So what exactly is the supply rebase and how does it function?
Ampleforth’s tokens, which are called Amples (Symbol $AMPL) are volatile in both priceANDsupply. Amples are free to fluctuate in price every as a result of the trading that takes place on the open market. However, Ampleforth has an equilibrium price target. Initially, that equilibrium price target is $1 USD.
What if you are an AMPL holder in real life? How do you participate in the daily rebase event?
To participate in the rebase, if you hold your tokens on Bitfinex or Ethfinex, those exchanges will automatically distribute your AMPL to you. You don’t need to remove your AMPL from your exchange wallet on Bitfinex or Ethfinex. If you are on a centralized exchange that has not properly accounted for AMPL expansion and contraction, you run the risk of not receiving your AMPL during the supply rebase expansion.
If you hold your AMPL in a private wallet (for example MyEtherWallet - MEW) you will also automatically have your expansion accounted for.
Winner: 50 $AMPL
Each participant is allowed only one entry. You will be disqualified for multiple entries
Imagine you have 10,000 AMPL. This contest is to guess the number of AMPL you will have distributed to your wallet, or taken from your wallet after the first rebase event on Sunday June 30th at 8pm UTC. This number can be positive or negative.
Entries are made by composing a tweet and typing in the body of the tweet "$AMPL"
Ampleforth was created with the mission to create fair and politically independent money. We believe these two qualities mean, as much as possible, reducing or removing the discretion afforded to any individuals or special classes of users.
To that end, let’s look at where discretion exists in the Ampleforth protocol today, how it’s currently managed, and how that management could evolve with the community over time.
This post gets a bit technical in places. If you’re not familiar with the workings of the protocol, I recommend first reading the red book or whitepaper.
As a quick refresher, there are three main protocol modules:
There are a small handful of protected functions in Ampleforth, but there are two that should be highlighted first: setRebasePaused and setTokenPaused. These two functions are emergency controls on the token that guard balances in critical situations.
When rebase is paused, the supply of the token is frozen until rebase is unpaused. When this is active, the supply stays constant and Amples are still freely tradeable by anyone. This is to guard against unexpected problems in the supply policy or oracle system upstream of the token.
In the absolute worst-case scenario, setTokenPaused will pause all transfers on chain. This is meant to guard balances against unexpected problems in the token itself.
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.
However, equally important is what these can’t do. You’ll notice that pausing acts globally or not at all, and there are no tools that can target individual wallets. There’s no possible way to freeze or confiscate a specific user’s funds. This inability to single out tokens or wallets is by design and is a fundamental core of Ampleforth’s fair and independent money.
Going forward, as the system becomes more mature, we’d like to disable or remove these two abilities altogether. Until we can get there though, we want to ensure complete transparency around these levers. All these operations are naturally logged publicly onchain, and anytime they may become necessary they’ll also be announced over all our channels. They will only be used in the case of technical bugs or security risks, and never in response to market dynamics.
The Supply Policy
The supply policy has three hyperparameters and the ability to update the cpi and market oracle references.
These hyperparameters (min time between rebase, rebase lag, and deviation threshold) are not so much related to balancing the stability of the system, as they are related to the speed at which the system balances. For this reason, we don’t expect these parameters to change very often with the market. Instead, we expect them to change slowly with the protocol as it moves through different stages of its lifecycle.
The Oracles are built atop a whitelisted set of data providers. The governance around oracles are primarily around adding to and removing from this whitelist, but there are also some settings like report expiration time, minimum number of reports, and report delay.
Crucially, there is no oracle value override, so the value must be aggregated from the providers’ data reports. Since this is built atop the trust of a specific group of data providers, there are certain precautions we’ve put in place to help minimize that required trust.
We aggregate values with a median function. So in order for a data provider to control the oracle value, it must either compromise or collude with 50% of the data providers.
A providers report must exist on-chain for at least 1 hour before it can be used, giving the governance time to react before a malicious value is used by the supply policy.
The Ampleforth team is also currently working on a page of our public dashboard that shows a log of all the actions of every data provider for total transparency and accountability.
You’ll notice that the general structure of our oracle is very similar to oracles used in other projects (e.g. MakerDAO). The value of the Ampleforth project isn’t so much in innovating Oracles as much as in innovating economics, so we wanted something as predictable as possible. In the long term, we’d prefer to use public infrastructure and not have to run our own oracles at all.
(Until then… are you or your project interested in becoming a data provider? Please let us know!)
We felt that upgradeability is something we needed to include in the beginning, given how quickly the crypto landscape changes. If it were ever possible, and safe to do so, we’d also prefer to remove this mechanism. However, we believe it’s unrealistic to think we can design a system today that will last our lifetimes without needing any changes ever.
How Discretion is Governed Today
Not coincidentally, the protected points of discretion above are collectively the surface area for protocol governance. So let’s talk about how governance is implemented at launch.
In each module, the protected functions are guarded by checking that the caller address matches a specific authorized address. Using a single address variable allows us to separate the concerns of governance from the concerns of the protocol logic. For example, this interface would let governance evolve from a multisig M-of-N wallet to a fully binding onchain distributed voting mechanism without having to make any changes to the protocol code itself.
In the beginning stages when the system is exposed to the most risk, this address will be controlled by the development team via a Gnosis 2-of-N multisig wallet contract. This is fairly centralized, but the tradeoff is that we can respond quickly and efficiently when needed in the early days.
Using a 2-of-N structure means that no single person has unilateral ability to make changes, because they need at least one other approved member to execute any action. We’ll publish and verify all public keys prior to mainnet launch for complete transparency and accountability until we can move to a structure not so dependent on this group.
How Discretion may be Governed in the Future
Decentralized governance is a big topic, with many active experiments (dxDAO, molochDAO, Decred, Tezos, Cosmos, etc.) going on as we speak. Given the nature of our project, and the amount of value we expect it to one day hold, we think a conservative path is the best way forward. A very good argument can be made that Ampleforth should never institute a governance system that hasn’t already been proven out somewhere else--there’s no kiddy pool area of the project where a failure isn’t potentially critical.
Poorly implemented governance can cause deadlocks or worse. So this will likely need to be instituted in stages as safety allows, and in collaboration with the community.
Community sentiment could initially be gathered in non-binding ways before any decision is made, through tools like Carbon Vote.
A community key with veto power could be added as a required approver.
The multisig wallet could be replaced with binding onchain voting contracts.
In the very long term, if you look at the governance tasks mentioned above, you might notice that not every task is similar to the others. Changing hyperparameters of the supply policy takes a very different set of skills than upgrading contract code. So one could imagine elected councils (represented onchain) for Economics and a second one for Technical or Operations. These groups could make recommendations in text form, sign them and store the signatures onchain, vote, and perhaps allow for community overrules with certain levels of support. All of this of is very theoretical (and it’s debatable whether this is even the best model) but shows the true depth of where this domain could lead.
However, returning back to where we started… what’s better than big expansive governance systems? Not needing expansive governance to begin with. One nice thing about the Ampleforth protocol is its simplicity. Because the surface area is so small, we could very likely be successful with very simple governance tools.
We believe the best governance system is one that is: - Developed in collaboration with the community - Transparent - Accountable - ...but reduces the need for accountability as much as possible.
Ampleforth has so far been a single-token system. We also don’t have any plans to release a separate governance token, as we like the idea of all users of the system having a say in its path.
We hope this provides a good look at where Ampleforth is with its journey through governance. Given the depth and complexity of this area, we don’t expect to have all the answers right now. If this is something you’d like to take part in, please reach out to us! There’s lots more work to be done. :)
The last time money changed, it happened with a whimper, then a bang. In the twilight of the Second World War, 44 nations sent delegates to Bretton Woods to build a global economic system that could avoid depression, indemnity, and hyperinflation. After a month, they had built the World Bank Group, as well as what they hoped was a stable global financial system. And it worked: for 26 years, the world had a near absence of banking crises.
One of the system’s core features was the dollar’s use as a reserve currency, which created for it two contradictory uses: one as liquidity within the United States economy, the other as an asset held by foreign nations. The first use required low inflation and a stable price while the second needed more appreciation to maintain value. These tensions, made of contradictory policy promises, pulled the dollar in irreconcilable directions. Rather than wait for the snap, Richard Nixon announced in 1971 that the United States Dollar would no longer be indexed to gold, ending the Bretton Woods system and moving the modern world into an era of pure fiat currency. It also triggered a decade of stagflation.
Today, Bitcoin too faces Triffin’s Dilemma. While proposed as a peer-to-peer digital cash system, the first cryptocurrency has found more lasting traffic as an extremely unstable asset, less liquid than its creators would have liked but more fitting to its profile as “digital gold.” Those long-term holders would prefer that Bitcoin continue to appreciate so they can make returns on their investment. Many early adopters would instead prefer that Bitcoin stabilize in order to facilitate mass adoption in commerce. Bitcoin, caught between these two extremes, by design lacks either a board of governors to force a resolution or an internal design that can resolve the issues of dual use.
But Ampleforth has a solution to this dilemma. With these pressures in mind, we’ve created a cryptocurrency both decoupled from Bitcoin’s fluctuations and immune to the pitfalls of a fully deflationary currency. To do that, we’re building on George Selgin’s proposal of “synthetic commodity money,” an asset with a real cost of production that can still be adjusted in response to economic forces. In short: cryptocurrency. To overcome the limits of old money, we’re making something new, with a unique structure and movement pattern that makes it not only different than bitcoin, but potentially uncorrelated as well.
It took great minds to solve the currency shocks and crises of the past century, and now we are putting their Nobel-winning theories to work by creating Amples (AMPL). To learn more, please check out our Red Book, where we outline the economic principles guiding our design. Now, as before, money is set to change. Satoshi Nakamoto took the first great step in 2009. At Ampleforth, we’re ready to make the next leap.
Ethereum, EOS, STEEM, ONT, NEO, NAS, Cardano, Tezos, POA, Dfinity, ThunderCore, Solana, RChain, Oasis Labs, Zilliqa, VeChain… there are enough Layer-1 blockchain projects released, or nearing release, that it’s hard for even a dedicated developer in the space to keep track of them all. Even individual platforms are planning sub-chains, like Ethereum’s sharding and plasma projects. There are chains on top of chains. How should you make sense of a world with so many chains?
Many Chains, or One Chain?
One question we often get is whether we believe there will be a single stablecoin that rules them all… we think the answer here should be no. We subscribe to Hayek’s theory that there should be many competing currencies and the best ones will get continued and lasting use. Competition between currencies will be driven by better stability, philosophy, economic scalability, or incentive alignment with network growth, and that competition between monies is itself a form of decentralization worth fighting for.
Just as different digital currencies have different behavioral characteristics, different layer-1 chains also have different platform characteristics. Ethereum explicitly trades transaction throughput for increased decentralization. EOS explicitly trades decentralization for increased transaction throughput. Each of these will be home to different kinds of applications that care about different tradeoffs.
DApp vs Money
If you’re a decentralized application, like Augur for example, it makes sense to choose one chain and deploy there. All your data is in one place and your users only need to manage one wallet to interact with it.
If you’re building a new money that aims to eventually become a medium of exchange, you want to be everywhere anyone is making a transaction. ALSO, if you’re aiming to be a real money, you need a way of regulating supply with market demand.
This seems to lead to a conflict between the needs of two different parts of a monetary system. A monetary policy looks a lot like a DApp and wants to be on a single platform, while a token contract looks a lot like a money and wants to be on every platform.
As a refresher, here is the single chain Ampleforth architecture as described in the whitepaper:
We’d like the Ampleforth Monetary Policy, Oracles, and Governance modules to exist on the chain with the highest level of decentralization.
Fortunately in the case of Ampleforth, the set of users who interact with the Monetary Policy is much smaller than the set of users who interact with the token. There is currently one publicly callable function, rebase, that users can call that will initiate a monetary policy action and this executes at most once every 24hrs. Similarly, our Oracle data sources receive data about 4 times per day. For these modules we’re not that concerned with transaction throughput, so we’ll gladly sacrifice speed for decentralization. As of today, Ethereum meets these needs very nicely. It has a high level of decentralization, enough usage to guard against 51% attacks, and has an amazing and supportive community of developers around it.
The ERC-20 (or perhaps in the future, the zkERC-20) contract will be deployed on every platform capable of supporting the arithmetic necessary to power the token transfer and supply operations, which is mostly simple arithmetic.
Now instead of one “Ampleforth ERC-20” box, there will be one on every platform on which we’ve launched. In order for this to work, we need a few things:
A user must be able to transfer Amples from their wallet on one chain to another wallet on a different chain — Value-transfer.
The monetary policy must be able to call rebase() on the token contract of a different chain, or otherwise sync its state to the other chain — State Transfer.