# 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](/kima-network/supported-assets.md) 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.kima.network/kima-network/the-kima-sdk/use-kima-sdk-without-widget/message-signing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.