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:
Calculating the optimal deposit amounts using
island.getMintAmounts()
Ensuring the amounts meet minimum requirements
Transferring tokens and minting LP tokens
Steps to Add Liquidity
Approve the router to spend your tokens (both tokens or one token in case of singleSided
Choose the appropriate liquidity addition method based on your tokens
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.
Set reasonable slippage parameters
Execute transaction
Kodiak Island LP tokens sent to the receiver as passed in params
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 fromburnAmount
: The quantity of Kodiak Island LP tokens to burnamount0Min
: 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 receivedamount1
: The actual amount of token1 receivedliquidityBurned
: 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 fromburnAmount
: The quantity of Kodiak Island LP tokens to burnamount0Min
: 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 receivedamount1
: The actual amount of token1 receivedliquidityBurned
: 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:
Calculate expected output amounts before calling
Include reasonable slippage protection via
amount0Min
andamount1Min
Ensure sufficient approvals are in place
Handle both success and failure cases in your integration
Verify received amounts match expectations after the transaction
ABI
Last updated