You're looking at all the posts published by Brandon Iles.
/ Ampleforth

State of Discretion and Governance in Ampleforth

State of Discretion and Governance in Ampleforth

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.

Ampleforth Modules

As a quick refresher, there are three main protocol modules:

- The ERC-20 Token, UFragments.sol
- The Supply Policy, UFragmentsPolicy.sol
- The Oracle used for CPI and market data, MedianOracle.sol

The Token

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 Oracle

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
- 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 best way to join the conversation is through the Telegram Channel, Subreddit, GitHub repo, or email.

/ Ampleforth

Independent Currency in a Multi-Chain World

Independent Currency in a Multi-Chain World

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.

Ampleforth Everywhere

As a refresher, here is the single chain Ampleforth architecture as described in the whitepaper:

Single Chain Architecture

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.

Thanks to Evan Kuo.

This Article was originally posted on Ampleforth's Medium Blog.

/ Ampleforth

Ampleforth is not a Stablecoin... (And that’s OK!)

Ampleforth is not a Stablecoin...            (And that’s OK!)

When people think of Stablecoins, they have something very specific in mind. A Stablecoin is meant to remove volatility. A Stablecoin is something you can use for payments. A Stablecoin is something you could use as a base trading pair on an exchange or as a refuge from positions in other digital assets. A Stablecoin is a stand-in for the dollar on the blockchain.

While Amples may be used for such tasks at some point in the far future, they are absolutely NOT stablecoins today. (And that’s OK!) Here’s why...

A Stablecoin removes volatility

Ampleforth does not try to remove volatility from the system. In fact, by design it allows volatility. Movements from the price target is the primary mechanism that engages the supply policy.

A Stablecoin can be used for payments

Until Amples have reached any kind of economic price-supply equilibrium, other stablecoins will be easier to use for payments and should be preferred for that use case. Dollars will be even easier still. Using Amples for payments will be about like using BTC or ZCash for payments, as we expect both price and supply to be volatile at launch.

A Stablecoin can be used as a base trading pair

Since Amples will likely be volatile, you’d be better served trading with a stablecoin (or the dollar) against Amples, instead of trying to use Amples as a base trading pair itself.

So Ample is not a stablecoin… Why was it created?

The Ample is an asset we’ve never seen before--it’s a Smart Commodity Money that incorporates price directly into supply. When supply needs to increase, it doesn’t go to any special group--it goes to everyone universally. Same for supply decreases.

Since commodities are naturally fair and independent, Amples were designed to uphold those same principles. Ample supply is governed strictly and automatically by rules, with no discretion on supply policy decisions. There are no added transaction fees, stability fees, or interest rates that need to be balanced with the market. There are no central collateral balance sheets that need to be maintained. There are no regular votes on monetary policy. Amples are never minted and sold, or bought and burned. Amples are fair, direct and independent, with no special class of stakeholders.

Amples will move differently

We expect that Amples will move differently from other digital assets, making them uniquely useful as a way of diversifying risk in a broader portfolio of assets or as a collateral asset in decentralized banks like MakerDAO.

Amples are macroeconomically friendly

Amples are a commodity money that doesn’t suffer the same deflationary drawbacks of fixed supply currencies.

Amples can scale economically

The Ampleforth protocol is an outside money that doesn’t rely on any collateralized debt. It can scale to a global ecosystem without having to lock up exogenous assets.
In short, Ampleforth is not trying to recreate fiat money on the blockchain. It is a new formulation of a smart, synthetic commodity money that we believe to be the next natural experiment after Bitcoin. In the beginning, it will likely be useful for diversifying risk within a portfolio or as an uncorrelated reserve asset. Much later, it could become an alternative to central bank money.