The Kima Blockchain
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:
Managing and updating the set of wardens.
Platform governance, e.g., choosing the blockchains and tokens that are supported, and setting fees.
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.
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
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*.The user submits a transaction request on the Kima blockchain, specifying the source address (and chain), the destination address (and chain), and the amount.
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.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.
$600M
Destination Contract
$8M
Source Contract
Destination Contract
$80M
$4M
Harmony
$100M
Nomad
$200M
Destination Contract
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.
The use of threshold signatures ensures that wardens can only move funds if a quorum of wardens has authorized the transfer.
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.
The use of SGX enclaves enforced that wardens can only deviate from the prescribed behavior by breaking the security of an SGX enclave.
Kima wardens have high concrete financial penalties if they misbehave. For instance:
Legally-staked wardens can be sued.
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.
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
Bitcoin
Avalanche
Ethereum
Algorand
Bitcoin Cash
BSC
Cardano
Tendermint-based chains
Polkadot
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.
1
101870
2
1713
3
25
4
1
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:
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.
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.
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.
Last updated
