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

# Intents

> Format, lifecycle, and the EIP-712 schema.

A Fuse intent is a structured EIP-712 message describing the outcome a user wants. Solvers compete to settle it.

## Intent types

The SDK exports three intent type sets, one per execution shape:

| Type        | When                                     | EIP-712 type                    |
| ----------- | ---------------------------------------- | ------------------------------- |
| Swap        | Same-chain swap                          | `DzapUserIntentSwapTypes`       |
| Swap+Bridge | Cross-chain swap with destination action | `DzapUserIntentSwapBridgeTypes` |
| Bridge      | Pure cross-chain transfer                | `DzapUserIntentBridgeTypes`     |

## Intent fields

Every intent carries:

```ts theme={null}
{
  txId: string;            // Unique intent ID (returned by quote)
  nonce: bigint;           // Per-user replay protection
  deadline: number;        // Unix seconds; intent expires after
  executorFeesHash: bytes; // Hash of the fee schedule
  swapDataHash: bytes;     // Hash of the actual swap calldata
  // ...type-specific fields
}
```

The hashes (`executorFeesHash`, `swapDataHash`) bind the off-chain intent to the exact on-chain action. A solver cannot rewrite the swap and reuse your signature.

## Lifecycle

<Steps>
  <Step title="Quote">
    Frontend asks `getZapQuote()`. Response includes `txId`, candidate steps, and the typed-data structure to sign.
  </Step>

  <Step title="Sign">
    User signs the EIP-712 typed data with their wallet. Output: a signature bound to the intent hash.
  </Step>

  <Step title="Submit">
    Signature + intent posted to the Fuse API (or directly to a solver).
  </Step>

  <Step title="Match + execute">
    A solver picks up the intent, verifies signature on-chain, executes the bundle.
  </Step>

  <Step title="Settle">
    User receives the final asset on the destination chain. Status visible via `getZapTxnStatus()`.
  </Step>
</Steps>

## Why intents instead of transactions?

* **Gasless** — solver pays gas; user pays only via the swap output.
* **Atomic outcome** — user signs the destination state, not the path.
* **Composable** — intents compose with bundles (multi-leg flows).

See [Gasless](/products/dzap-fuse/gasless) for the signing flow and [Execution Flow](/products/dzap-fuse/execution-flow) for what the solver does after submission.