Some drawbacks of multi-token blockchains

A multi-token blockchain is any blockchain which is capable of hosting representations of multiple distinct tokens/cryptocurrencies.

Multi-token blockchains are typically powered by smart contracts; these keep track of distinct ledgers within the same blockchain to represent different cryptocurrencies.

Ethereum is a prominent example of a multi-token blockchain. Although the native token of Ethereum is ETH, the Ethereum blockchain also hosts many other tokens known as ‘ERC20’ tokens. These custom tokens support similar transactional capabilities as ETH but they are controlled via smart contracts whose state is recorded on the same blockchain.

One of the defining features of multi-token blockchains is their approach to cross-chain interoperability. Unlike single-token blockchains which are focused on direct chain-to-chain conversion via bridges, multi-token blockchains tend to separate the token conversion step from the cross-chain transfer step. With the multi-token approach, the conversion of tokens from one unit to another is recorded on a single blockchain; newly acquired tokens can then be moved to a different blockchain as a separate step.

One approach to move tokens from one multi-token blockchain to another is using a state proof mechanism; this involves locking tokens on one blockchain and then using the resulting state proof to release/unlock an equal number of tokens on a different blockchain. This is the approach used by Algorand. See https://medium.com/algorand/algorand-state-proofs-707d64038e35 — It ensures that the total number of tokens available across all blockchains in the ecosystem is always limited and (in theory) cannot exceed the total number of tokens which were issued on the native blockchain.

Some drawbacks of this approach are:

• While tokens are held on a remote chain, they cannot be used to participate in on-chain governance on their native chain.
• Tokens held on remote chains cannot be interfaced with via the same API endpoints as tokens held on the native chain.
• The list of native chain validators must be kept up to date on the upstream chain (and vice versa); this requires native chains to continuously pay fees to the upstream chain to update its validator list; the upstream chain needs this list of validators in order to be able to verify state proofs from the native chain. This generates ongoing operational costs for the native chain.
• The consensus mechanism which is used by the native chain must be capable of producing state proofs that are compatible with the upstream chain.
• If the upstream chain is unreliable, malicious state proofs could be generated to cause tokens to be issued/unlocked on the native chain. The state proof model assumes that the upstream blockchain is secure and that the majority of its validators are honest. The integrity of tokens on the native chain can only be as good as the integrity of tokens on the upstream chain.
• It’s a complex solution which requires more computational resources than cross-chain bridging. More computational resources generally means higher fees.

With decentralized bridges (e.g. cross-chain DEXs), each bridge/DEX can potentially be operated by a different set of people/validators; this creates more competitive pressure to keep fees low and it ensures that cross-chain token conversions/transfers are processed quickly and efficiently. The cross-chain bridging approach also creates incentives for node operators to launch, operate and promote markets in a way which maximizes capital efficiency — This is because the financial interests and goals of DEX node operators are district from those of blockchain node operators. Whereas the goal of a blockchain node operator is to encourage people to purchase and then to passively HODL a specific token for as long as possible, the incentive of a DEX node operator (who receives a % fee on each trade) is instead to promote trading activity and encouraging people to continuously re-evaluate their investments.