Kodiak Island Router

A helper contract that enables easy, secure liquidity provisioning and withdrawals

Overview

The IslandRouter contract serves as a helper contract for users to easily provide liquidity to Kodiak Islands. It handles the complexities of depositing tokens, slippage protection, and token swaps when needed, while ensuring optimal liquidity provision.

Kodiak Islands require liquidity providers to deposit tokens in specific ratios that match the Island's underlying Kodiak V3 position. The router provides several key protections:

  • Minimum output amount protection for swaps when providing liquidity with single token.

  • Deposit ratio slippage protection

  • Minimum LP token (shares) protection

Managing Liquidity

Token Deposit Ratio

The router handles liquidity addition by:

  1. Calculating the optimal deposit amounts using island.getMintAmounts()

  2. Ensuring the amounts meet minimum requirements

  3. Transferring tokens and minting LP tokens

Steps to Add Liquidity

  1. Approve the router to spend your tokens (both tokens or one token in case of singleSided

  2. Choose the appropriate liquidity addition method based on your tokens

  3. If the liquidity addition is using a single token, find the appropriate swap data and use Kodiak Quoter api to get the calldata according to the swap params.

  4. Set reasonable slippage parameters

  5. Execute transaction

  6. Kodiak Island LP tokens sent to the receiver as passed in params

  7. In case of zaps msg.sender receives back any unused token0 or token1

Adding liquidity with both tokens

1. Standard Two Token Deposit

Prerequisites

  • Token0 and Token1 balances sufficient for desired liquidity.

  • Approved router contract to spend both tokens.

Implementation Example

2. Native BERA + Token Deposit

It is important that one of the tokens in the underlying pool is WBERA for depositing with native BERA.

Prerequisites

  • Sender must have sufficient NativeToken and Token1 balances for desired liquidity.

  • Approve router contract to spend Token1 tokens.

  • Send required bera as msg.value

Implementation is same as above except for sending native token BERA as msg.value

Adding Liquidity with a single token

When depositing into a concentrated liquidity position like an Island, it's crucial to understand that the underlying tokens need to be in a specific ratio to maximize the value of the position. If a user wants to deposit a single token, a swap is required to balance the tokens before adding liquidity to the position. This process involves calculating the ideal amount of the input token to swap for the other token in the pair.

The IslandRouter uses a external swap Routers to swap this token to achieve maximal efficiency during the swap. The kodiak router is whitelisted to begin with and other routers will be whitelisted later to further increase this swap efficiency.

Prerequisites

  • Sufficient balance of input token or native token.

  • Approved router for input token amount

  • Understanding on how to find the swap params such that after the swap the token0 and token1 are in correct ratio to deposit into the island

  • Understanding on how to generate swap calldata using Kodiak Router.

Single Token Deposit Implementation

Implementation Example

Adding Liquidity with Native BERA

When you want to provide liquidity to an island with native token BERA.

Prerequisites

  • Native BERA balance

  • Island must have WBERA as one of its tokens

Single Native Token Deposit

Implementation Example

Important Notes

  • For native BERA deposits, one token in the Island pair must be WBERA

  • Unused BERA is automatically returned to sender as native tokens when performing single sided deposits with native BERA

  • If the msg.sender is a contract, it must handle both type of unused tokens i.e ERC20 tokens and native tokens when depositing with single token or native token

  • Set appropriate slippage parameters based on market conditions

  • Monitor gas costs, especially for operations involving swaps

  • Verify all addresses and amounts before execution

  • Consider using view functions to estimate outputs before executing transactions

Removing Liquidity

The router exposes two functions for removing liquidity with slippage control

removeLiquidity

Purpose: Removes liquidity from a Kodiak Island position by burning LP tokens and getting the underlying tokens.

Parameters:

  • island: The address of the Kodiak Island position to withdraw from

  • burnAmount: The quantity of Kodiak Island LP tokens to burn

  • amount0Min: Minimum amount of token0 that must be received (slippage protection)

  • amount1Min: Minimum amount of token1 that must be received (slippage protection)

  • receiver: The address that will receive the withdrawn tokens

Returns:

  • amount0: The actual amount of token0 received

  • amount1: The actual amount of token1 received

  • liquidityBurned: The amount of liquidity removed from the underlying Kodiak V3 position

Important Notes:

  • Caller must approve the router contract to spend their Kodiak Island LP tokens

  • Transaction will revert if received amounts are less than specified minimums

  • Useful for standard token pairs where wrapped native token conversion isn't needed


removeLiquidityNative

Purpose: Similar to removeLiquidity but specifically handles positions involving WBERA (wrapped BERA), automatically unwrapping it to native BERA before returning it to the user.

Parameters:

  • island: The address of the Kodiak Island position to withdraw from

  • burnAmount: The quantity of Kodiak Island LP tokens to burn

  • amount0Min: Minimum amount of token0 that must be received (slippage protection)

  • amount1Min: Minimum amount of token1 that must be received (slippage protection)

  • receiver: The address that will receive the withdrawn tokens (must be payable to receive native BERA)

Returns:

  • amount0: The actual amount of token0 received

  • amount1: The actual amount of token1 received

  • liquidityBurned: The amount of liquidity removed from the underlying Kodiak V3 position

Important Notes:

  • Caller must approve the router contract to spend their Kodiak Island LP tokens

  • One of the tokens in the pair must be WBERA

  • WBERA portion will be automatically unwrapped and sent as native BERA to the receiver

  • The non-WBERA token will be sent as is to the receiver

  • Transaction will revert if received amounts are less than specified minimums

  • Receiver address must be payable to receive native BERA

  • Particularly useful for positions involving native BERA pairs

For both functions, it's recommended to:

  1. Calculate expected output amounts before calling

  2. Include reasonable slippage protection via amount0Min and amount1Min

  3. Ensure sufficient approvals are in place

  4. Handle both success and failure cases in your integration

  5. Verify received amounts match expectations after the transaction

ABI

Last updated