The global crypto market cap grew tenfold from January 1st, 2020, to January 1st, 2022 (from $196B to over $2T¹). This massive growth has caused a fragmentation of liquidity– as of March 2022, more than 15 different blockchains have native tokens with market caps above $5B²). Furthermore, it seems unlikely that the market will have a single “blockchain to rule them all”, as the different chains offer trade-offs between security models, speed, cost, functionality, and environmental costs that make different blockchains appealing for different users and applications.
Allowing users to move liquidity from one chain to another securely is a challenging and critical problem facing the continued growth of the blockchain space. Kima has been developed to provide this seamless, secure, and efficient cross-chain transaction. It is superior to the other interoperability and liquidity solutions available on the market today, including cross-chain bridges/token-wrapping and direct messaging. This section will share an overview of these solutions and their disadvantages.
Also review our for a detailed description of the technical elements of the Kima protocol and blockchain that support the advantages of the Kima model over the other solutions.
¹Coinmarketcap. Global charts.https://coinmarketcap.com/charts/, 2022. ²https://defillama.com/chains
Custodial wrapping solutions require a trusted custodian to coordinate actions between the chains (e.g., minting wrapped tokens or releasing reserve tokens). In these situations, the custodian serves two roles. First, it relays messages between chains. Second, it serves as the sole source of truth as to the state of the other chain, i.e., if the custodian authorizes the minting of wrapped assets, those assets will be minted regardless of whether reserves were deposited.
Although blockchains cannot communicate directly with each other, in some situations, the custodian can be replaced by an untrusted relayer, whose sole job is to pass messages between the chains. This is non-custodial wrapping.
The core idea of non-custodial token wrapping is that each chain runs the other chain "light-client" directly on-chain. In other words, if it is possible to generate succinct “state proofs” that encode the current state of the source chain, and an efficient verifier (that can run inside a contract on the destination chain), an untrusted relayer can “prove” that an action happened on the source chain, and this action can be verified by a contract on the destination chain.
Suppose an on-chain contract can validate transactions for the other. In that case, an untrusted relayer can simply forward the state of the source chain to the verifier contract on the destination chain, where it can be verified. In this case, both the reserve contract on the source chain and the wrapped token contract on the destination chain can be keyless, eliminating the need for a custodian to safeguard the keys. This type of non-custodial wrapping is only possible when the source chain has a light client that is simple enough to be executed within a smart contract on the destination chain. The inter-blockchain communication (IBC) protocol allows Cosmos-based blockchains to interact in this way¹.
Almost all blockchains built using the Cosmos SDK can wrap tokens this way, including several large-market-cap chains such as the Cosmos Hub, crypto.org, Thorchain, Axelar, the Secret Network, Binance Chain, and many others².
In addition to the IBC-enabled chains, several other layer-1 blockchains have been built to enable efficient light clients, e.g., Mina³ and Algorand⁴.
It is possible to build light clients for existing blockchains (e.g., Bitcoin), but this is an extremely challenging task and typically requires a complete redesign for each supported blockchain. The job of a light client on the destination chain is to verify that a given transaction occurred on the source chain. This task would be easy if the light client had access to block headers from the source chain. Users could issue simple Merkle Proofs that a given state balance was consistent with the (known) block header. LayerZero uses this technique to provide cross-chain interoperability and trusted Chainlink oracles push block headers onto the chain⁵. Once these block headers are stored on the destination chain (untrusted), users can easily prove that deposits occurred on the source chain. This solution is efficient but crucially relies on the honesty of the oracles providing the block headers. Malicious oracles could provide invalid block headers, allowing them to certify non-existent deposits and make real withdrawals.
¹https://ibcprotocol.org/
²https://cosmos.network/ecosystem/tokens/
³Joseph Bonneau, Izaak Meckler, Vanishree Rao, and Evan Shapiro. Mina: Decentralized cryptocurrency at scale. Technical report, O(1) labs, 2020. ⁴Noah Grossman. Algorand state proofs.https://medium.com/algorand/algorand-state-proofs-707d64038e35, 2022.
⁵Ryan Zarick, Bryan Pellegrino, and Caleb Banister. Layerzero: Trustless omnichain interoperability protocol. LayerZero:TrustlessOmnichainInteroperabilityProtocol, 2021.
The Kima platform has several advantages over direct messaging solutions. Kima is aware of all the pools' states and history, at any time/block, and thus can set optimal incentives. Not only that, but also in addition to Kima's core activity (cross-chain transfers), in some cases, and based on users' and governance decisions, it can take additional actions to increase incentives via composability. For instance:
Use services (such as Curve) to move liquidity between pools on the same network (i.e., USDT to USDC on Ethereum)
Use abundant liquidity to generate additional yield by integrating with other services (i.e., offer loans)
In comparison, pools that rely on direct messages can act only based on local information sent at the message time. While the gain from the Kima optimization is hard to quantify in the abstract, it should improve capital efficiency and thus translate into higher returns for liquidity providers and lower costs to users.
Asset wrapping or token wrapping is a straightforward approach to moving assets from one chain to another. The core idea is that an asset, for example ETH, is locked on one chain (Ethereum), and a synthetic, “wrapped” asset (wETH) is minted on another chain (e.g., Solana). The core technical challenge with token wrapping is to ensure that the wrapped asset stays in sync with the underlying reserves, that the number of wETH on Solana remains in one-to-one correspondence with the ETH held in escrow on the Ethereum chain. There are two core methods for ensuring that the wrapped asset remains synchronized to the reserve asset - custodial and non-custodial.
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 was WBTC¹. A group of custodians hold BTC on the Bitcoin blockchain and issue “wrapped” BTC (WBTC) on Ethereum. 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.
There are two core security problems with custodial token wrapping.
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.
Attackers could potentially subvert the minting capability of the smart contract to mint unbacked wrapped assets. This is also a threat to non-custodial solutions.
The risk of contract vulnerabilities also increases with the complexity of the on-chain bridge contracts for both custodial and non-custodial solutions. For example, the Wormhole bridge uses multi-signatures instead of threshold signatures (TSS)². This requires the contract to aggregate multiple signatures from different accounts before updating its state. The use of multi-signatures, instead of TSS, drastically increases the complexity of the contract and leads to contract risk like that used in the Wormhole attack³.
¹Kyber Network, BitGo Inc, and Republic Protocol. Wrapped tokens a multi-institutional framework for tokenizing any asset. https://wbtc.network/assets/wrapped-tokens-whitepaper.pdf, 2019.
²Leopold Schabel. Introducing the wormhole bridge.https://medium.com/certus-one/introducing-the-wormhole-bridge-24911b7335f7, 2020.
³Extropy.io. Solana’s Wormhole hack post-mortem analysis. https://extropy-io.medium.com/ solanas-wormhole-hack-post-mortem-analysis-3b68b9e88e13, 2022.
Even if the technical challenges can be overcome and the wrapped asset remains synchronised with the underlying reserve asset, relying on token-wrapping alone introduces liquidity fragmentation. Instead of assets being “swapped,” assets are locked and then new, synthetic tokens are issued on another chain. As a result, liquidity is locked on various blockchains, increasing the number of digital assets not available to the market. In deflationary token economies especially, this is an issue, as it reduces the operational liquidity of that blockchain.
The additional problem is that wrapped tokens are still not interoperable with native tokens on the destination chain. Thus, wrapping has not solved the problem of liquidity fragmentation. It allows chains to communicate, but in doing so, only makes the fragmentation of liquidity occur within chains rather than between them.
Even worse, if there are multiple bridges between the same chains, the bridges produce different wrapped tokens which are not interchangeable. Thus having multiple wrappings of the same token contributes to liquidity fragmentation – the main problem the bridges were built to solve. Each new bridge brings a collection of bridge-wrapped tokens, and the proliferation of bridges has brought with it a proliferation of bridge-wrapped tokens. For example, Avalanche had about 650M USDC¹, 1.6B Avalanche-Bridge-Wrapped USDC², and a paltry 680M Wormhole-wrapped USDC³.
Similarly, in addition to native USDC⁴, Solana has 47M Sollet-wrapped USDC⁵, 5M Wormhole-wrapped USDC⁶, and 1.9M Allbridge wrapped USDC (from Ethereum)⁷. Further complicating things, Allbridge wraps USDC differently depending on the source chain, so Allbridge wrapped USDC from Avalanche⁸ is controlled by a different contract than Allbridge wrapped USDC from Ethereum.
The situation worsens as Allbridge also offers wrapped USDC from chains like BSC⁹ and Polygon¹⁰, neither of which chains natively support USDC. As a result, these tokens are wrappings of wrappings.
Protocol developers now realize that having multiple bridges into their ecosystem is undesirable. For example, Osmosis recently solicited applications to be the one “canonical” bridge to their blockchain¹¹.
Avoiding the wrapping issue, stablecoins like USDT¹² and USDC¹³ are natively available on Ethereum, Solana, Avalanche, Algorand and Tron. Nevertheless, moving value across chains is still a cumbersome and risky process.
A superior model for cross-chain projects is to maintain pools of assets on each blockchain. The project's custodians can release these “real” (native) assets on the destination chain when they observe a deposit on the source chain. This is the approach taken by the cross-chain DEX Thorchain and is the approach taken by Kima.
As with the wrapping solutions, the core technical challenge with using liquidity pools to facilitate cross-chain swaps is keeping the pools synchronised, i.e., ensuring that tokens are only released on the destination chain when corresponding tokens are deposited on the source chain. When the source chain has an efficient light-client implementation, then the destination chain can validate source-chain deposits without the help of trusted, off-chain entities.
¹https://snowtrace.io/token/0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e ²https://snowtrace.io/token/0xA7D7079b0FEaD91F3e65f86E8915Cb59c1a4C664 ³https://snowtrace.io/token/0xb24ca28d4e2742907115fecda335b40dbda07a4c ⁴https://explorer.solana.com/address/EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v ⁵https://explorer.solana.com/address/BXXkv6z8ykpG1yuvUDPgh732wzVHB69RnB9YgSYh3itW ⁶https://explorer.solana.com/address/FVsXUnbhifqJ4LiXQEbpUtXVdB8T5ADLKqSs5t1oc54F ⁷https://explorer.solana.com/address/DdFPRnccQqLD4zCHrBqdY95D6hvw6PLWp9DEXj1fLCL9 ⁸https://explorer.solana.com/address/8Yv9Jz4z7BUHP68dz8E8m3tMe6NKgpMUKn8KVqrPA6Fr ⁹https://explorer.solana.com/address/8XSsNvaKU9FDhYWAv7Yc7qSNwuJSzVrXBNEk7AFiWF69 ¹⁰https://explorer.solana.com/address/eqKJTf1Do4MDPyKisMYqVaUFpkEFAs3riGF3ceDH2Ca ¹¹Stevie Woofwoof. Osmosis town hall — choosing a bridge service provider.https://medium.com/osmosis-community-updates/osmosis-town-hall-choosing-a-bridge-service-provider-63e0835d78e, 2022.
¹²https://tether.to/en/transparency/ ¹³https://www.circle.com/en/multichain-usdc