Tokens, tokens, tokens
First, there was Bitcoin. Then there was the altcoin boom. Then the hot new stuff was blockchains without coins. And if you’ve spent any time in the cryptocurrency space lately, you’ll know tokens are the thing of the moment with 10 or more new ones every week. At Outlier Ventures we are seeing a multi-token world emerge, and from early on we’ve been tracking a good amount of the tokens out there. Recently we have developed a robust framework for understanding the token ecosystem, the highlights of which you can see in this token ecosystem landscape map.
Whilst most of these tokens are issued as ERC-20 on Ethereum – at least initially – some live on different platforms like Maidsafe or Waves, and others like Tezos are part of a new platform entirely.
Multi-token economies
In our Community Token Economy approach we propose the creation of multi-token economies. It looks like this:
There is a need for each of these to interoperate in a frictionless way. In the ultimate vision, the community token economy is a fluid mesh of value offered, consumed and rewarded. So how can they interact and interoperate?
Smart contracts for token interoperability
Smart contracts, or more generically programmable blockchains, are the building blocks of most tokens. An Ethereum ERC-20 token is no more or less than a small computer program on the Ethereum blockchain. It has a handful of functions to do things like returning the balance of an account and transferring funds, and some storage that keeps balances. Can we use smart contracts to make tokens smarter and let them interact in interesting ways? Sure we can.
Case study: freezing tokens
In the CTE white paper we described SteemIt as a case study of a multi-token economy. SteemIt has interoperability between its three tokens encoded into its purpose-built blockchain platform. For example, the Steem token can be converted into the Steem Power token instantly, while conversion the other way takes time. Effectively the tokens are bonded, signalling long-term support for the platform in exchange for an interest rate and increased voting rights.
This type of token interoperability could be realised on a general-purpose blockchain such as Ethereum, using smart contracts. The logic to support this can remain quite simple, which is essential to make them secure and keep transaction fees low. Let’s explore how we might realise a freezing/unfreezing interaction such as between Steem and Steem Power in Ethereum smart contracts.
(If you’re not into smart contract technicalities, just skip the next section)
A token freezing mechanism in smart contracts
To implement a token freezing mechanism in Ethereum-based smart contracts, we create two token contracts that are aware of each other. We’ll call these Active and Frozen. The first is the contract for the Active token (i.e. tokens that can be actively used and traded, like the Steem token), the second for the Frozen token (i.e. tokens that are locked in for a period, like the Steem Power token). Both implement the ERC-20 standard and have some additional functions to facilitate the freezing mechanism. They check permissions so that some functions can only be called by the other contract.
The Active token contract has all the normal ERC-20 token functions, and additionally it has a function freeze(amount) which allows token holders to freeze a certain amount of their holding.
When Alice wants to freeze 100 of her 250 Active tokens, she calls freeze(100). The Active contract checks if she has enough balance to do this, and gets to work. Her balance of Active tokens becomes 150. The Active contract destroys 100 of her active balance and calls a permissioned function on the Frozen contract to add a deposit of 100 to Alice’s Frozen account. The deposit(amount) function is permissioned so that only the Active contract can call it.
The Frozen contract also implements the ERC-20 functions. Functions like transfer() are left empty so that tokens are locked, and can only be recovered using the unfreezing mechanism.
To unfreeze some tokens, or in other words, convert them back into Active tokens, Alice calls unfreeze(50) on the Frozen contract. This stores a withdrawal operation with the amount and the date.
We can implement the rest of the unfreezing logic mostly in read-only functions. First, the Frozen contract gets an additional function getAvailableBalance(address). This gives the available amount from the withdrawal operation according to the current date (using last block time). The Active contract uses this in its implementation of the ERC-20 function balanceOf(address) and adds it to the amount in the Active contract for that user. When making a transfer, i.e. when the ERC-20 function transfer() is called, the Active contract takes any outstanding balance in withdrawals from the Frozen contract first. Then it completes the withdrawal by calling unfreezeComplete(amount) on the Frozen contract, which finalises the withdrawal in its storage.
This is an outline of how a token freezing mechanism in Solidity could work and not an actual implementation. The approach can be optimised, and like any smart contract the implementation would need to be security-hardened. There are other approaches to achieve the same result within Solidity, and surely this kind of behaviour is possible with alternative smart contract languages and platforms and like NEO and EOS.
More types of token interactions
Similar to the token freezing example, many other forms of automated token interactions can be implemented. As part of designing and growing community economies we encourage experimentation and iterative development around monetary policy.
Some forms of token interactions and smart token behaviours that might be realised using smart contracts:
- Automated exchange, explored below
- Demurrage, i.e. a token losing some of its balance over time if left unused for a particular application
- Pay for usage of a service at a discount when paying using certain tokens
- Issuance of new tokens at a discount when paying using certain tokens
- Variable issuance of new tokens according to external factors like platform adoption
Decentralised exchanges and token changers
The CTE approach needs frictionless ways to seamlessly exchange tokens for other types tokens, both within the community token economy and as on-ramps and off-ramps. This is true for end users, but even moreso for applications. Ideally, users won’t experience any friction of funds being changed from the denomination they know (for example Pound Sterling) into an app token or further into protocol tokens. We need automated and decentralised ways to do this.
Decentralised exchanges such as EtherDelta, Kyber network, 0x and Omega One are furthering the frontier for decentralised exchange of tokens with some success. Whilst decentralisation comes at a cost and there is still much ground to cover, we’ve come a long way already. A DApp could interact with the EtherDelta smart contract right now to exchange, for example, Kik’s Kin token for Ether without an end user ever opening EtherDelta’s website and with no counterparty risk. That’s progress, and there is very likely more to come.
Another approach to exchanging tokens, which we’ve mentioned in the CTE white paper, is championed by Bancor. A token changer contract is created which wraps tokens A and B, and is itself a token AB. To change token A into token B, a user (or an app) purchases AB tokens with token A, then liquidates those into token B. Although Bancor is promising and well aligned with a multi-token perspective, a considerable number of possible weaknesses have been pointed out, and there might be simpler ways to exchange one token for another.
Within the scope of a community token economy, a simplified form of a dedicated token changer could be realised, using the Community Token as a reserve currency and an oracle to determine the exchange rate rather than relying on a decentralised trading mechanism and active arbitrageurs. Because this token changer provides a genuine service to the token economy, it can charge a fee slightly above market price to compensate for losses due to price inaccuracies. And because the community controls it through its governance structure, its reserves can be adjusted manually rather than automatically, thereby avoiding some of the weaknesses of Bancor, while preserving the trustless character.
Wrapping up
On a sufficiently feature-rich base ledger, there are many methods to let different tokens interact and exchange. But what if our tokens are on different distributed ledgers? In a follow-up post we’ll explore ways for distributed ledgers to interoperate including Cosmos, Polkadot, Plasma and Aion.
