Blockchains are siloed. Web3 apps built within those ecosystems are constrained by their on-chain liquidity. Many of the solutions developed for these challenges - known as bridges - suffer from flaws and vulnerabilities: security, user experience, complexity, and poor capital efficiency.

Kima addresses these challenges in a unique way, by creating a Web3 settlement layer, which enables interchain transactions. With this novel approach, liquidity can be transferred between chains in a safe, secure, and cost-effective manner - enabling the most reliable omnichain solution.

There are two key concepts that distinguish the Kima solution: Its unique security is achieved by eliminating all known attack vectors (no smart contracts, no oracles, no external relayers) and adding multiple layers of security (such as using a Trusted Execution Environment (using Intel SGX) and decoupled validation). As a result, the protocol uses game theory and financial incentives to maintain the liquidity equilibrium and maximize capital efficiency.

As a result, Kima's infrastructure simplifies and speeds up the creation of secure Omnichain applications.

We will discuss Kima's incentive scheme in the following 3 pages:

A. Incentive Scheme: Liquidity Penalties and Bounties

B. Incentive Scheme: Protection Mechanisms

C. Incentive Scheme: Passive and Active Liquidity Providers

In this example, our user (Jane) wishes to send USDC from her address on Ethereum to her address on Solana. She wants the transaction to happen quickly, securely, and cheaply - and she wants to be sure the transaction did occur (“transaction certainty”).

For this purpose, the Kima protocol should automatically adjust the liquidity level desired in the pools per the following rules:

• Maintain a lower bound on liquidity in active pools, allowing for low-fee, quick transactions and quickly replenishing them if the level falls below this lower bound

• Maintain minimal liquidity in low activity pools

• Easily identify inactive pools becoming active and active pools whose activity is diminishing and update the liquidity thresholds accordingly

Passive Liquidity Providers deposit liquidity into the system for some time. They earn a portion of the system fees throughout this period (see “Incentive Scheme”).

Active Liquidity Providers can collect bounties in return for depositing into prioritized pools. They can choose to withdraw their deposited funds shortly after, from the same pool or a different one, or maintain their liquidity position in the system, enjoying their portion of the fees collected while they do so. By being Active Liquidity Providers, who follow the system priorities and move liquidity around, they enjoy another source of income - liquidity bounties - on top of fee income.

The Kima platform relies on Active Liquidity Providers to accomplish this through an incentive scheme.

Kima is a blockchain that tackles the interoperability problems found in existing solutions without causing additional liquidity fragmentation. Kima addresses this problem by providing a simple, secure mechanism for allowing users to perform cross-chain atomic swaps without token-wrapping.

The Kima blockchain is built using the Cosmos SDK, which provides a steadfast framework for developing a custom blockchain. The Kima blockchain uses committee-based consensus, where a “committee” is selected to produce blocks and run the consensus protocol. Each committee consists of a rotating set of “wardens” whose role is to ensure the asset pools remain in sync and 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 through the use of Threshold Signature Schemes (TSS). Security is strengthened by running the wardens inside a Trusted Execution Environment. The group wardens and the parameters of the Kima platform are controlled through the Kima blockchain.

To avoid creating synthetic (“wrapped”) tokens on each chain, Kima maintains liquidity pools on each integrated layer-1 blockchain (e.g. Ethereum, Polygon, Solana). The Kima protocol, run on the Kima blockchain, monitors and synchronizes assets across these layer-1 blockchains.

The Kima blockchain is both permissioned and permissionless. The permissioned layer includes validators approved by Kima and known for their reliability - e.g. funds, banks, organizations, etc. The second layer of the Kima blockchain validators is permissionless, allowing anyone with enough (delegated) stake to become a block producer (and warden). The permissionless nature of the Kima blockchain means that the set of wardens will change regularly.

The 2 layer consensus mechanism archives stability, security, and decentralisation.

The Kima blockchain has four main goals:

1. To manage and update the set of wardens for the committee-based consensus.

2. To execute platform governance, e.g. choosing the blockchains and supported tokens, setting fees, etc.

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

4. To enable cross-chain messaging. As Kima moves beyond its initial deployment, it will enable users to perform more than just simple cross-chain atomic swaps. The Kima messaging platform will allow users to interact with contracts across multiple blockchains from a single, unified environment.

When users request cross-chain transfers, the warden 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

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 (committee of wardens). Thus, if a committee member misbehaves during the consensus protocol or the threshold signature scheme, there is evidence of this misbehavior. This can be presented as proof and used to slash the committee member’s stake.

This architecture has been proven in Cosmos SDK-built systems like Axelar and Thorchain. As in other Cosmos-based blockchains, a committee of validators is elected through stake-weighted voting. 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.

Kima’s infrastructure offers a seamless cross-chain transfer of digital assets via running a network of decentralized liquidity pools. By creating and managing liquidity pools across several Layer 1 and Layer 2 blockchains, value can be transferred 1:1 without relying on synthetic/wrapped assets or centralized players. The Kima protocol monitors and synchronizes assets across these blockchains via a decentralized settlement layer and provides a simple and secure mechanism for allowing users to perform cross-chain atomic transfers and swaps without token wrapping.

This example will assume that the Kima has established pools on three Layer-1 blockchains (A, B, and C). With Kima, users can transfer assets between addresses on:

• Blockchain A and B (i.e., exchanging USDT on Ethereum for USDC on Solana and vice versa)

• Blockchain A and C (i.e., exchanging USDT on Ethereum for BUSD on the Binance Blockchain and vice versa)

• Blockchain B and C (i.e., exchanging USDC on Solana for BUSD on the Binance Blockchain and vice versa)

For Kima’s service to work well, all pools must have sufficient liquidity to support withdrawals and be adaptive to the market movements. The Kima protocol monitors and take the following actions:

• If a pool receives several withdrawal requests, it should be replenished.

• If there is too much liquidity in the pool, it should be decreased to maximize capital efficiency.

• If there is a strong demand for withdrawals from a pool (i.e., Pool B), the other pools' liquidity can be directed there to address demand.

The Kima blockchain stores up-to-date information of all pools and optimally transfer assets between pools as needed. In this case, optimal refers to both the quality of service (i.e., provide liquidity when/where needed) and the protocol’s availability to address financial risk and minimize both the costs and the amount of liquidity locked within the blockchains.

While the Kima protocol can automatically monitor and manage the pools, it will require strong relationships with external liquidity providers. We have designed an incentive scheme for these players that aligns with their motivations and our desired behaviors (i.e., helping replenish or move liquidity as needed).

The following section explores how liquidity providers are motivated to move liquidity from over-funded pools to pools that need replenishment and how users can use the Kima platform and services.

The goal of the Kima infrastructure is to allow for the efficient and secure transfer of assets between blockchains.

At this time, there is no option to transfer original assets between blockchains. Instead, a user will deposit the original asset into a service (such as a cross-chain bridge) on blockchain A and receive a similar/matching asset at the address on blockchain B.

To do this, the user can:

1. Utilize the service of a centralized exchange (such as Coinbase) or an OTC desk, which will manage the exchange of asset A for asset B.

2. Use a cross-chain bridge, which creates a synthetic asset on blockchain B to match the original asset deposited on blockchain A.

3. Use a direct messaging service. Assuming the assets are natively available on two blockchains, a service or user can implement a smart contract that allows blockchain A to message blockchain B. Blockchain A would send a message once the original asset has been deposited on Blockchain A, and Blockchain B would then release the matching asset on Blockchain B.

We will go into the vulnerabilities and issues of these existing solutions in the following sections. Our position is that token-wrapping and cross-chain bridges only increase the liquidity challenges and lead to liquidity fragmentation across blockchains.

Preface

Kima's Liquidity Management Algorithms (LIMA) is a set of algorithms running on the Kima blockchain, collecting data from Kima's pools, calculating the optimal liquidity positions of every pool, and based on that the related penalties and bounties.

LIMA calculates these parameters for every pool:

K1 - the lower bound of the optimal liquidity of the pool

K2 - the upper bound of the optimal liquidity of the pool

K3 - the maximum liquidity of the pool

As we will see, the LIMA rebalancing algorithms reduce financial risks for liquidity providers and maximize capital efficiency for users.

Penalties and Bounties

Let us establish that our user (Jane) wishes to send USDT from her address on Ethereum to her USDC address on Solana. By doing so, she is, in fact, requesting liquidity from the USDC pool on Solana. If the liquidity is below the pool optimal liquidity level, as calculated by LIMA (in the diagrams below, the range between K1-K2), Jane request to take liquidity (“Taker”) is charged a “taker penalty.”

This penalty grows as the requested amount reduces liquidity further below the optimal liquidity. As the liquidity level approaches zero, extracting an asset from this pool becomes significantly more expensive.

Similarly, if the liquidity is below the optimal level, a transaction that deposits USDC to the pool earns a bonus - a “maker bounty.” The bounty decreases as liquidity decreases and approaches the optimal liquidity.

The “taker penalty” is higher than the “maker bounty”, which means that the protocol collects (in advance) more than it needs to pay out in bounties for replenishment (or grooming) of the pools.

As long as the liquidity in the pool is optimal (between K1 and K2), the pool is in equilibrium and depositing into the pool earns no bounty, and withdrawing from the pool does not cost a penalty. In this case, Jane’s only cost to transfer assets is the Kima network fee (0.05%).

In summary, her total cost would be:

Fee = Taker Penalty | Bounty + Network fee - Maker Penalty | Bounty

Network fee = 0.05% of the transfer amount.

The diagram below describes a pool Maker and Taker Bounties and Penalties behavior:

Click the image to enlarge.

Liquidity Taking (Withdrawals):

• A taker withdrawing $a below K1 pays a penalty that increases as liquidity approaches zero

• A taker withdrawing $b above K1 and below K2 pays no penalty (just the network fee)

• A taker withdrawing $c above K2 receives a bounty that grows as liquidity is further above K2

Liquidity Making (Deposits):

• A maker depositing $a below K1 receives a bounty that grows as liquidity approaches zero

• A maker depositing $b above K1 and below K2 receives no bounty

• A maker depositing $c above K2 pays a penalty that grows as liquidity is further above K2

As can be seen, transactions taking place between K1 and K2 do not incur penalties. However, as soon as liquidity goes out of this range (meaning someone paid the penalty), there is an incentive for someone else to bring the liquidity back to the K1-K2 range and collect a bounty.

K2 is much larger than K1, allowing for large transfers to pass, paying only the network fee and no penalties. As a result, in rare scenarios a transaction can be charged a deposit penalty. K2 serves as an upper limit for liquidity to ensure a pool’s balance does not grow too much (and out of alignment with the market). It is also a failsafe mechanism to ensure the Kima platform is protected against extreme dumping scenarios. Specifically, when the assets in the pool are stablecoins (e.g., USDT, USDC, or DAI), this protects the system against players who seek to dump off-pegged stablecoins in one pool and extract pegged stablecoins from another pool. This event's overall risk and cost has an upper limit K3. Specifically, at some point above K2, depositing into the pool will incur a penalty that equals the value of the deposited assets, making the transaction uneconomic for the depositor.

The penalty and bounty curves adapt dynamically to the activity in the pool. As activity in the pool increases or decreases, the actual values K1, K2, and K3 change accordingly.

Higher activity means more transfer volume which will increase K1, K2 and K3 proportionally. A decrease in activity will contract the curve, decreasing K1, K2, and K3

The Kima platform has several built-in mechanisms for protection and automation, geared towards users and liquidity providers.

First, users can define a Maximum Fee Limit to ensure their transaction is executed only when the fee does not exceed the limit.

If transactions cannot be executed in the current block (due to the fee being too high), the deposit to blockchain A will be executed, and the withdrawal from blockchain B will be considered for the next B chain block with a defined number of retries.

Similarly, liquidity providers can deposit liquidity to blockchain A with no withdrawal from blockchain B or another chain. In this case, they can set a Minimal Bounty Limit, below which the transaction will not be executed. The transaction can also wait for the next A chain block with a retry limit.

In the Kima system we use these parameters:

• Each transaction pays a Network Fee of 0.05% of the transaction value, which is Network Fee Income.

• Penalties are double the Bounties, which means half of the Network Penalty Income is paid to Active Liquidity Providers as Liquidity Bounties.

• Network Fee Income is divided between Liquidity Providers (50%), Kima Validators (25%), and the Kima Foundation (25%).

• Network Penalty Income is divided between Active Liquidity Providers as bounties (50%), Kima Validators (25%), and the Kima Foundation (25%).

The Kima protocol prioritizes liquidity provider transactions to secure the liquidity bounty and reduce costs for subsequent withdrawals. This makes bounties easy to win and low-risk, which we believe will encourage liquidity providers to build machines that follow liquidity levels and execute to make an optimal profit. As long as it is easy and profitable for a liquidity provider to deposit an asset and collect a bounty, and it can be done quickly, we can rely on the system incentives to guide liquidity to where it is desired, maintaining at least a level of K1 liquidity (the lower boundary of the optimial liquidity level) for all pools. The high quality of service and the low fees on well-funded pools (pools well above K1) generate an attractive business case for Liquidity Providers, who earn a portion of the costs.

Liquidity providers provide liquidity to the Kima protocol by sending Liquidity Provision transactions and depositing an amount into one of the system’s pools. Such liquidity providers can generate a return in two complementary ways:

Passive Liquidity Providers (PLPs)

A PLP sends liquidity to one of the Kima pools. This transaction might win her a bounty if sent to a pool where liquidity is needed (pool balance is below K1). From that point, until the PLP decides to withdraw her liquidity, she earns a portion of the network fees collected on the entire system (0.05% of the transaction amount).

The Kima protocol is designed to achieve high capital efficiency - a high ratio of transfer volume per dollar of liquidity - which directly translates to a higher return for PLPs (more fees to the dollar). This is a passive strategy, which does not require any decision-making from the PLP and generates ongoing returns from the network fee income.

Based on our simulations, $1m of daily volume would yield $500 in network fees per day (or $182,500 per year), with half going to the PLPs ($91,250 annually). If capital efficiency is high and $100,000 of liquidity is enough to support the volume level (10:1), the yearly return for passive liquidity providers is 91.25%.

Active Liquidity Providers (ALPs)

A liquidity provider can take an active part and act as an ALP. ALPs move liquidity between pools: taking liquidity out of over-liquid pools and moving it to where it’s needed.

In order to do so, such ALP should monitor the state of the system pools, and constantly withdraw and deposit funds following the protocol's incentives. By doing so, ALPs can boost their return by collecting liquidity bounties on top of the passive strategy liquidity fees income.

The Kima protocol prioritizes ALP transactions to secure liquidity and reduce costs for subsequent withdrawals. This makes bounties easy to win and low-risk, which would encourage ALPs to build automated strategies (bots) that follow liquidity levels and execute to make an optimal profit. As long as it is easy and profitable for an ALP to deposit or withdraw an asset and collect a bounty, and if it can be done quickly, we can rely on the system’s incentives to guide liquidity to where it is desired, maintaining at least a level of K1 liquidity for each pool and grooming excessive liquidity from where it is not needed (above K2 - the upper boundary of the optimal liquidity level).

Quality of Service (QoS)

We define Quality of Service as “just enough” and “just in time” liquidity to support users’ demand, incurring minimum fees.

The QoS for users who perform transfers is derived from the pools' liquidity levels. For small transfers, if the destination pool balance is just above K1, the transaction goes through with no penalty at all, or a small penalty.

However, if the balance is close to K1, larger transactions would be asked to pay larger penalties. For very large transactions to go through, the liquidity in the pool should be well above K1. Thus, higher liquidity attracts larger transactions, generating larger fee income.

The purpose of running the simulations is to test the system’s behavior and benchmark its performance and business KPIs. For the purpose of simulation, the Kima team researched existing activity on various cross-chain bridges to characterize the demand for cross-chain transfers.

The team identified the distributions that best describe the pools' historical data, comparing various distribution types. The log-normal distribution has proven to be the best fit for historical data distributions.

The following scatter plot shows the estimated log-normal distribution parameters (scale and shape) for transfers of several assets on the three networks - Ethereum, Polygon, and Optimism.

Each dot in the chart represents a pool (USDT, USDC, WETH, etc.), with corresponding scale and shape values that describe the pool’s distribution. As can be seen, Ethereum pools tend to have higher scale values since transfers tend to be bigger, which can be understood as a consequence of high gas fees making small transfers uneconomical.

Benchmark Simulation

The following describes a benchmark simulation that uses simulated data based on the estimated log-normal distributions. In this simulation, there is one asset that can be transferred across three networks. There are three pools in this simulation, one for each network (A, B, and C). We generate random transactions for AB, BA, AC, CA, BC, and CB. Transactions are generated from a log-normal distribution with the chosen scale and shape parameters.

In the following chart, the scale and shape parameters were chosen to represent current market demand (left-hand side of the scatter plot presented above).

The X axis is simulation time.

The Y axis shows pool balances A, B, and C as different colors and the pools’ corresponding K1 - the lower threshold for liquidity for each pool.

We see that pools reach below K1, up to the Maximum Fee Limit set by users, and tend to recover above K1 because of the incentive structure. Whenever pool liquidity falls below K1, the pool charges penalties, followed by paying bounties.

Benchmark Quality of Service and business KPIs

Based on a given transfer demand, characterized as a distribution with scale and shape parameters, we analyze how liquidity provision impacts the system performance and the expected return for LPs.

In this simulation, the liquidity in the system is set at the start. We ran multiple simulations with higher initial liquidity, keeping the demand (transaction distributions) the same across simulations.

The LPs in this simulation are passive. They provide the initial liquidity and enjoy the fee income. More liquidity in the system increases the quality of service for users: fewer transactions are rejected due to lack of liquidity or high penalties. At the same time, increasing the liquidity while keeping the demand constant may have a dilution effect, which decreases the return for the LPs - as the rewards are distributed to more LPs.

The following charts show the impact of increasing liquidity (X-axis) and the liquidity provider’s return - APR% (left Y-axis), and transfer quality of service as measured by rejection rate (right Y-axis).

The return is calculated as the LP fee income divided by the liquidity provided and normalized to yearly terms.

The results of the simulations confirm the expected system behavior:

• Low liquidity level (X-axis) relative to the demand results in a high rejection rate (right Y-axis)

• Increasing liquidity decreases the rejection rate and improves the quality of service

• By increasing liquidity, LPs increase the Quality of Service at the cost of return (the dilution effect), but can still enjoy lucrative 2-figure returns

The red circle in the chart above corresponds to (roughly) 10:1 capital efficiency, which generates a return of ~90%. This level of liquidity (2.2 times the average hourly volume) maintains a 97% quality of service level (3% rejection rate).

The above simulation does not yet account for additional mechanisms to improve the system’s efficiency. Specifically, meeting higher QoS and higher returns with less liquidity. This can be achieved by incentivizing Active Liquidity Providers to move liquidity to where it is most needed.

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 risk 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. Kima is using one-sided pools, i.e. in each pool there is only 1 asset, and thus LPs are not exposed to impermanent loss.

Initially, Kima will use stablecoins - assets with similar value (e.g. swap USDT on Ethereum for USDC on Solana), which reduces arbitrage risks. In addition, Kima's fee mechanism disables arbitrage opportunities, as fees go higher than the tokens' price difference.

¹Stefan Loesch, Nate Hindman, Nicholas Welch, and Mark B. Richardson. Impermanent loss in uniswap v3. Technical report, Topaze Blue, 2021.

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.

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.

Reorgs, by themselves, are not a problem. If an honest user’s deposit was reorganized out of the source chain, the same deposit transaction could 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. 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. 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. If wardens finalize a transaction that is eventually reverted on the source chain, the warden stake can be slashed to reimburse liquidity providers whose funds were lost. This slashing mechanism provides a tool for allocating risk between wardens and liquidity providers and can be tuned by on-chain governance.

3. Insurance: Setting an 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.

¹Satoshi Nakamoto. Bitcoin whitepaper.https://bitcoin.org/bitcoin.pdf, 2008.

²https://www.coindesk.com/markets/2020/08/07/ethereum-classic-attacker-successfully-double-spends-168m-in-second-attack-report/

³https://www.gemini.com/cryptopedia/double-spend-attacks-bitcoin

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.

1. 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.

2. Contract Vulnerabilities

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.

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.

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.

¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ¹⁰ ¹¹Stevie Woofwoof. Osmosis town hall — choosing a bridge service provider., 2022.

¹² ¹³

The Kima platform is designed with the most advanced security protocols and instruments available today. It stands apart in its design due to its use of two security mechanisms: threshold signatures and trusted execution environments. Kima wardens control the asset pools on the destination chain through the use of Threshold signature schemes, and security is further 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 in order to generate a signature. Specifically, a threshold signature scheme consists of two protocols (1) Distributed Key Generation and (2) Distributed Signature Generation.

Distributed Key Generation Protocol 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).

Distributed Signature Generation Protocol The Distribute 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.

Implementation of Protocols For a Threshold Signature Scheme 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 public set of n1 signers that have undergone KYC and a larger set n2 of anonymous signers that are chosen dynamically through Proof of Stake. The TSS could then be built so that it needs both t1 + 1 public signers AND t2 + 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 redistribute shares of the secret key. This means that if an adversary is unable to learn the secret key before a redistribution, all the information it gained before the redistribution becomes useless after the redistribution. For instance, if we have a t-out-of-n sharing of the secret key, the adversary can corrupt t nodes before the redistribution and another t after, but will still not be able to learn the secret key. Proactive Secret Sharing strictly increases the security of the system, by improving protection against adversaries who corrupt multiple nodes over time.

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¹³.

In the blockchain space, Intel SGX has been used to increase user privacy as well as improve security. On the privacy front, both the Secret Network¹⁴ and Oasis Cipher Paratime¹⁵ use Intel SGX to facilitate private smart contracts on Cosmos-based blockchains. On the security front, the Avalanche Bridge implements a 3-out-of-4 threshold signature scheme inside Intel SGX enclaves¹⁶. This does not improve the privacy of the bridge but instead 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 custodians of more than $5.7B worth of assets on the Ethereum blockchain¹⁷.

To provide transaction privacy in a blockchain using committee-based consensus, each block producer can run their nodes inside an SGX enclave. Using Intel’s attestation feature, every block producer can verify that all the other committee members are running the authorized blockchain client inside an SGX enclave. The enclaves can generate key-pair(s) for a public-key encryption protocol that allows users to encrypt their transactions before sending them to a node. Upon receiving an encrypted transaction, the transaction can be decrypted and validated inside the SGX enclave. The security of SGX guarantees that even the block producers themselves cannot decrypt the encrypted transactions.

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.

Kima does not rely on the security of Intel SGX to maintain its 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 their 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 as well. 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 would need to first break the security of SGX and then collude. Thus by implementing the threshold signature scheme inside an SGX enclave, Kima can significantly boost security with only a negligible loss in performance.

¹Joshua Baron, Karim El Defrawy, Joshua Lampkins, and Rafail Ostrovsky. Communication-optimal proactive secret sharing for dynamic groups. In International Conference on Applied Cryptography and Network Security, pages 23–41. Springer, 2015.

²Rosario Gennaro and Steven Goldfeder. One round threshold ECDSA with identifiable abort. IACR ePrint Archive, 2020.

³P. M. Hallam-Baker. Threshold signatures using Ed25519 and Ed448. Technical report, IETF, 2020.

⁴https://github.com/axelarnetwork/tofn

⁵https://github.com/ZenGo-X/multi-party-ecdsa

⁶https://github.com/ing-bank/threshold-signatures

⁷https://github.com/bnb-chain/tss-lib

⁸https://github.com/thorchain/thorchain-tss

⁹https://github.com/renproject/mpc

¹⁰https://github.com/coinbase/kryptology

¹¹Victor Costan and Srinivas Devadas. Intel SGX explained, 2016.

¹²https://github.com/ayeks/SGX-hardware

¹³https://azure.microsoft.com/en-us/updates/intel-sgx-based-confidential-computing-vms-now-available-on-azure-dedicated-hosts/

¹⁴https://scrt.network/graypaper

¹⁵https://github.com/oasisprotocol/cipher-paratime

¹⁶Conor Leary. Avalanche bridge: Secure cross-chain asset transfers using Intel SGX.https://medium.com/avalancheavax/avalanche-bridge-secure-cross-chain-asset-transfers-using-intel-sgx-b04f5a4c7ad1,2021.

¹⁷https://etherscan.io/address/0xe78388b4ce79068e89bf8aa7f218ef6b9ab0e9d0

¹⁸Alexander Nilsson, Pegah Nikbakht Bideh, and Joakim Brorsson. A survey of published attacks on Intel SGX. arXiv preprint arXiv:2006.13598, 2020.

The Kima platform maintains large liquidity pools across multiple different layer-1 blockchains. Wherever there is pooled capital, there is an attendant risk. The Kima platform is committed to safety and liveness in its services, with the terms being defined as the following:

Safety: Safety is the ability to prevent the system from doing something incorrectly. In this case, this includes someone emptying the liquidity pools held on different blockchains or causing a transaction to occur that was not requested.

Liveness: Liveness is the ability to ensure that the system is able to do the things that it should be able to do. Here, Liveness means that the Kima system is able to continue making cross-chain transactions when requested.

In this section, we lay out the main types of risk faced by Kima and the steps taken to mitigate that risk.

Malicious wardens

The primary 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.

The use of threshold signatures ensures that wardens can only move funds if a quorum of wardens has authorized the transfer. The use of SGX enclaves makes it so that wardens can only deviate from the prescribed behavior by breaking the security of an SGX enclave. Kima wardens must stake tokens, and they expose themselves to slashing risk if they misbehave. A majority of professional block producers now validate across multiple chains; thus misbehavior on one chain will result in a loss of reputation that translates to a loss of revenue across multiple chains.

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 the risk of smart-contract vulnerabilities. The Wormhole exploit showed the risk of overly complex contracts.

Kima does not use multisigs, but instead uses threshold signatures, and thus Kima does not use smart contract, but instead holds assets in EOAs, which minimizes this attack surface.

Other risks include blockchain reorganizations and impermanent loss - these were already covered in this whitepaper.

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 potential for decentralized finance (DeFi), blockchain, and digital currencies is now measured in trillions of dollars in market capitalization. The market is exploding with options and opportunities for the financial ecosystem, but until now there has not been an optimal solution for applications that wish to operate across cryptocurrencies. Applications do suffer from performance delays, security flaws, and fragmented liquidity as a result of relying on insecure bridges, slow centralized exchanges, and inefficient token wrapping.

The Kima platform solves this problem. Its model of decentralized liquidity pools offers seamless cross-chain interoperability and exchange of digital assets by running a network of decentralized liquidity pools. Its highly secure and efficient protocol monitors and synchronizes assets across these blockchains via a liquidity management algorithm and provides a simple and secure mechanism for allowing users to perform cross-chain atomic transfers and swaps without token wrapping.

The entire platform is protected by best-in-class security protocols and mechanisms. It is more than adequately protected against the attendant risks of managing pools, as well as the ongoing risk of blockchain finality and impermanent loss.