# 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](https://docs.kima.network/kima-network/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](https://viem.sh/docs/viem/api/wallet-client) 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.