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

# How Delta intent swaps work

> From signed intent to on-chain settlement: the full Delta flow end-to-end.

Delta separates **what the user wants** (the intent) from **how it gets executed** (the fill). The user signs once, off-chain. Solvers on the [Portikus Network](/solver-network/portikus) race to provide the best executable calldata, and protocol settlement executes the winning calldata through the Delta contract.

## The flow at a glance

```mermaid theme={null}
sequenceDiagram
  autonumber
  actor User
  participant DApp as Your app / SDK
  participant API as Velora API
  participant OS as Order Server
  participant Solvers as Portikus Network<br/>(solvers)
  participant Settlement as Protocol settlement
  participant Delta as Delta contract<br/>0x...c96d

  User->>DApp: "Swap 1000 USDC for USDT"
  DApp->>API: GET /v2/quote?mode=DELTA
  API-->>DApp: delta block (route + alternatives + spender)

  DApp->>API: POST /v2/delta/orders/build<br/>(route from prices)
  API-->>DApp: toSign (EIP-712) + orderHash

  DApp->>User: Request signature
  User-->>DApp: ERC-2098 compact signature

  DApp->>API: POST /v2/delta/orders<br/>(order + signature)
  API->>OS: Persist signed order

  rect rgb(232, 245, 233)
    note over OS,Solvers: Off-chain auction
    OS->>Solvers: Broadcast order
    Solvers-->>OS: Competing fill calldata
    OS->>Solvers: Award winner
  end

  OS->>Settlement: Winning calldata + signed order
  Settlement->>Delta: settle(order, signature, fillData)
  Delta-->>User: destToken delivered

  loop Until terminal status
    DApp->>API: GET /v2/delta/orders/{orderId}
    API-->>DApp: status = PENDING / COMPLETED / FAILED
  end
```

## The five stages

### 1. Quote

You call `GET /v2/quote?mode=DELTA`. The API returns a `delta` block with a recommended `route`, optional `alternatives` (crosschain), the resolved `partner` fee, and the `spender` address to approve. There's no separate integrity token to carry forward; you pass `delta.route` into the build step.

### 2. Build

You `POST /v2/delta/orders/build` with the unmodified `delta.route` from step 1 and `owner` set to the user's address. The API returns `{ toSign: { domain, types, value }, orderHash }`. The server composes the EIP-712 domain, types, and order struct for you.

<Warning>
  Pass `delta.route` **verbatim** from the quote response. Reordering or re-encoding it will cause the build call to reject.
</Warning>

### 3. Sign

The user signs the returned `toSign` typed data with their wallet. The build response carries the exact domain, types, and struct layout. Delta uses **ERC-2098 compact signatures** (64 bytes, not 65). Most modern libraries (viem, ethers v6, wagmi) produce or accept compact sigs natively. The user pays **no gas** for this step; it's a pure off-chain message.

### 4. Auction

You `POST /v2/delta/orders` with `order` (the `toSign.value`), the `signature`, `chainId`, and your `partner`. The order server persists it and runs a [sealed-bid auction](/solver-network/sealed-bid-auctions) across the **Portikus Network**: solvers bid in parallel without seeing each other's offers, and the best simulated outcome wins. The winning solver commits fill calldata and the capital needed to deliver it; they take on inventory and pricing risk in exchange for the spread.

### 5. Settle

The protocol settlement layer calls `settle(...)` on the Delta contract (`0x0000000000bbF5c5Fd284e657F01Bd000933C96D`, same address on every supported chain) with the signed order and the winning solver's fill calldata. The contract verifies the signature, pulls `srcToken` from the user via the approved spender (the Delta contract itself), runs the fill, and delivers `destToken` to the user. If settlement fails, nothing is pulled from the user. You track progress via `GET /v2/delta/orders/{orderId}` until the order reaches a terminal status (`COMPLETED`, `EXPIRED`, `FAILED`, `CANCELLED`, or `REFUNDED`). Crosschain orders can report `REFUNDING` before `REFUNDED` while Velora verifies the bridge refund transaction.

## Why this design

<CardGroup cols={2}>
  <Card title="Gasless for users" icon="gas-pump">
    Users sign off-chain. Settlement gas is handled inside the Delta flow.
  </Card>

  <Card title="MEV-protected" icon="shield">
    Orders are auctioned privately. There's no public mempool to sandwich.
  </Card>

  <Card title="Solver competition" icon="trophy">
    Solvers compete on price. The user always gets the best committed fill.
  </Card>

  <Card title="Atomic risk model" icon="lock">
    User funds only leave the wallet when settlement succeeds on-chain. A failed fill costs the user neither funds nor gas.
  </Card>
</CardGroup>

## Related pages

* [Portikus Network](/solver-network/portikus) — the intent infrastructure behind stage 4 and 5.
* [Sealed-bid auctions](/solver-network/sealed-bid-auctions) — how the auction picks a winner and resists manipulation.
* [Quickstart](/overview/quickstart) — run the flow end-to-end with cURL.
* [Integrate → Delta swap](/integrate/api/delta-swap) — this flow as a hands-on API walkthrough.
* [Integrate → Limit orders](/integrate/api/limit-orders) and [TWAP](/integrate/api/twap) — the same flow with a price constraint or a schedule.
* [Delta contract](/resources/chains-and-contracts) — on-chain entry point and per-chain addresses.