Burning Some Bridges

In which we learn what a crypto bridge is, the main deficiencies with existing bridges, and how Kima addresses them

Why bridge?

Part of the Degen life is chasing APYs - elusive, high-yield new projects only available for a limited time. When these projects reach their goal, they have no reason to share their candy, meaning your window to “get in” is limited. A big part of chasing the next (crypto) high and supporting these projects requires moving your liquidity around chains.

New projects pop up on L1 and L2 chains and, as they try to generate traffic and TVL, offer investors a higher return on investing/staking for a limited time. However, if your liquidity is in a wallet on mainnet or in a centralized exchange, a chasm exists between you and your coveted prize. You need a bridge to reach the promised land.

What is a crypto bridge?

Think of each blockchain as its own galaxy: it has unique stars and planets (protocols and tokens) and a way to traverse them (a native coin).

The distance between galaxies is vast in our physical universe, much larger than the galaxies themselves. The same is true with blockchains: there’s no easy way to transfer liquidity (value) or messages (data) between two disparate blockchains unless you resort to a central messaging system.

A bridge utilizes an extra-chain messaging mechanism to convey messages between blockchains. There are different ways to achieve this task, wherein centralization is a feature, not a bug:

1. A centralized exchange that maintains a node for every blockchain can be considered a bridge.

2. A Layer 2 (L2) chain can use message aggregation of a Layer 1 (L1) chain to transfer data between the layers (think Polygon or Optimism).

3. Two smart contracts on two separate chains can utilize a set of oracles to convey messages using a third-party server.

Most bridges used today fall under the third category. While some will try to “decentralize” the third-party server, it will always be external to the blockchains and therefore susceptible to hacking and manipulation.

How does a crypto bridge work?

We now know how a bridge can coordinate messages across chains, but how do bridges transfer liquidity?

Most bridges utilize a method called “lock and mint.”

If users want to transfer n units of Token T from Chain A to Chain B, they deposit n units of T in a smart contract on Chain A (lock). A message is then transmitted through the messaging layer to a smart contract on Chain B, and that smart contract produces (mints) n units of a new wrapped token (WT) on Chain B.

To transfer the value back from Chain B to Chain A, the WT value is burned by the smart contract on Chain B. A message is then conveyed to the smart contract on Chain A to release T back to the user.

Why is a wrapped token used? Token T is native to Chain A and does not exist on Chain B. 

Here’s an example to help clarify this: a user wants to transfer 1 ETH from Ethereum to Solana, where ETH is a native token on Ethereum but does not exist on Solana, whose native coin is SOL. The bridge will issue wETH on Solana and will ensure its value by promising (proving) that for every wETH minted on Solana, there’s one real ETH locked on Ethereum.

To transfer the ETH back to its origin chain, the wETH token is then burned on Solana, and the original ETH is released to the user on Ethereum.

Bridge challenges

Security

There are several issues with the Lock and Mint mechanism. First and foremost, it is complex and highly susceptible to hacking. If you can convince the smart contract on the target chain that a user locked a certain amount of tokens without them actually doing so, that smart contract will mint wrapped tokens based on the message alone.

This was the case with Wormhole Bridge, where a hacker managed to convince the Solana side of the bridge to mint about 80,000 wETH using a signature hack. At the end of that day, hackers managed to steal nearly $320 million worth of tokens.

In the previous 24 months, there were more than seven bridge hacks, totaling over $2 billion in damages. Most hacks targeted the messaging layer or the smart contracts required on either end of the bridge. Others used phishing attacks to access the validator nodes.

Complexity

A bridge that supports n number of blockchains must provide an order of n² paths between every pair of chains it supports. It is hard to manage, adds attack surfaces, and introduces many more wrapped tokens into the ecosystem, leading us to the next issue. 

Wrapped Tokens are not ideal

Wrapped tokens have no intrinsic value beyond representing the fact that another token of value is locked somewhere else. Furthermore, every bridge has its own wrapped tokens. This creates an absurd situation where there can be three different USDT tokens on Avalanche (wUSDT, USDT.e, etc., in addition to the genuine USDT provided by Tether) and this many USDT versions on Solana.

Beyond user confusion, there’s the need to imbue each wrapped tokens with value on the target chain. This usually entails providing liquidity pools on AMMs. The wrapped tokens will not be usable in every protocol, forcing the baffled user to convert the token to a supported version, losing additional value to fees.

Enter Kima

Kima is an I14y (interoperability) protocol - not a bridge.
Kima is implemented as an L1 blockchain (built on the Cosmos SDK) that allows its validators (or wardens) to sign transactions together, using a Threshold Signature Scheme (TSS).

These transactions can span multiple blockchains, using an array of light clients for every blockchain Kima supports.

Kima utilizes this capability to manage pools of tokens on other blockchains, and thus facilitate value transfer between them.

Kima Pools

Kima’s pools are simple EOAs (Externally Owned Accounts) - normal crypto wallets, like the ones you yourself own - as opposed to smart contracts.
Like every EOA, a Kima pool can only do 2 things: receive and send funds.
Receiving funds is done automatically. Sending funds is only achieved when the wardens reach a consensus and use TSS to sign a transfer transaction.

So how does Kima work?

If a user wants to move value (let’s say n units of token T) between blockchain A and blockchain B, they will use the Kima SDK to send an approval transaction on A, allowing the Kima pool to transfer n T tokens from their wallet to the Kima pool on A.
They will then send a transaction to the Kima blockchain, with 6 parameters:

Transfer(origin=A, address on A, destination=B, address on B, token symbol=T, # of units=n)

Upon receiving the transaction, the wardens will sign a transaction on Blockchain A, transferring n tokens from the user’s address to the Kima pool on A. They will then wait a requisite number of blocks on A, to ensure finality.

Once finality is achieved, the wardens will sign a transaction on blockchain B, transferring n tokens to the user’s address on B. Again, they will wait for finality, and mark the transaction PAID.

Benefits of using Kima

• You can immediately see from the description above that no smart contracts, or wrapped tokens have been used. Security is paramount to Kima’s operation.

• Kima operates with like-tokens: the same token must exist on both blockchains. While this might sound like a limitation, Kima chose to focus on stablecoins to begin with (with the exception of BTC/wBTC pair, which is highly audited), therefore voiding the need for conversions and price oracles - that add a financial hacking attack surface to an application.
  To Kima, a $ is a $ - you give us 1 USDT on Ethereum, we give you 1 USDT on Solana.

• Because Kima does not use smart contracts only direct token transfers, our gas fees are much lower.

• Transaction time is solely dependent on the finality time of the 2 blockchains involved (transactions involving Solana will be lightning fast, transactions involving Bitcoin can take an hour).

• Kima only charges 5 basis points per transaction as fee, lower than any other solution.

• Kima provides an end-to-end audit trail, accompanied by compliance checks, to make sure non of the addresses provided is involved in anything untoward.

• And finally, and most importantly, Kima is composable: developers can build any dApp they want on top of Kima, utilizing its native behavior. E.g. a developer can implement swaps between tokens, across blockchains, utilizing Kima to move the value between chains securely, faster, and cheaper.

But wait, there’s more…

We’ve seen Kima can be used to easily transfer value between blockchains, but that’s not the only trick up our sleeve. In the next post we’ll discuss some more interesting uses we envision for the Kima protocol.