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
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:
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%.
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).
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 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.
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.
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.
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
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