Message Signing

In order to submit a transaction to the Kima blockchain, the user must sign a message containing the transaction details. This message is signed by the user's wallet and then included in data submitted to the Kima Transaction Backend submit endpoints (/submit/transfer or /submit/swap).

Message Structure

The Kima message is a string that is signed by the user's wallet. It contains the following information:

• Authorization amount: in whole tokens i.e. 10.23 not 10230000

• Origin token symbol

• Origin chain symbol: see the list of chain symbols in the Supported Assets section

• Target address

• Target chain symbol

Template:

I approve the transfer of {authorizationAmount} {originSymbol} from {originChain} to {targetAddress} on {targetChain}.

Signing the Kima message

Get the message to sign by calling the /submit/fees endpoint and selecting the appropriate version based on whether the user is paying fees from the origin or target chain.

To sign the message, connect the user's wallet, read transactionValues.feeFromOrigin.message or transactionValues.feeFromTarget.message from /submit/fees, and pass that string to your wallet client's message-signing function.

If you are integrating on EVM chains, see the Viem wallet client docs for a concrete signMessage implementation.

This signature will be passed to the options param of the submit endpoint.

Permit2 tokens

If the selected origin token has isPermit2=true in /chains, the Kima message signature above is still mandatory, and you must also include an additional options.permit2 payload in the submit request:

• r

• s

• v

• deadline

This means there are two distinct signatures in a Permit2 flow:

• the Kima message signature, which authorizes the transaction details for Kima

• the Permit2 signature payload, which authorizes token spending without a separate on-chain approve() transaction

Some supported tokens use a signature-based approval flow through Permit2 instead of a regular on-chain approval transaction.

Regular approval

With a regular ERC-20 approval flow, the user must first send an approve() transaction to grant spending permission to the spender contract. After that transaction is confirmed, the transfer transaction can be submitted.

This means the user usually pays gas twice:

1. once for the approval transaction

2. once for the transfer transaction

Permit2 approval

With Permit2, the user signs additional off-chain typed data instead of sending a separate approve() transaction from their wallet. That signed authorization is then used as part of the transfer flow.

This reduces friction because:

• no separate approval transaction is required

• the user avoids paying gas for a standalone approval

• the approval and transfer flow becomes faster and simpler

Key difference

The main difference is where the approval happens:

• Regular approval: permission is granted on-chain through an approve() transaction

• Permit2: permission is granted by signing an additional authorization payload, which removes the need for a separate approval transaction

For supported Permit2 tokens, the wallet flow includes the normal Kima message signature plus an additional Permit2 authorization signature instead of a standard approval transaction.

Why sign a message?

Signing a message significantly improves security in the following ways:

• The signature is cryptographically verifiable as coming from the user's wallet. This is proof that the user has authorized the transaction.

• The transaction details cannot be modified without invalidating the signature. This prevents a "man in the middle" attack where the destination address is changed to the attacker's address.