Kawa Litepaper
February 2023
Abstract
As multiple blockchain ecosystems have emerged, interoperability has become increasingly important within DeFi. It has the potential to unlock liquidity that is fragmented across disparate ecosystems and significantly reduce transaction costs. However, continual exploits resulting in billions of dollars of losses [1] have reiterated the need for increased security of interoperability protocols. Kawa proposes a cross-chain messaging aggregation protocol to reduce individual bridge/messenger service dependency. Utilizing this novel architecture, Kawa has built a cross-chain lending protocol deployed natively on Sei, and other popular EVM-compatible and layer 2 blockchains. Kawa aims to be the key entry point to the Sei ecosystem.
For anyone short on time, there is a FAQ & Step-by-Step Guide at the end.
Table of Contents
• Cross-Chain Messaging Aggregation (XCM)
• Security
• Why Sei?
Introduction
Kawa is a cross-chain, decentralized lending protocol offering perpetual, variable rate loans. By utilizing a proprietary cross-chain messaging aggregation protocol (XCM Aggregation), Kawa significantly improves upon security and speed of existing cross-chain money markets. The core protocols used by Kawa are described below:
Kawa Core: the ledger containing the state of the protocol, such as account balances, risk settings, markets and additional information needed to ensure correct functioning of the protocol. Kawa Core is deployed on Sei, leveraging instant finality, high throughput, and low gas fees. Protocol state and logic is centralized within the Kawa Core ledger, which communicates state transitions with other blockchains via Kawa Ports and the XCM Aggregator.
Kawa Ports: the entry and exit points to the protocol that do not maintain a state. Lenders provide liquidity by depositing assets into Kawa Ports. Once consensus is formed by the XCM Aggregator, the account state is updated on the Kawa Core ledger, and the deposited asset can be used as collateral to borrow another asset on any supported blockchain.
XCM Aggregator: This protocol is designed to address the potential risks associated with the exploits of bridges and cross-chain messaging protocols. It requires a quorum to be reached by different cross-chain messaging providers before committing any changes to destination blockchain. As a result, the compromise of one provider does not threaten the security of the destination chain.
Kawa is governed by holders of the protocol native Kawa Token ($KAWA). Kawa is entirely non-custodial; users are responsible for managing their own funds.
As creators of the protocol, the Kawa development team have produced a convenient and user-friendly front-end to the smart contracts, which will be hosted at https://app.kawa.finance (in the near future).
Cross-Chain Messaging Aggregation (XCM)
Current XCM Infrastructure
XCM protocols have emerged as the favored solution to enable asset interoperability between disparate blockchains. However, while providing efficient and effective cross-chain asset transfers, the intricate process entailing both off-chain programs and on-chain smart contracts has resulted in the emergence of new security issues. Last year there were several severe attacks targeting cross-chain infrastructure, resulting in billions of dollars’ worth of losses.
There is a wide range of XCM bugs and security holes, which vary depending on the software, technology, and security strategy employed.
Methods used to successfully exploit XCM protocols:
• Compromising enough validators to execute transactions [2]
• Compromising a validator using elaborate fishing schemes [2]
• Compromising a validator whose permissions had been recently changed [2] • Compromising a contract that had been recently upgraded [3] [4]
• Exploiting depreciated insecure functions [5]
• Exploiting cross-contract interactions of a complex design [6]
• Exploiting a contract in a way overlooked by all audit [7]
• Stealing private keys having decrypted them from poor passphrase encryption [7] • Forging a block’s proof [8]
XCM protocols are an attractive target due to the centralization of value associated with them, and the complexity of securely implementing such a system. Moreover, sections of these protocols must be managed off-chain, creating additional sources of risk, through centralization and opacity, not present in strictly on-chain alternatives. The nuclear solution of “rolling back the chain” that blockchains are afforded in the worst case, will never be available to these protocols, due the native incapability of blockchains to communicate.
The security of an XCM protocol can be compared to the security of a blockchain, which can only be achieved with sufficient levels of decentralization and battle tested code. New XCM designs have made noteworthy improvements to decentralization and architecture, but further enhancements are necessary. Cross-chain protocols require high liveness to ensure security; any downtime poses critical security issues.
Kawa’s proprietary XCM Aggregation protocol removes dependency on any single XCM protocol, significantly improving upon the security and resilience of existing cross-chain money markets, even in the event of complete outage, or exploitation.
XCM Aggregator
Kawa incorporates a proprietary XCM Aggregation protocol, leveraging multiple XCM protocols to establish a quorum, strengthening the security and resilience of Kawa. On each chain, Kawa’s XCM Aggregator contracts will communicate with each other via multiple XCM (Xn) infrastructure simultaneously. Quorum (Qn) must be met in order for a transaction to be confirmed and the user state updated.
Some simple observations:
1. Exploitation or compromise of a single bridge or XCM protocol will not affect the integrity of Kawa.
2. Exploiting or compromising enough XCM protocols simultaneously to maliciously influence consensus is an order of magnitudes more improbable than exploiting one.
Thus, XCM aggregation is crucial to any cross-chain protocol relying on message signals arriving. In particular, cross-chain lending protocol’s must send liquidation XCM between its deployments in a timely manner and cannot afford for a bridge to go down.
XCM Aggregators will become a new DeFi primitive - an industry standard in cross-chain messaging. Several noteworthy cross-chain applications have expressed interest in utilizing this aggregator, which will be offered as a service in return for fees (which Kawa will be exempt from). As XCM Aggregator volumes increase, transactions will be batched, increasing security while minimizing costs for users.
Theoretically, if an actor managed to exploit 2+ (quorum) XCM services simultaneously, it is possible to exploit Kawa. However, exploiting two XCM services simultaneously is an order of magnitudes more unlikely, and there is lower hanging fruit in the form of exploiting a singular XCM service.
Kawa Architecture
Kawa Core
Kawa’s main state, Kawa Core, is hosted on the Sei blockchain. This is the master state of user balances. Actions reducing value locked in the protocol must originate from here (such as borrowing and withdrawing transactions), while actions crediting value to the protocol are received and validated coming from the XCM Aggregator after being sent by a Kawa Port.
Kawa’s UI will abstract away any complexities into as few transactions as possible.
Kawa Ports
Kawa Ports are interfaces that facilitate cross-chain transferring of assets. Each supported blockchain has its own Kawa Port (including Sei) that is used to lock and extract assets that are native to that chain. Kawa Ports communicate with Kawa Core through the use of the XCM Aggregator.
Public Methods:
Supply
This method locks a user's asset in the Kawa Port, which is subsequently credited as a balance on Kawa.
Invoke
This method invokes a signed notice from the Kawa Port.
Notices are messages with instructions to a function generated by Kawa Core, processed by the XCM Aggregator and stored in the Kawa Port waiting for the user interaction.
Security
Security Over Latency
Kawa prioritises security over latency for several reasons:
• Security over Speed: The security of funds is of the utmost importance. If a transaction is not secure, it may result in the loss of user funds.
• Preventing Fraud: High latency can help prevent fraudulent transactions by allowing more time for potential security breaches to be detected and addressed before funds are transferred.
• Maintaining Consistency: Increased security measures may require additional processing time, but they help ensure the consistency and accuracy of the blockchain, maintaining its integrity and trust among users.
For example, consider a cryptocurrency exchange that wants to make a large transfer of funds to a cold storage wallet for safekeeping. If the exchange prioritizes speed over security, the transfer may be processed quickly but could be vulnerable to hacks and fraudulent activity. On the other hand, if the exchange prioritizes security, it may take longer to process the transfer, but the funds will be much more secure. In this case, the higher latency with increased security is a better choice for the exchange.
Kawa prioritizes security over latency with respect to XCM. In practice this means Kawa is at least as slow as the slowest XCM to meet quorum. However, due to the instant finality of the Sei network, Kawa’s Sei deployment adds minimal latency when compared to Ethereum finality.
Any XCM leaving Sei to other chains will be very fast, similar to other instant finality chains. Thus, any latency won’t be noticeable beyond what users are already used to.
Whilst some interactions on Kawa Ports will be sending back confirmation XCMs, Kawa Core will not be waiting for them to authorize other transactions. All transactions will be assumed as executed at the moment they are sent from Kawa Core. This means there is no latency added waiting for return confirmation (except in some niche cases). Fig 4 below demonstrates this flow.
Why Sei?
Instead of the traditional blockchain’s fire-and-forget broadcast, Sei's design enables a requestor or a proxy to proactively talk to validators to bring a transaction to finality. This results in near instant finality for simple transactions, vital for applications that need completion in real time.
Such features create an ideal environment for Kawa to securely store, update and communicate user states within its Ports contracts. At the same time it adds minimal latency to the cross-chain communication due the instant finality that Sei’s offers. Other blockchains like EVM, cannot [9].
Native Assets Only
The utilization of cross-chain infrastructure, which spans multiple blockchain platforms, can create exceedingly complex effects. Indeed, these bridges foster a connection between two or more blockchains, making the security of each platform entwined and susceptible to one other. Additionally, exploitation of cross-chain bridges that mint “wrapped” assets may
result in these synthetic assets no longer being backed 1:1 to the underlying asset.
An example of this happening can be seen with the Meter.io attack [9] which caused BNB.bsc to have a lower price on BNB chain than what Hundred Finance ascertained from the global Chainlink price, creating arbitrage opportunities where attackers could purchase BNB.bsc at a lower cost and use it as collateral to borrow more valuable assets.
Kawa believes in a future without bridge wrapped assets. Therefore, aligning with Kawa's focus on cross-chain risk mitigation, exclusively native tokens will be used for its lending and borrowing services.
Liquidations
The liquidation incentives will steadily increase over time to entice engagement, beginning at 10% plus a premium to allow the discount to rise as a function of how under-water a position is [11]. The market forces will dictate how high it needs to be.
Liquidations will begin by having the same collateral on the same Kawa Port where the underwater user’s collateral is. It will be possible to see on chain or through the UI that a liquidation has begun (avoiding two entities trying to liquidate more than the amount eligible for liquidation).
Kawa will have stabilization pools, so there is sitting liquidity ready to liquidate which will be the beneficiary of the liquidation incentive. However, liquidation will still be open to any entities so that Kawa can rely on multiple ways to maintain solvency.
Kawa’s assumption here is that sophisticated players are omnichain and given enough incentive will take advantage of the opportunities available to them.
Interest Rate Model
Similar to Aave, Kawa will utilize both a variable & a fixed interest rate model. The reserve factor will depend on analysis of each asset's risk.
As with Aave there is an optimal utilization variable & two different slope variables depending on whether you are above or below optimal utilisation. When utilization is below optimal, the APR curve increases at the gentler of the two slopes, and when it is above optimal it increases at the steeper slope. This should sufficiently control cross-chain flows of liquidity.
Where Kawa differs from Aave is that 5% of generated borrow fees will be redistributed to $KAWA stakers.
Kawa Token Utility
$KAWA is the governance token issued by the Kawa protocol. KAWA tokens represent voting power on governance proposals. Holders with enough KAWA tokens can make a formal proposal for change in the protocol. Token holders will then be able to vote on the proposal themselves or delegate their vote shares to a third party. Examples of the kinds of decisions token holders might vote on include proposals to alter include:
• Collateral and borrow factors
• Price oracle parameters
• Reactive interest rate model parameters
• Reserve factors
• Whitelist XCM protocols and modify quorum
It also captures the fee revenue that is generated by the system and incentivizes early adopters.
Conclusion
Over the coming years, the proliferation of blockchains is expected to escalate, driven by factors such as the need for application-specific blockchains, the desire for greater scalability, and advancements in blockchain algorithms. Interoperability among blockchains will remain a critical aspect, enabling seamless access, communication, and liquidity for users across the globe.
Kawa’s omnichain money market enables users to deposit any major asset on any supported chain and borrow a variety of supported assets across multiple chains in a seamless experience.
With the development of a proprietary XCM Aggregator, Kawa introduces a new DeFi primitive that enhances the security and availability of cross-chain messaging protocols through increased decentralization. Reliance on a single XCM protocol is obsolete; XCM aggregation is the future.
Frequently Asked Questions
Can you borrow across multiple chains if your collateral is locked on one chain i.e. can you fractionalise across chains where you borrow?
Yes, users can borrow assets across multiple blockchains up to their maximum borrowing capacity. For example, assuming an LTV of 60%, locking 10 $ETH on Ethereum permits a user to borrow a maximum of 6 $ETH across the chains of their choice, such as 3 $ETH on Optimism, and 3 $ETH on Sei. Kawa will launch with initial deployments on Sei and Ethereum, with expansion to Optimism, Polygon, BNB and other Layer 2 and EVM compatible blockchains.
What will you be able to do with your $SEI tokens on the first day of Sei’s launch? Won’t you be draining liquidity from Sei because in its primitive state, it will have a low amount of applications and uses for the Sei token whereas at that point, Ethereum will have a vast amount?
Kawa Protocol will act as an extra layer of utility for Sei and could reduce sell pressure by allowing $SEI holders to lock their tokens in exchange for a different asset, rather than selling them. This may attract holders of $SEI on central exchanges, who would otherwise not bridge to the Sei chain. It will also have the indirect effect of increasing the TVL, even more so in the case that someone takes out leverage by folding their $SEI through Kawa. Being able to borrow $SEI enables users from Ethereum to get exposure to the Sei ecosystem, exploring its dApps, farming, staking tokens and much more. This is another one of the reasons Kawa will become the entry point of liquidity into the Sei ecosystem.
Will you be ready on day one of the Sei launch?
Kawa expects to be ready to launch on day one of Sei. However, there are certain elements out of Kawa’s control that would prevent us from launching immediately. For example, if oracles aren’t supported on Sei when the blockchain launches, it would be unsafe to deploy Kawa. In terms of elements within Kawa’s control, Kawa will be ready to launch on day one of Sei.
Is Kawa planning on doing all liquidations or will you enable users to conduct them as well?
Liquidations will be both available to the protocol and sophisticated users. If you would like to read more about this, please read the Liquidations section above.
What happens if Axelar and Wormhole go down simultaneously? How would you then obtain consensus?
If the XCM Aggregator was using 4+ bridges, with minimum quorum of 2, then the protocol would continue to operate as normal. In the extremely unlikely event that enough bridges stop responding simultaneously, the XCM aggregator will not form consensus and won’t update a state. This will temporarily disrupt liquidations, but users’ funds will be safe.
How do you correct liquidity mismatches if borrowing/lending traffic is all going one way?
As utilization of any particular asset goes up the APR curve should sufficiently incentivize users to go the other way. You can read more about this in the Interest Rate Model section.
Is the ledger state shared across all blockchains or is it centralized to Sei?
The main ledger (Kawa Core) is held on Sei, all balance updates have to route via this. Kawa Ports deployed on other chains are stateless.
How long does it take to be able use my collateral after depositing on Ethereum?
The largest amount of time spent is with Ethereum finality, once that has passed, the instant finality of Sei will enable you to borrow assets on any other chain. Which is another reason why an instant finality chain like Sei is ideal for Kawa’s design.
Why did you pick Sei and Not EVM?
The instant finality of the Sei Blockchain makes it an ideal environment for Kawa vs EVM based blockchains. To read more see the Why Sei? section for more details.
How is the portfolio set up?
Wallets on different chains become linked contractually, so the UI will be able to show you the balances on whichever wallet you are logged in with.
Where do I stake my Kawa tokens?
$KAWA is a Sei native token and staking/liquidity mining and governance will take place on Sei through the Kawa.finance dapp.
Do you have a Native Stablecoin?
No.
Step-by-Step Guide
Supplying and borrowing assets
Murakami supplies $ETH as collateral on Ethereum and borrows $SEI on Sei.
1. Murakami deposits $ETH into the Kawa Port Ethereum contract.
2. Kawa Port sends an XCM via the XCM Aggregator Ethereum contract.
3. The XCM Aggregator Etherem contract sends this message through 3 different XCM protocols: Wormhole and Axelar.
4. The XCM Aggregator Sei contract receives these XCMs, once it has received 2 of them, quorum is formed, and it sends the message to the Kawa Core Sei contract.
5. Kawa Core updates, and now Murakami is able to borrow $SEI.
6. Kawa Core sends a message to Kawa Port Sei and the $SEI is now available.
7. Kawa Port sends a message to Kawa Core to confirm that the borrow was complete.
Withdrawing collateral
Murakami wants to pay off his healthy $SEI loan and withdraw $ETH collateral.
1. Murakami deposits $SEI into the Kawa Port Sei contract.
2. Kawa Port sends a message to Kawa Core and his balance is updated. 3. Murakami can now start the withdrawal process of his $ETH.
4. Kawa Core sends an XCM to the XCM Aggregator Sei contract.
5. The XCM Aggregator Sei contract contact sends this message through 3 different XCM protocols: Wormhole and Axelar.
6. The XCM Aggregator Ethereum contract receives these XCMs, once it has received 2 of them, quorum is formed, and it sends the message to Kawa Port Ethereum contract.
7. The $ETH is now available.
8. Kawa Port sends a XCM to confirm that the collateral was withdrawn via the XCM Aggregator Ethereum contract.
9. The XCM Aggregator Ethereum contract sends this message through 3 different XCM protocols: Wormhole and Axelar.
10. The XCM Aggregator Sei contract receives these XCMs, once it has received 2 of them, quorum is met, and it sends the message to Kawa Core Sei contract.
Liquidation process
Murakami’s $SEI loan is underwater. Dave, a sophisticated user, liquidates Murakami’s position and receives Murakami’s $ETH collateral.
1. Dave deposits $SEI in Kawa Port Sei contract, also indicating that he is to liquidate Murakami’s underwater position. In this transaction he will select his preferred collateral to receive from Murakami’s position, in this instance there is only one choice, $ETH.
2. Kawa Port contract updates the Kawa Core contract. $ETH collateral is now Dave’s. He doesn’t have to withdraw it at this moment and could borrow against it. He chooses to withdraw it.
3. Kawa Core sends an XCM to the XCM Aggregator Sei contract.
4. The XCM Aggregator Sei contract sends this message through 3 different XCM protocols: Wormhole and Axelar.
5. The XCM Aggregator Ethereum contract receives these XCMs, once it has received 2 of them, quorum is met, and it sends the message to Kawa Port Ethereum contract. 6. The $ETH is now available.
7. Kawa Port sends a XCM to confirm that the collateral was withdrawn via the XCM Ethereum contract.
8. The XCM Aggregator Ethereum contract sends this message through 3 different XCM protocols: Wormhole and Axelar.
9. The XCM Aggregator Sei contract receives these XCMs, once it has received 2 of them, quorum is met, and it sends the message to Kawa Core Sei contract.
References
[1] 2022 Biggest Year Ever For Crypto hacking with $3.8 Billion Stolen. https://blog.chainalysis.com/reports/2022-biggest-year-ever-for-crypto-hacking/
[2] Back to Building: Ronin Security Breach Postmortem. https://blog.roninchain.com/p/back-to-building-ronin-security-breach
[3] Wormhole Vulnerability. https://github.com/immunefi-team/wormhole-uninitialized
[4] Nomad Bridge Hack: Root Cause Analysis. https://medium.com/nomad-xyz-blog/nomad-bridge-hack-root-cause-analysis-875ad2e5aacd
[5] Explained: The Wormhole Hack (February 2022). https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022
[6] Explained: The Poly Network Hack (August 2021). https://www.halborn.com/blog/post/explained-the-poly-network-hack-august-2021
[7] Explained: The Harmony Horizon Bridge Hack. https://www.halborn.com/blog/post/explained-the-harmony-horizon-bridge-hack
[8] Explained: The BNB Chain Hack (October 2022). https://www.halborn.com/blog/post/explained-the-bnb-chain-hack-october-2022
[9] The Time to Finality for Solana. https://cryptoresearch.report/crypto-research/the-time-to-finality-for-solana/
[10] Explained: The Meter.io Hack (February 2022). https://www.halborn.com/blog/post/explained-the-meter-io-hack-february-2022
[11] Euler Finance Whitepaper. https://docs.euler.finance/getting-started/white-paper
Last updated
