How can a blockchain verify the state of another blockchain? There are two solutions: oracles and light clients.

Oracles

Oracles are trusted entities that push information onto a blockchain so that it can be easily consumed by on-chain contracts. Although oracles are often used to move real-world data onto the blockchain, they can also be used to move information from one chain onto another. In this context, oracles are trusted entities that validate transactions on the source chain and push updates to the destination chain. In most situations, multiple oracles are used to reduce the dependence on a single trust point. The information provided by multiple oracles can be aggregated on-chain (via multisignature contracts) or off-chain via threshold signature schemes.

When the oracles control assets of value, they are often called custodians rather than oracles, but their role is the same.

Most bridging solutions rely on oracles, e.g., WBTC relies on a set of “custodians” to push information about BTC balances on the Bitcoin blockchain to other chains like Ethereum. The Wormhole bridge relies on oracles known as “guardians” to hold assets in escrow and mint synthetic assets on other chains.

Light Clients

Passing information through oracles requires some degree of trust in the oracles.

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. The core idea of non-custodial token wrapping is that each chain runs the other’s “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), then an untrusted relayer can “prove” that an action happened on the source chain. A contract on the destination chain can verify this action. Most bridging solutions rely on oracles, e.g., WBTC relies on a set of “custodians” to push information about BTC balances on the Bitcoin blockchain to other chains like Ethereum. The Wormhole bridge relies on oracles known as “guardians” to hold assets in escrow and mint synthetic assets on other chains.

If an on-chain contract can validate transactions for the other, then 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.

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 includes several large-market-cap chains, including Terra, the Cosmos Hub, crypto.org, Thorchain, Axelar, Secret network, Binance Chain, and many others.

In addition to the IBC-enabled chains, several other layer-1 blockchains have been built with the goal of enabling 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 it typically requires 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. If the light client had access to block headers from the source chain, then this task would be easy. 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. 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 which would allow them to certify non-existent deposits and consequently make real withdrawals.

From January 1st, 2020, to January 1st, 2022, the global crypto market cap grew more than tenfold (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 different chains offer trade-offs between security models, speed, cost, functionality, and environmental costs that make different blockchains appealing to other users and applications.

Allowing users to move liquidity from one chain to another securely is a challenging problem but critical for the continued growth of the blockchain space. Entrepreneurs have tried to solve the liquidity problem by creating bridges that introduce synthetic "wrapped" tokens on the destination chain. These wrapped tokens now exist on the destination chain and can benefit from the new chain's functionality, security guarantees, and other properties. However, the wrapped tokens are still not interoperable with native tokens on the destination chain. Thus wrapping has not solved the problem. 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, each bridge produces different wrapped tokens which are not interchangeable. Thus having multiple wrappings of the same token actually 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 has about 650M USDC, 1.6B Avalanche-Bridge-Wrapped USDC, and a paltry 680 Wormhole-wrapped USDC. Similarly, in addition to native USDC, Solana has 47M Sollet-wrapped USDC, 5K 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 gets worse as Allbridge also offers wrapped USDC from chains like BSC and Polygon, neither of which chains support USDC natively, so these tokens are wrappings of wrappings. Protocol developers are beginning to realize that having multiple bridges into their ecosystem is actually undesirable. For example, Osmosis recently solicited applications to be the one “canonical” bridge to their blockchain.

Besides being painful for the user experience, the proliferation of bridge-wrapped tokens is also a significant security risk. Transferring a token on one chain to anything but its wrapping on another chain requires at least two hops, each of which risks the user will initiate an incorrect transaction and thus lose their funds. Furthermore, different wrappings of tokens are not equivalent, so if a user ever sends the wrong type of wrapped token to a smart contract, they will also lose their funds. This is made worse because many of the wrappings have similar names. Wormhole even has 2 versions of wrapped UST on Ethereum! The mushrooming number of wrapped tokens and bridge contracts increases the chance that a user will misunderstand which contract address on which chain they should send which wrapping of which token. An error of any of these will also result in irreversible lossoffunds. This is true even for stablecoins like USDT and USDC, which are both natively available on Ethereum, Solana, Avalanche, Algorand, and Tron.

Kima is a new blockchain that tackles the interoperability problem without causing additional fragmentation. Kima addresses this problem by managing liquidity pools across multiple chains, thus providing a simple and secure mechanism for users to perform cross-chain atomic swaps without token wrapping.

Existing interoperability solutions

Blockchain interoperability is a method by which two different blockchains can pass information and eventually value.

This document is created by Kima for educational and informational purposes only. The contents of this document are not a financial promotion. None of the information or analyses presented are intended to form the basis for any investment decision and no specific recommendations are intended. Therefore, none of the contents of this document serve as an invitation or inducement to engage in any sort of investment activity. This document is not intended to be a prospectus, solicitation, inducement or offering for investment or the sale or issuance of securities or any interests or assets.

The information in this document is given in good faith, but no warranties, guarantees or representations are made by Kima with regard to the accuracy, completeness or suitability of the information presented. Kima expressly disclaims any and all responsibility, and Recipients expressly waive any claim, for any direct or consequential loss or damages of any kind whatsoever (whether foreseeable or not) arising directly or indirectly from: (i) reliance on any information contained in this document or any information which is made available in connection with any further inquiries, (ii) any error, omission, or inaccuracy in any such information, (iii) any action resulting therefrom or (iv) usage or acquisition of products. This disclaimer applies notwithstanding any negligence, default or lack of care.

Kima may update, modify or correct this document at its sole discretion, without notice or incurring any obligation or liability to any recipient hereof. This document is strictly confidential and intended to be viewed exclusively by those recipients (“Recipient/s”) specifically authorized by Kima. This document shall not bind, convey any rights, obligations, terms, performance, covenants, representations or warranties on behalf of Kima to Recipient, or create any relationship between Kima and any Recipient or any other party.

The Kima wardens manage Kima’s Liquidity Pools through the use of Threshold Signatures. The group wardens as well as the parameters of the Kima platform are controlled through the Kima Blockchain.

The Kima blockchain has four main goals:

1. Managing and updating the set of wardens.

2. Platform governance, e.g., choosing the blockchains and tokens that are supported, and setting fees.

3. Creating an auditable record. Every cross-chain swap will be recorded on the Kima blockchain (as well as the underlying chains) to create a secure audit trail and provide accountability for the wardens.

4. In the future it may enable smart-contracting. As Kima moves beyond its initial deployment, the platform will allow users to perform more than just simple cross-chain atomic swaps. The Kima smart-contracting platform will allow users to write contracts that control accounts across multiple blockchains from a single, unified environment

The Kima blockchain uses committee-based consensus, where a “committee” is selected to produce blocks and run the consensus protocol.

The committee-based consensus is particularly amenable to Kima’s notion of wardens as the set of wardens can be chosen to be the same as the consensus committee.

The Kima blockchain is built using the Cosmos SDK, which provides an excellent framework for developing customized blockchains that use committee-based consensus.

This architecture has been proven in systems like Axelar, Zeta chain, and Thorchain, all of which are built using the Cosmos SDK. The Tendermint consensus committee uses threshold signatures to maintain joint control of accounts on other blockchains. The Kima blockchain is powered by the KIMA token, which is used for staking and governance.

As in other Cosmos-based blockchains, a committee of validators is elected through stake-weighted voting. A core difference between Kima and many other Cosmos-based chains is that the committee also maintains threshold key shares for the signing keys controlling the liquidity pools on the connected chains.

To increase security, the Kima blockchain has multiple types of wardens/block producers, which are characterized by different ways they can be penalized for incorrect behavior. For instance, there may be legally-staked wardens, which are public entities that have undergone KYC and can be legally liable for misbehavior. There may also be reputation-staked wardens, which are also public, who have undergone KYC and stand to lose significant finances due to the reputation loss from misbehavior, for instance, professional block producers that operate on multiple chains. Then there may be token-staked wardens that are anonymous but qualify by holding enough (delegated) proof of stake, which can be slashed. The Threshold signing protocols can require thresholds from multiple types of warden for transactions to be executed (at least, from larger-asset pools). This allows Kima to combine the security advantages of KYC with those from standard token proof-of-stake systems. Thus a would-be attacker would need to control both a sufficient threshold of user-delegated stake and compromise several legally-liable well-known organizations.

Because Kima has a permissionless system for token-staked wardens, Kima wardens will change regularly. To avoid changing the pool contracts, Kima uses proactive secret sharing to allow the exiting wardens to pass their key shares onto the newly elected wardens without weakening the security of the system.

In addition to producing blocks on the Kima blockchain, the block producers are responsible for validating and recording events that happen on the connected chains. To do this, Kima block producers can run full nodes of each of the connected blockchains.

When users request cross-chain transfers, the committee is responsible for (1) recording the request on the Kima blockchain, (2) monitoring the source chain to ensure the deposit was received, (3) completing a threshold signature to release funds on the destination chain, and (4) recording the finalized process on the Kima blockchain.

The Kima consensus and the underlying threshold signature scheme provide an auditable record of the actions of the validators. Thus when a committee member misbehaves during the consensus protocol or during the threshold signature scheme, there is evidence of this misbehavior, and this can be presented as proof and used to slash the committee member’s stake.

Kima, which is being built using the Cosmos SDK, can take advantage of the IBC protocol to communicate with other IBC-enabled blockchains like the Cosmos Hub, Terra, Osmosis, Secret, and Oasis.

Lifecycle of a transfer

When a Kima user wishes to transfer tokens from a source chain to a destination chain

1. The user “approves” the Kima pool on the source chain. This will allow the Kima wardens to pull a specified number of tokens into the pool. This is achieved by calling approve(sourcePoolAddress, amount) on the ERC20 (stable coin) contract*.

2. The user submits a transaction request on the Kima blockchain, specifying the source address (and chain), the destination address (and chain), and the amount.

3. The Kima Wardens ensure that the liquidity pool on the destination chain has sufficient reserves and then initiate a transferFrom(sourceUserAddress, sourcePoolAddress, amount) transaction on the source chain to pull tokens into the Kima pool on the source chain. If this transaction fails, the Kima wardens will resubmit the transaction.

4. When the Kima Wardens observe the finalized token transfer on the source chain, they submit a transaction on the destination chain transferFrom(targetPoolAddress, targetUserAddress, amount), transferring tokens to the destination address. If this transaction fails, the Kima wardens will resubmit the transaction until it succeeds.

*Note that ERC20 tokens on EVM-compatible chains (like Ethereum, BSC, Polygon, Tron, Avalanche C-chain, Evmos, Moonbeam, and others) as well as Solana’s SPL tokens and Cosmos’ CW20 tokens all support approve and transferFromfunctionality.

This transaction flow ensures that the transaction on the source chain and the destination chain is initiated by the Kima wardens. This allows the Kima wardens to ensure that they will never accept incoming token transfers if there is insufficient liquidity on the destination chain to fulfill the transfer.

This solution is also extremely composable. Kima wardens could, at the user’s request, perform multiple actions on either the source or destination chain (e.g., to interact with native DeFi primitives on either chain), always guaranteeing that the entire sequence of steps happens atomically. The actions on both the source and destination chains can be linked — the Kima wardens ensure that the (atomic) sequence of transactions on the destination chain is not initiated unless the (atomic) sequence of transactions on the source chain completes successfully.

Liquidity pools

Avoiding token wrapping requires maintaining liquidity pools on each of the destination chains supported by Kima .

On-chain liquidity is provided by liquidity providers in exchange for LP tokens. Initially, Kima will focus only on stable pairs, e.g., USDC on Ethereum for USDC on Solana or BTC for WBTC on Ethereum, so liquidity providers will not be at risk of impermanent loss.

Liquidity providers receive LP tokens which entitle them to a share of the fees generated by the Kima platform.

The on-chain liquidity pools are controlled by the wardens using a Threshold Signature Scheme.

Bridge hacks

Bridges are high-value targets, attracting competent hackers and hacking groups and even state-sponsored hackers. There have been several high-profile thefts from bridges in the past few years.

In most cases, the attackers exploited logical errors in the source contract (which handles deposits) or the destination contract (which handles minting and burning synthetic assets).

The one exception to this was the Ronin hack where the actual warden keys were compromised.

Security

The Kima platform maintains large liquidity pools across multiple different layer-1 blockchains, and wherever there is pooled capital, there is an attendant risk. This section lays out the main types of risk faced by Kima and the steps taken to mitigate that risk.

Malicious wardens

The wardens control all funds held in Kima pools and are the only entities that can move tokens out of the pools, thus it is of critical importance to protect the system against malicious (or otherwise compromised) wardens. Kima uses the following features to protect against malicious wardens.

1. The use of threshold signatures ensures that wardens can only move funds if a quorum of wardens has authorized the transfer.

2. Kima has different types of wardens, based on whether their stake is through KYC and real-world penalties or whether their stake is based on (delegated) staked tokens. The TSS will require transactions (at least from certain large-capacity pools) to need participation from multiple types of wardens. For instance, a transaction signature may require participation from 2-out-of-5 legally-staked wardens and 7-out-of-10 token-staked wardens.

3. The use of SGX enclaves enforced that wardens can only deviate from the prescribed behavior by breaking the security of an SGX enclave.

4. Kima wardens have high concrete financial penalties if they misbehave. For instance:

   1. Legally-staked wardens can be sued.

   2. Reputation-staked wardens would lose profits, such as professional block producers that operate on multiple chains (most do), which would lose revenue on other chains.

   3. Token-staked wardens would be slashed.

Smart contract risk

The Wormhole bridge uses multisigs (as opposed to threshold signatures) to control its asset pools. This dramatically increases the complexity of the on-chain code, and also the risk of smart-contract vulnerabilities.

In the early days of Ethereum, the parity multisig wallet contract was hacked, allowing attackers to steal over 150,000 ETH.

More recently, the Wormhole exploit took advantage of the complexity of the on-chain code used to verify multiple signatures and allowed attackers to steal 120,000 ETH.

Kima does not use multisigs. Instead it uses threshold signatures, which means Kima can hold assets in extremely simple contracts, or even EOAs, which minimizes this attack surface.

Impermanent loss

In order to facilitate cross-chain transfers without token-wrapping, Kima manages liquidity pools across multiple different blockchains.

As users transfer funds between these pools, liquidity providers can be at risk of impermanent loss. In fact, in Uniswap v3, the average liquidity provider saw negative returns due to impermanent loss.

Kima liquidity providers are not subject to impermanent loss, because Kima’s cross-chain swaps are swapping assets of equal value (e.g. USDC on Ethereum for USDC on Solana).

Block Reorgs

The Nakamoto consensus only reaches eventual finality, meaning that blocks (and the transactions within them) can be rolled back. These “reorganizations” can affect the final blocks in a chain. The table below gives a list of blockchains achieving instant finality.

When transferring tokens from blockchains that only achieve eventual finality, the Kima liquidity pools are at risk since a deposit transaction on the source chain could be reorganized out of the chain after the corresponding withdrawal on the destination chain was finalized. Although chain reorgs are possible, deep reorgs are not a regular occurrence. The table below shows the number of reorgs by depth as reported by Etherscan.

Reorgs, by themselves, are not a problem. If an honest user’s deposit has been reorganized out of the source chain, the same deposit transaction can be included in a later block. The core problem is that malicious users can take advantage of a reorg to execute a double-spend attack by emptying their accounts before the deposit to the Kima pool is eventually confirmed on the newly confirmed blockchain. In extreme cases, malicious users could attempt to initiate a reorg to execute double-spend attacks. To date, successful double-spend attacks have been perpetrated on small chains (like Ethereum Classic), but no double-spend attacks have ever been recorded on Bitcoin or Ethereum.

Note that transferring tokens to blockchains that only achieve eventual finality does not pose a risk to Kima. If Kima wardens release tokens on the destination chain, and that transaction is reorged out, the wardens can simply resend the transaction.

The risk of reorgs on the source chain will always be a risk when transferring tokens from a chain that only has eventual finality (e.g., Bitcoin or Ethereum) – there is no way to eliminate it completely. The risk of reorgs can be reduced by waiting for additional confirmations on the source chain, but excessive waiting degrades the user experience.

Although the risk of reorgs cannot be completely eliminated, it can be partitioned and managed, and Kima has taken the following steps to mitigate the risk posed by reorgs:

1. Variable confirmation thresholds: To minimize risk without degrading the user experience, Kima wardens use variable confirmation thresholds when deciding whether a transaction on the source chain is finalized. For example, low-value deposits can be accepted with fewer confirmations than high-value transactions. This is the approach taken by Thorchain, where the number of confirmations needed to finalize an Ethereum transaction is proportional to the transaction size. Similarly, deposits from known and trusted entities can be finalized with a lower threshold of confirmations than deposits from unknown or untrusted sources.

2. Warden stake: All Kima wardens maintain a stake, and if wardens finalize a transaction that is eventually reverted on the source chain, the warden stake can be slashed to reimburse liquidity providers who lost funds. This slashing mechanism provides a tool for allocating risk between wardens and liquidity providers and can be tuned by on-chain governance.

3. Insurance: The Kima insurance pool can protect traders and liquidity providers against the risk of double-spend attacks in the same way it protects against other forms of protocol risk.

The Kima platform provides seamless cross-chain interoperability without token wrapping.

To avoid creating synthetic (“wrapped”) tokens on each chain, Kima maintains liquidity pools on each integrated layer-1 blockchain (e.g., Bitcoin, Ethereum, Terra, and Solana). A user who wishes to send an asset (e.g., USDC) from one chain (e.g., Ethereum) to another (e.g., Solana) will send USDC to Kima’s USDC pool on Ethereum and withdraw USDC from Kima’s USDC pool on Solana.

The core of the Kima platform is the Kima blockchain which monitors and synchronizes assets across multiple existing layer-1 blockchains.

The Kima blockchain uses committee-based consensus. Each committee consists of a rotating set of “wardens” whose role is to ensure the asset pools remain in sync, withdrawals from a pool on the destination chain are only authorized when a corresponding deposit has been confirmed on the source chain.

Kima wardens control the asset pools on the destination chain through the Threshold signature schemes (TSS). Security is strengthened by running the wardens inside a Trusted Execution Environment.

Threshold signatures

Threshold signature schemes (TSSs) allow a group of participants (“cosigners”) to securely generate and control the secret signing key for a digital signature scheme, such that a certain threshold (e.g., 7-out-of-10) cosigners must participate in the signing protocol to generate a signature.

Specifically, a threshold signature scheme consists of two protocols - (1) Distributed Key Generation and (2) Distributed Signature Generation.

The Distributed Key Generation protocol creates private “key shares,” where each participant holds a single share and a single public verification key for a digital signature algorithm (either ECDSA or ED25519).

The Distributed Signature protocol takes each participant’s key share and a (public) message and creates a digital signature on the message that will verify under the verification key created during the key generation protocol.

The “threshold” property comes from the guarantee that there is a fixed threshold (e.g., $t$-out-of-$n$) such that an adversary who corrupts up to t participants in the protocol (and learns their private key shares) learns nothing about the underlying secret key. In particular, an adversary who corrupts $t$ or fewer participants cannot generate a new signature on any message.

Threshold Signature protocols can be extended to arbitrary authority structures. For instance, there could be a set of $n_1$ highly-trusted signers (e.g., signers that have undergone KYC and have a real-world reputation at stake) as well as a larger set of $n_2$ anonymous signers that are chosen dynamically through on-chain staking. The TSS could then be built so that it needs both $t_1+1$ public signers AND $t_2+1$ anonymous signers to participate in order for a statement to be signed. Any adversary then who does not control this learns nothing of the underlying secret key and is unable to forge signatures.

Furthermore, TSS protocols can use Proactive Secret Sharing to periodically re-randomize the shares of the secret key. If an adversary compromises a few of the wardens and so learns a few shares of the secret key before the re-randomization, this knowledge will not help it learn shares of the secret key after re-randomization. Essentially, this means each re-randomization causes the adversary to have to restart from zero in its efforts to learn secret shares. Thus, as long as the adversary isn’t able to learn the full secret key between any pair of re-randomizations, it will never learn the secret key or be able to make new signatures.

Proactive Secret Sharing strictly increases the security of the system, protecting against an adversary who is able to compromise some nodes but is never able to compromise above a certain amount within a certain time window.

Threshold signature schemes exist for ECDSA and ED25519. In addition to rigorous theoretical proofs of security, TSS schemes have been widely implemented. In fact, professionally audited, open-source TSS libraries are available from Axelar, ZenGo, ING bank, Binance, Thorchain, Ren, and Coinbase. Collectively, these TSS implementations are currently used to custody billions of dollars worth of tokens across multiple blockchains.

Although attacks are common in the DeFi space, there have been no reported attacks that have exploited a Threshold Signature Scheme.

Trusted Execution Environments

Trusted Execution Environments (TEEs) provide hardware-based security where secrets can be stored and code can be executed in a secure and verifiable manner. The key properties of a TEE are:

1. Privacy: Data processed inside the TEE cannot be accessed by external programs, system administrators, or attackers who have physical access to the machines.

2. Transparency: TEEs can “attest” to the code they are executing, thus the output of a TEE can be publicly verified.

The most common TEE is Intel SGX which is available on a wide variety of Intel CPUs. Microsoft Azure supports Intel SGX in its cloud instances.

It is possible to use TEEs to bring privacy to the blockchain. In almost all blockchains, every transaction is public. However, it is possible to make transactions private by running all nodes inside TEEs. This not only prevents malicious behavior by operators but even allows all transactions to be encrypted (except when inside the TEE), keeping transaction details hidden even from the operators themselves. This has been done in practice: both the Secret Network and Oasis Cipher Paratime use Intel SGX to facilitate private smart contracts on Cosmos-based blockchain.

TEEs can also significantly improve security by holding keys, or shares of keys, inside of the TEE. For instance, the Avalanche Bridge implements a 3-out-of-4 threshold signature scheme inside Intel SGX enclaves. While transactions remain public, this dramatically reduces the trust in the (anonymous) bridge “wardens” by generating and storing each warden’s key share inside an SGX enclave. Using this combination of TSS and SGX, the Avalanche Bridge wardens are custoding over $5.7B worth of assets on the Ethereum blockchain.

Intel Skylake, one of the CPUs that supports Intel’s Trusted Execution Environment SGX

Although Intel SGX is very powerful, it is not a panacea – there have been several high-profile attacks against SGX enclaves, and even in the absence of attacks, relying on Intel for security provides an unwanted and unnecessary point of centralization. Nevertheless, SGX dramatically increases the difficulty of attacking a system.

Kima does not rely on the security of Intel SGX to maintain the privacy or safeguard its assets. Instead, Kima uses SGX to complement the security of its system. Kima wardens run the threshold signature scheme inside an SGX enclave. Thus the TSS key shares are not directly accessible to the wardens or system administrators. Instead, the key shares are held inside SGX enclaves, and the entire multiparty key generation and signing protocols are run inside the enclaves. This strictly improves the security of the underlying threshold signature scheme. In a t -out-of-n threshold signature scheme, security holds as long as no more than t wardens collude to subvert the protocol. When the TSS protocol is run inside SGX, to break security t+1 wardens would need to first break the security of SGX and then collude. Breaking SGX, though not impossible, is very challenging and typically requires physical access to the host machine and significant expertise, significantly raising the barrier to entry for a would-be malicious warden. Thus by implementing the threshold signature scheme inside an SGX enclave, Kima can significantly boost security with only a negligible loss in performance.

Several projects are helping users move liquidity across chains. Some are simple “bridges” while others, like Axelar, Thorchain, and Zetachain have their own native blockchain that allows for cross-chain smart contracts. Most focus on transferring value through token wrapping (with the exceptions being Stargate, Chainflip, and Thorchain). Most use Threshold Signatures (TSS) instead of multisignatures, with being the main outlier. Stargate is built on LayerZero, and LayerZero’s message passing will be built on Chainlink oracles. It appears that ; however, if Stargate moves to Chainlink as an oracle provider, Stargate will rely on Chainlink security. Chainlink has, to some extent, adopted Threshold Signatures (“”), and SGX (), so in principle, Stargate could use these features, but they are not widely used (and not currently mandated) by the Chainlink ecosystem.

Kima is a new solution to inter-chain asset transfer that avoids token wrapping using liquidity pools, thus bringing real unification of blockchain networks. These valuable liquidity pools are protected using a suite of powerful security tools: Threshold signatures, Trusted Execution Environments, and multi-type staking. Kima also has techniques to address other issues such as impermanent loss, smart contract risk, and transaction atomicity. Thus Kima offers a powerful security solution to liquidity fragmentation, allowing for much-needed interoperability in the blockchain space.

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.

Asset wrapping

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.

Liquidity pools

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.

Ensuring sufficient pool reserves

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.