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.
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!)
The token and supply policy are upgradeable via OpenZeppelin’s AdminUpgradeabilityProxy. This allows for further development, integrations, and security fixes for bugs that weren’t found in our three independent security audits.
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.
It will start with a simple, audited Gnosis Multisig Wallet controlled by Ampleforth team members.
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
- ...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. :)