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

# Sell native ETH with Delta

> Sell native ETH through Delta: deposit the ETH into the Delta contract as dETH with one transaction that also authorizes the order on-chain. No ERC-20 approval, no off-chain signature.

Delta orders are gasless because a signed intent lets the Delta contract pull an ERC-20 from the user's wallet at settlement. Native ETH can't work that way: a signature can't carry ETH, and there is no `approve` on the native token. So a native-source Delta order adds **one on-chain transaction** to the flow: the user deposits the ETH into the Delta contract, where it's held as **`dETH`** (the Delta Wrapped Native token, 1:1), and that same transaction authorizes the order — no ERC-20 approval and no off-chain signature needed.

Everything else — quote, build, submit, auction, settlement — is the standard [Delta swap](/docs/integrate/api/delta-swap) flow.

## How it differs from an ERC-20 source

| | ERC-20 source | Native ETH source |
| - | - | - |
| `srcToken` | token address | placeholder `0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE` |
| Approval / permit | one-time `approve` or a signed permit | none |
| Funds before settlement | stay in the user's wallet | deposited into Delta, held as `dETH` |
| Order authorization | off-chain EIP-712 signature | on-chain pre-signature, set by the deposit transaction |
| `signature` field on submit | ERC-2098 compact signature | the literal string `"0x"` |
| On-chain transactions | 0–1 (the approve, if needed) | 1 (`depositNativeAndPreSign`, pays gas) |
| Status right after submit | `PENDING` | `AWAITING_SIGNATURE` until the deposit transaction is seen |
| If the order expires unfilled | funds never left the wallet | Velora refunds the deposit automatically; status becomes `REFUNDED` |

The swap itself is still gasless and MEV-protected — the one gas-paying step is the deposit, playing the role the `approve` transaction plays for an ERC-20. And if the user already holds enough `dETH` (from an earlier deposit or an unfilled order), no deposit is needed at all: the standard sign-and-submit flow works verbatim and the whole trade is gasless.

## The flow

<Steps>
  <Step title="Quote">
    `GET /v2/quote?mode=DELTA` with `srcToken=0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`. Nothing native-specific in the request or response.
  </Step>

  <Step title="Build">
    `POST /v2/delta/orders/build` with the `delta.route` verbatim, as usual. Keep the returned `orderHash` — the deposit transaction needs it.
  </Step>

  <Step title="Submit with signature “0x”">
    `POST /v2/delta/orders` with the built `order` and `signature: "0x"`. There is nothing to sign off-chain; the order is stored in status `AWAITING_SIGNATURE` and waits for the on-chain authorization.
  </Step>

  <Step title="Deposit and pre-sign in one transaction">
    The user sends `depositNativeAndPreSign(orderHash)` to the **Delta contract** with `value` equal to the order's `srcAmount`. It wraps the ETH into `dETH` and registers the order hash as pre-signed, in one transaction.
  </Step>

  <Step title="Auction and settlement">
    Velora picks up the deposit event, validates the order, and moves it to `PENDING`. From there it runs through the auction and settles like any other Delta order. Poll `GET /v2/delta/orders/{orderId}` as usual.
  </Step>
</Steps>

The quote, build, and submit calls look exactly like the [Delta swap walkthrough](/docs/integrate/api/delta-swap), so only the two native-specific steps are shown here. Submitting the order:

```bash theme={null}
curl -X POST 'https://api.velora.xyz/v2/delta/orders' \
  -H 'Content-Type: application/json' \
  -d '{
    "chainId": 1,
    "order": { "...": "toSign.value from the build response, sent verbatim" },
    "signature": "0x",
    "partner": "my-app-name"
  }'
```

Then the deposit, from the user's wallet (viem shown; any library works):

```ts theme={null}
import { parseAbi } from "viem";

const DELTA_CONTRACT = "0x0000000000bbF5c5Fd284e657F01Bd000933C96D"; // same address on every Delta chain

const hash = await walletClient.writeContract({
  address: DELTA_CONTRACT,
  abi: parseAbi(["function depositNativeAndPreSign(bytes32 orderHash) payable"]),
  functionName: "depositNativeAndPreSign",
  args: [orderHash],                    // from the build response
  value: BigInt(order.srcAmount),       // from toSign.value
});
```

Once the transaction is mined the order leaves `AWAITING_SIGNATURE` within a few seconds. Submitting the order before sending the deposit is the intended ordering — it gives Velora the order hash to watch for.

<Warning>
  Send the deposit with `value` equal to the order's `srcAmount` (read it from `toSign.value.srcAmount`). Depositing less leaves the order stuck without sufficient balance; depositing more is safe — the excess stays as withdrawable `dETH`.
</Warning>

### If the user already holds dETH

`dETH` deposited earlier — say, from a cancelled order — funds new orders directly. If the user's `dETH` balance covers `srcAmount`, skip the deposit: have them sign `toSign` off-chain and submit with the real signature, exactly like an ERC-20 source. No approval is needed either way; the Delta contract has built-in access to `dETH` balances for settling signed orders.

## When the order doesn't fill

* **Expired**: Velora automatically returns the deposited ETH to the owner's wallet. The order's status becomes `REFUNDED` — for a native-source order this is a normal outcome, not a bridge failure. (TWAP orders are the exception: an expired native TWAP is not auto-refunded; the remaining balance stays as `dETH` for the user to unwrap.)
* **Cancelled**: cancellation invalidates the order but does not move funds. The deposit stays as `dETH`, which the user can spend on a new order or unwrap back to ETH at any time (see below).
* **Partially filled**: the unfilled remainder stays as `dETH`, same as a cancellation.

<Warning>
  A user who unwraps or transfers their `dETH` while a native-source order is still open removes the balance that order settles from — the order will suspend or fail. Treat open native orders as a claim on the user's `dETH` balance.
</Warning>

## Buying native ETH

Native ETH as the **destination** token needs none of the above. Use the same placeholder as `destToken`, and the beneficiary receives actual ETH — not dETH or WETH — at settlement. There's no unwrap step to build. One caveat: if the beneficiary is a smart contract, it must accept plain ETH transfers (a payable `receive`/fallback), or settlement will fail.

## What dETH is

`dETH` is an ERC-20 (the `DeltaWrappedNative` contract) that wraps the chain's native token 1:1: ETH on Ethereum, BNB on BSC, and so on. Its underlying is the chain's wrapped native (WETH), so `dETH` and native are interchangeable at a 1:1 rate.

The Delta contract has built-in access to `dETH` balances — that's what lets a native order settle with no ERC-20 approval: at settlement the user's `dETH` is burned and the ETH goes to the winning solver's fill. `dETH` is deployed alongside the Delta contract and lives at the same address on every Delta chain:

```
0x0a0d53b6684c7b32b4cbef5fe8483bfcc8406742
```

This address is for reference and on-chain verification. In the API flow you always pass the native placeholder as `srcToken`; on any chain where native isn't enabled as a Delta source, the quote fails with `ETH as source token is not supported`. The [Chains & contracts](/docs/resources/chains-and-contracts) table is the canonical list of Delta-enabled chains. Where Delta isn't deployed, use a [Market swap](/docs/integrate/api/market-swap) instead.

## Unwrapping back to ETH

`dETH` works like WETH in both directions, so a deposit is never a lock-in. Any `dETH` a user holds can be unwrapped back to native ETH at any time, 1:1, by calling `withdrawNative` on the `dETH` contract:

```solidity theme={null}
withdrawNative(uint256 amount, address owner, address receiver)
```

It burns the `dETH` and sends native ETH to `receiver`. `depositNative` is the reverse (and sending ETH straight to the contract wraps it automatically). `dETH` is also a normal ERC-20, so a user can instead swap it to anything through a [Market swap](/docs/integrate/api/market-swap). In the Velora app that's a prefilled swap link, for example `dETH` to ETH on Ethereum:

```
https://www.velora.xyz/app/swap/0x0a0d53B6684C7B32B4cBeF5fE8483bFcc8406742-0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE/1/SELL?network=ethereum
```

<Note>
  `dETH` can also hold yield-bearing positions for Productive orders, where the wrapped balance earns yield in a strategy while the order rests. That's a separate, advanced flow and isn't covered here.
</Note>

## Related pages

* [Delta swap](/docs/integrate/api/delta-swap): the full source-to-destination flow native ETH plugs into.
* [Trading modes](/docs/integrate/trading-modes) covers when to use Delta vs Market.
* [Delta → How it works](/docs/delta/how-it-works) for the auction and settlement model.
* [Chains & contracts](/docs/resources/chains-and-contracts) for supported chains and contract references.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.