> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notional.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Signing, Nonces, and API Wallets

Reads and subscriptions for one account use that account's `user` address, not its API-wallet
address. Each action's endpoint page explains how to sign it.

## Before Trading

A deployment can require protocol access before trading. Query `POST /info` with
`{"type":"checkAccess","user":"0x..."}` and require `isAuthorized: true`. Terms state is available
through `{"type":"checkTerms","user":"0x..."}`; require `hasAccepted: true` for the current terms
version. If either check fails, the account owner must complete onboarding before the client trades.

## Who Can Sign

Notional verifies which address signed the request and which user's account it may change:

* A direct user signature acts for that same address.
* An approved API wallet can act for its approving user only where the endpoint allows API wallets.
* Reads and subscriptions continue to use the user's address, not the API-wallet address.

Approving an API wallet delegates eligible actions; it does not create a second trading account.
See [Approve Agent](/api-reference/exchange-endpoints/approve-agent) for the approval request and
[Extra Agents](/api-reference/info-endpoints/extra-agents) for the resulting authorization state.

## Action Types

| Family                         | Shared rule                                                     |
| ------------------------------ | --------------------------------------------------------------- |
| Trading, TWAP, outcome actions | The exact action fields and number formatting are signed        |
| Withdrawals                    | The user must sign directly; API wallets are not authorized     |
| Multi-step deposits            | The user signs the exact quote directly before it expires       |
| Agent approval                 | The user establishes or revokes the API-wallet relationship     |
| Deposit reporting              | Notional verifies the deposit rather than requiring a signature |

Each action page shows the exact JSON fields and any action-specific signing or expiration rules:

* [Place Order](/api-reference/exchange-endpoints/order)
* [TWAP Order](/api-reference/exchange-endpoints/twap-order)
* [Merge Outcome Shares](/api-reference/exchange-endpoints/merge-outcome)
* [Withdraw](/api-reference/exchange-endpoints/withdraw)
* [Execute Deposit](/api-reference/exchange-endpoints/execute-protocol-transfer)
* [Report Deposit](/api-reference/exchange-endpoints/report-deposit)

## Signing Domains

A signing domain is the name and chain information included in an EIP-712 signature. Notional
trading actions use the `NotionalExchange` domain. A signature created for a venue's domain cannot
be used as a Notional signature, or vice versa.

## Nonces

A nonce is a Unix-millisecond number that prevents the same signed request from being used twice.
For actions that include a nonce:

* Use a Unix-millisecond integer within `[now - 2 days, now + 1 day]`.
* Nonces are tracked per signer, including an API wallet acting for one or more users.
* Notional remembers up to 20 recent nonces per signer. Once full, a new nonce must be greater than
  the smallest remembered nonce and must never have been used.
* Use one shared counter across every process that uses the same signer. `Date.now()` alone can
  produce duplicates when requests are created at the same time.
* `expiresAfter`, where supported, sets an expiry time; it does not replace the nonce.

Nonce reuse normally fails. Some actions can return the saved response for an exact retry of the
same signed action; cancel requests intentionally reject duplicate nonces. Follow the action page
and check the current result before retrying.

## Signing Rules

* Format the action exactly as its endpoint page requires, sign it, and do not change it afterward.
* Use the action's documented signing domain, chain, JSON fields, and signer restrictions.
* A signature can recover the expected wallet locally and still fail if the server verifies
  different fields or a different signing domain.

Failure shapes and retry guidance are centralized in
[Error Responses](/api-reference/error-responses).