Approval
In order for Kima to move tokens on behalf of the user an on chain approval needs to happen. An approval has 3 components:
Owner address: User
Spender address: Kima Pool
Total amount: origin token amount plus gas fees
Getting the Kima Pool Address
Using the Kima Backend
GET /chains/pool returns a list of pool addresses and balances for all supported chains.
[
{
"chainName": "SOL",
"poolAddress": "5tvyUUqPMWVGaVsRXHoQWqGw6h9uifM45BHCTQgzwSdr",
"balance": [
{
"amount": "99684.841000000000000000",
"tokenSymbol": "USDK",
"decimal": "6"
}
],
"nativeGasAmount": "70.119964040000000000"
},
{
"chainName": "TRX",
"poolAddress": "TQ3qmAgUgMwrY9prMiHLZmF43G4Jk8bxNF"
// ... etc
}
]Using the Kima API
EVM
ecdsa
0x9a721c664f9d69e4da24f91386086fbd81da23c1
Solana
eddsa
5tvyUUqPMWVGaVsRXHoQWqGw6h9uifM45BHCTQgzwSdr
Tron
ecdsa (base58)
TQ3qmAgUgMwrY9prMiHLZmF43G4Jk8bxNF
You can also obtain the pool addresses from the TSS endpoint. Use the type in the chart above to determine which one to use.
GET https://api.sardis.kima.network/kima-finance/kima-blockchain/kima/tss_pubkey
Success Response:
tssPubkey(array object)tssPubKey: string
ecdsa: string
eddsa: string
reserved: string
pagination(object)nextKey: string | null
total: number
Note: for Tron, the hex ecdsa address must be converted to a base 58 checksum address.
Getting the Service Fee
The fees and allowance amounts are calculated by an endpoint exposed by Kima chain. The this endpoint also returns a feeId which must be included when submitting the transaction.
Using the Kima Backend
GET /submit/fees
Query Params (all required):
amount(number): the amount of tokens to transferoriginAddress(string): the source user addressoriginChain(string): the chain the user tokens will come fromoriginSymbol(string): the token symbol the user will pay with (or bridge from)targetAddress(string): the receiving addresstargetChain(string): the destination chaintargetSymbol(string): the token symbol being delivered
Example:
/submit/fees?amount=10&originChain=TRX&targetChain=ARB&deductFee=true&originSymbol=USDK
Success Response:
Amounts are returned as both numbers representing the amount in whole tokens and as a string representing the integer amount in the smallest unit of the token (e.g. USDC is 6 decimals).
feeId(string): a unique identifier for the fee; include this in the submit request (/submit/transferor/submit/swap)feeOrigin*the gas fee for the origin chainfeeKimaProcessing*The processing fee (currently 0.05%)feeTarget*the gas fee for the target chainfeeTotal*the total feetransactionValues: amounts used for the allowance and submitting the transactionfeeFromOrigin: amounts used when the user selects to pay fees from the origin amountallowanceAmount: the token amount that needs to be approved. Can be passed directly to the contract call.submitAmount: the amount that needs to be passed to submit endpoints
feeFromTarget: amounts used when the user selects to pay fees from the target amount
The allowanceAmount is the one you'll need to pass to the contract call. There are 2 variants returned depending on whether the user chooses to pay fees from the origin or target amount.
When paying fees from the origin, use
transactionValues.feeFromOriginvalues.When paying fees from the target, use
transactionValues.feeFromTarget.
Example:
Transferring 10 USDC from ARB to SOL with 0.07371 USD in total fees.
When paying fees from the origin
The total fees are added to the amount
User signs the message
I approve the transfer of 10.07371 USDK from ARB to 5FHwkrdxkjF7xoL2ncGh4AEYs1KyJzz5MeiaHGz8h8GA on SOL.(feeFromOrigin.message)The user approves a transfer of
10.07371USDC on Arbitrum (feeFromOrigin.allowanceAmount)The amount sent to submit endpoints is amount RECEIVED on the target chain
The amount sent to submit endpoints is
10USDC (feeFromOrigin.submitAmount)Also included is the
feeIdand signed message
The user receives
10USDC on Solana
When paying fees from the target chain
The user does not pay fees on Arbitrum
User signs the message
I approve the transfer of 10 USDK from ARB to 5FHwkrdxkjF7xoL2ncGh4AEYs1KyJzz5MeiaHGz8h8GA on SOL.(feeFromTarget.message)The user approves a transfer of
10USDC on Arbitrum (feeFromTarget.allowanceAmount)The amount sent to submit endpoints is
9.926290USDC (feeFromTarget.submitAmount)The fees are deducted from the amount recieved on Solana so the user receives
9.926290USDC on Solana
Save the corresponding submitAmount, message and feeId for later as they are needed to submit the transaction.
Chain Names
See the short names in the Supported Assets section.
Using the Kima API
There is also an endpoint that can be called directly.
POST {{baseUrl}}/v2/fees/calculate
It has all the params and same response as the Backend /submit/fees endpoint except:
The params are in the body as JSON
There is an extra param
creatorwhich is the Kima address of the developer wallet sending the transaction-kima1...
Permit2 Tokens
Read the selected origin token metadata from GET /chains.
isPermit2=false: use the standardapproveflow shown below.isPermit2=true: signature is still required, and submit withoptions.permit2payload (r,s,v,deadline) in addition.Permit2 tokens are not supported in
mode=light.
BTC-origin flow (approval equivalent)
BTC-origin transactions do not use ERC20 approve. Instead, funds are first locked in a BTC HTLC output and then submitted to Kima with HTLC metadata.
You should still call GET /submit/fees first and keep feeId for the final submit step.
Step 1: Create HTLC lock intent
POST /btc/htlc/lock-intent
Request body:
senderAddress(string): BTC sender addresssenderPubkey(string): BTC sender public key (hex)recipientAddress(string): recipient address used to construct the lock scriptamountSats(string): lock amount in satoshispoolAddress(string, optional): explicit BTC recipient in scriptlockBlocks(number, optional): timeout as block deltatimeout(number, optional): explicit timeout value
Response includes:
lockIdhtlcAddresstimeoutHeightamountSatssenderPubkey
Step 2: Broadcast BTC lock transaction
Use the user's BTC wallet/provider to send amountSats to the returned htlcAddress. Save the broadcast transaction hash (txid).
Step 3: Record the broadcast transaction
POST /btc/htlc/record
Request body:
lockIdtxid
Response returns submit-ready HTLC fields:
htlcCreationHashhtlcCreationVouthtlcExpirationTimestamphtlcVersion(currentlyp2wsh-sha256-cltv-v1)senderPubKey
Use these together with:
htlcAddressandhtlcLockIdfromlock-intenthtlcAmountSatsfrom the selected lock amount
These values are then sent to POST /submit/transfer or POST /submit/swap.
Calling Approve
Once all the info has been collected it’s time to make the on chain call. The exact details of how this is done depends on the origin chain and library used.
The getClientsForChain() and getPoolAdressesForChain() would be utility functions defined elsewhere.
Last updated