> ## 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.

# System Overview

> How DZap's components fit together.

DZap is layered. Each layer has a clear contract; layers below don't depend on layers above.

```
┌─────────────────────────────────────────────────────┐
│                  Surface layer                      │
│   App · SDK · API (REST) · MCP · CLI · Skills       │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│                  Reasoning layer                    │
│        ZapBot agent · tool router · memory          │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│                   Routing engine                    │
│   Pathfinder · price service · solver matcher       │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│                  Execution layer                    │
│   DZapDiamond contracts · Permit2 · bridge relayers │
└─────────────────────────────────────────────────────┘
```

## Surface layer

What integrators touch:

* **App** — `app.dzap.io`, the user-facing web app.
* **SDK** — `@dzapio/sdk` for TypeScript apps.
* **API** — REST endpoints at `api.dzap.io` (Trade) and `zap.dzap.io` (Fuse).
* **MCP server** — exposes every tool to LLM clients.
* **CLI** — `dzapai` for terminal-driven operations.
* **Skills** — context bundles for AI editors (Cursor, Claude Code).

## Reasoning layer

What ZapBot does between input and routing:

* **Tool selection** — picks the right tool from the catalog based on intent.
* **Plan generation** — surfaces a plan before execution for write operations.
* **Memory** — short-term per-session, optional long-term per-user.

See [AI Architecture](/ai/architecture) for the deep dive.

## Routing engine

The heart. For every quote, the engine evaluates routes across:

* DEX aggregators (ParaSwap, OKX, 1inch, ...).
* Bridges (Across, Mayan, Allbridge, ...).
* Native DEXs (when they beat the aggregators).

Routes are ranked by net output (after fees, gas, slippage). The top-N come back ranked.

## Execution layer

What lands on-chain:

* **DZapDiamond** — the per-chain router. Single trusted spender. See [Smart Contract Addresses](/products/contracts).
* **Permit2** — gasless approvals. Canonical address `0x000000000022D473030F116dDEE9F6B43aC78BA3` on most EVM chains.
* **Bridge relayers** — the actual cross-chain message carriers (Across CCIP, Mayan Wormhole, Chainflip, ...).

## Where the layers split

Different teams own different layers — deliberately. The routing engine doesn't know about the surface; the execution layer doesn't know about the reasoning layer. This makes:

* The surface easy to extend (new SDKs, new clients).
* The execution layer easy to audit (no business logic mixed in).
* The reasoning layer easy to swap (different agents, different LLMs).

See [Smart Contract Architecture](/products/architecture/smart-contracts) for the on-chain side.