The flow at a glance
The five stages
1. Quote
You callGET /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
YouPOST /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.
3. Sign
The user signs the returnedtoSign 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
YouPOST /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 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 callssettle(...) 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
Gasless for users
Users sign off-chain. Settlement gas is handled inside the Delta flow.
MEV-protected
Orders are auctioned privately. There’s no public mempool to sandwich.
Solver competition
Solvers compete on price. The user always gets the best committed fill.
Atomic risk model
User funds only leave the wallet when settlement succeeds on-chain. A failed fill costs the user neither funds nor gas.
Related pages
- Portikus Network — the intent infrastructure behind stage 4 and 5.
- Sealed-bid auctions — how the auction picks a winner and resists manipulation.
- Quickstart — run the flow end-to-end with cURL.
- Integrate → Delta swap — this flow as a hands-on API walkthrough.
- Integrate → Limit orders and TWAP — the same flow with a price constraint or a schedule.
- Delta contract — on-chain entry point and per-chain addresses.