> For the complete documentation index, see [llms.txt](https://exliquid.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://exliquid.gitbook.io/docs/developers/transactions-and-signing.md).

# Transactions and signing

Exliquid uses typed signed transactions so the action being authorized, the target network and replay-protection fields are part of the transaction contract.

## What a signed transaction binds

A canonical signed transaction includes or commits to information such as:

* network / chain identity;
* protocol and envelope version;
* transaction type;
* account and subaccount;
* signer identity;
* authorization reference when an agent is used;
* nonce domain and nonce;
* validity-height range;
* action payload;
* client transaction identifier.

The exact wire schema is versioned. Use the supported SDK or published protocol schema for field-level encoding.

## EIP-712 signing

The current transaction model uses EIP-712 typed signing.

This gives wallet and client implementations a structured message rather than treating every action as an unexplained byte string.

Before signing, a client should verify:

1. the target network is correct;
2. the account and signer are correct;
3. the market action matches what the user intends;
4. the nonce was obtained for the correct signer/subaccount/domain;
5. the transaction has not expired;
6. all numeric values use the expected units and precision.

## Nonces

Nonces provide replay protection and ordering within an action domain.

The current external protocol defines separate domains for classes of action such as ordinary trading and restricted risk-control actions. Query the correct nonce before signing:

```
GET /api/v1/accounts/{address}/nonce
    ?signer={signer}
    &subaccount={subaccount}
    &domain={domain}
```

Do not reuse a nonce for a different logical action unless the protocol explicitly defines a supported replacement flow.

## Transaction ID

After constructing the signed transaction, clients receive or derive a stable transaction identifier used for confirmation and lookup.

Keep this ID until the outcome is known.

Useful queries include:

```
GET /api/v1/transactions/{tx_id}
GET /api/v1/transactions/{tx_id}/confirmation
GET /api/v1/transactions/{tx_id}/receipts
GET /api/v1/transactions/{tx_id}/events
```

## Owner and agent signing

An account owner can sign its own actions. Where agent authorization is enabled, an authorized agent can sign within the scope granted by the owner.

Applications must not treat agent authorization as possession of the owner's private key; it is a scoped authorization relationship that can be queried and revoked.

See the authorization endpoints in [REST API](/docs/developers/rest-api.md).

## Network identity

Current network and signing identifiers are listed in [Protocol identifiers](/docs/reference/protocol-identifiers.md). Always pair them with the availability and compatibility information in [Networks and versions](/docs/reference/networks-and-versions.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://exliquid.gitbook.io/docs/developers/transactions-and-signing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.