Transferring value
Last updated
Last updated
Once inter-chain communication has been established, either through oracles or light clients, there are two main methods for transferring value across the chain: asset-wrapping and liquidity pools.
Token wrapping is a straightforward approach to moving assets from one chain to another. The core idea is that an asset (e.g., ETH) is locked on one chain (e.g., Ethereum) and a synthetic, “wrapped” asset (e.g., wrapped ETH) is minted on another chain (e.g., Solana).
Token wrapping is an appealing solution for transferring value because it is easy to deploy — wrapping an asset only requires an escrow address on the source chain and token contract on the destination chain. When (real) tokens are deposited on the source chain (and this information is relayed through a bridge or light-client protocol), synthetic assets are minted on the destination chain.
The core technical challenge with token wrapping is to make sure that the wrapped asset stays in sync with the underlying reserves (e.g., the number of Wrapped ETH on Solana remains in one-to-one correspondence with the ETH held in escrow on the Ethereum chain).
With custodial asset wrapping, a custodian (or group of custodians) holds the private keys controlling accounts on two chains. The (off-chain) custodian monitors both accounts and keeps them in sync by issuing (signed) transactions to the appropriate blockchain. One of the earliest successful examples of token wrapping is WBTC, where a group of custodians hold BTC (on the Bitcoin blockchain) and issue “wrapped” BTC (WBTC) on Ethereum (and Tron).
The WBTC custodians monitor their WBTC wallet(s), and when BTC is deposited, they use their private key to issue (“mint”) new WBTC on the Ethereum blockchain. Conversely, when Ethereum users redeem (“burn”) their WBTC, the custodians use their private key to release BTC on the Bitcoin blockchain.
The WBTC bridge is only one-way; BTC can be wrapped on the Ethereum blockchain but wrapped ETH is not created and issued on the Bitcoin blockchain because there is no natural method for issuing new tokens on the Bitcoin blockchain.
As of March 30, 2022, more than $12.9B worth of WBTC is in circulation on the Ethereum blockchain (and a corresponding amount is held in the custodians’ wallets on the Bitcoin blockchain). This model of bridging through custodial token wrapping is the most common form of blockchain interoperability.
For example, the Wormhole Bridge connects 8 chains (Avalanche, BSC, Fantom, Ethereum, Oasis, Polygon, Solana, and Terra), and their network of 19 “guardians” controls almost $3B in assets across these chains. Similarly, the Avalanche bridge uses custodial token wrapping to provide interoperability between the Avalanche C-Chain and Ethereum. Currently, the Avalanche bridge contract holds over $5.7B worth of assets on Ethereum.
Many other bridges, e.g., the Binance Bridge, the Nomad Bridge, Allbridge, and Sollet also use custodial token wrapping to “move” liquidity across chains.
There are two core security problems with custodial token wrapping.
Insider Threat: The custodians hold the private keys to accounts on both chains and can use these keys to steal the reserve assets, or mint unbacked wrapped assets.
Contract Vulnerabilities: Token wrapping requires the bridge to maintain a contract (rather than an EOA) on the destination chain. Attackers could potentially subvert the minting capability of the smart contract to mint unbacked wrapped assets – this is what happened in the Wormhole exploit
The risk of contract vulnerabilities increases with the complexity of the on-chain bridge contracts. For example, the Wormhole bridge uses multisignatures instead of threshold signatures which requires the contract to aggregate multiple signatures from different accounts before updating its state. The use of multisignatures instead of threshold signatures drastically increases the complexity of the contract and leads to contract risk like that used in the Wormhole attack.
Efficient light clients allow trustless relaying of information between chains.
Light client relayers can also be used to facilitate asset wrapping. In this case, both the reserve contract on the source chain and the wrapped token contract on the destination chain can be keyless, which eliminates the need for a custodian to safeguard the keys.
This type of non-custodial wrapping is only possible when both the source and destination chains have light clients which are simple enough that they can be executed within smart contracts on the other chain. In practice, this restricts this type of solution to the Cosmos ecosystem where IBC provides a trustless message-passing protocol.
Token wrapping has been widely deployed because it is a simple method for cross-chain value transfer, but, as discussed above, it causes liquidity fragmentation which is plaguing blockchains today.
In order to avoid the liquidity fragmentation caused by token wrapping, it is necessary to maintain liquidity on the destination that can be released as necessary.
The main appeal of token wrapping is that bridges based on token wrapping can be launched without any liquidity. Initially, the bridge operators start with no liquidity on either the source or destination chain, and when a user deposits assets on the source chain, the bridge simply mints new (synthetic) assets on the destination chain.
If, however, the bridge maintains a pool of “real” assets on the destination chain, then the bridge wardens can release these real assets on the destination chain when they observe a deposit on the source chain.
This type of value transfer does not introduce new synthetic tokens and thus does not contribute to liquidity fragmentation.
This is the approach taken by Kima. The approach has previously been taken by the cross-chain DEX Thorchain and by the Stargate Bridge, but Kima introduces significant security improvements compared to these platforms.
As with wrapping solutions, most systems transferring value using liquidity pools rely on trusted “custodians” or “wardens” to manage the pool assets. Ensuring these custodians do not mismanage pool funds is crucial to the security system.
When the source chain has an efficient light client implementation (that can be implemented on the destination chain), there is no need for custodians. Still, until more chains support this type of “trustless” message passing, oracles are necessary to relay messages.
Maintaining liquidity pools makes it possible to avoid token wrapping. However, insufficient liquidity on the destination chain can cause transfers to fail. This is not a risk to the system. If a user deposits tokens on the source chain when there is insufficient liquidity on the destination chain, the system can simply refund the user’s deposit. It does, however, present a user experience problem. Users would like to know whether their transfer will succeed before sending tokens on the source chain.
This problem is particularly challenging when transferring across multiple chains. For example, suppose there are three chains A, B, and C, and the liquidity pool on chain C holds 100 tokens. If a user on chain A tries to send 51 tokens to chain C, while a user on chain B tries to send 51 tokens to chain C, the pool on chain C can only fulfill one of the two withdrawal requests. If deposits were made on both chains A and B, then one of those deposits needs to be refunded.
To avoid this problem, the Stargate Bridge (built on top of LayerZero) allocates liquidity separately for the source chain. Thus the liquidity is partitioned into sub-pools, one for transfers from pool A and another for transfers from pool B. Their “∆-protocol” allows users to know (before initiating a transfer) whether their entire transaction will succeed, but it has two main drawbacks: (1) it fractures the liquidity on the destination chain, which limits the size of transfers that can be performed and (2) it dramatically increases on-chain complexity, requiring the liquidity pools be contracts (rather than EOAs).
Kima takes an alternative approach to ensure that pools on the destination chain always have sufficient liquidity to process user transactions.
