Independent Currency in a Multi-Chain World

Independent Currency in a Multi-Chain World

By Ampleforth | Ampleforth | 20 Aug 2020

Originally posted Feb 4th, 2019

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.

Polkadot and Cosmos are each working to bridge chains together and we’ll likely leverage one or both projects to link these parts together.


Many Chains, Many Coins?

Bitcoin makes one promise to its users: a fixed supply cap of 21M. Bitcoin could change many things about its protocol, but if it ever broke this promise it would cease to be Bitcoin.

ETH, on the other hand, could change its linear inflation schedule to be steeper or shallower — it could even switch to a fixed supply like BTC — and it would still be the world computer. ETH’s promise is that you’ll be able to redeem ETH for computation.

Ampleforth’s promise is equally simple, it’s a direct elastic supply policy that responds only to demand. We could have a token contract on Ethereum and a copy of that token contract on EOS, but as long as the tokens share the same supply pool, are fungible with each other, and are governed by the same monetary policy, they are all “Amples”.

We could even have two different token implementations on a single chain like Ethereum, one standard ERC20 and one private-but-more-gas-intensive zkERC20.

If one platform is meaningfully more useful than another, you might think these exchange rates would diverge. I think instead, more tokens should naturally flow to that higher-value platform (through usage or simple arbitrage) and still lead to an equalized price over time.


Wrapping Up

All of the above should make it clear why Ampleforth is explicitly is not building its own chain. By deploying on many chains, we can leverage the benefits of every platform as needed and be anywhere anyone is storing value or making a transaction.

What do you think of this vision? Is there anything you think we’re missing?


Written by: Brandon Iles, - @brandoniles


Ampleforth #AMPL on Publish0x. Website:


Ampleforth #AMPL blog on Publish0x.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.