From bcb0b40e99eec265b9b24b458733380f30a58b20 Mon Sep 17 00:00:00 2001 From: nazariikyselevych Date: Wed, 10 Jun 2026 23:34:36 +0300 Subject: [PATCH] docs: clarify Delta settlement actor --- delta/crosschain-delta.mdx | 8 +++++--- delta/how-it-works.mdx | 14 ++++++++------ delta/overview.mdx | 4 ++-- for-agents/decision-tables.mdx | 4 ++-- .../prompt-library/crosschain-aave-deposit.mdx | 2 +- integrate/api/delta-swap.mdx | 4 ++-- integrate/api/market-swap.mdx | 2 +- integrate/api/twap.mdx | 4 ++-- overview/product-stack/limit-orders.mdx | 2 +- resources/chains-and-contracts.mdx | 4 ++-- .../migrations/market-to-delta-parallel.mdx | 2 +- sdk/products/delta.mdx | 6 +++--- sdk/products/swap.mdx | 2 +- sdk/products/twap.mdx | 4 ++-- solver-network/portikus.mdx | 2 +- solver-network/sealed-bid-auctions.mdx | 16 ++++++++-------- 16 files changed, 42 insertions(+), 38 deletions(-) diff --git a/delta/crosschain-delta.mdx b/delta/crosschain-delta.mdx index 0a4293f..fe3e135 100644 --- a/delta/crosschain-delta.mdx +++ b/delta/crosschain-delta.mdx @@ -18,6 +18,7 @@ sequenceDiagram participant API as Velora API participant OS as Order Server participant Solvers as Solver network
(Portikus) + participant Settlement as Protocol settlement participant Delta as Delta contract
source chain participant Bridge as Bridge provider
(CCTP / Across / Relay / ...) participant Dest as Destination chain @@ -38,11 +39,12 @@ sequenceDiagram rect rgb(232, 245, 233) note over OS,Solvers: Source-chain Delta auction OS->>Solvers: Broadcast order - Solvers-->>OS: Competing fills + Solvers-->>OS: Competing fill calldata OS->>Solvers: Award winner end - Solvers->>Delta: Settle on source chain + OS->>Settlement: Winning calldata + signed order + Settlement->>Delta: Settle on source chain Delta->>Bridge: Initiate selected bridge leg API-->>DApp: status = BRIDGING @@ -115,7 +117,7 @@ Then use the same build, sign, and submit calls as a same-chain Delta order: Delta does not ask the user to perform a separate bridge transaction. The user signs a Delta order that already contains the selected destination chain, output token, and bridge execution data. -At settlement time, the winning solver executes the source-chain Delta order through Portikus. If the order is crosschain, the settlement module sends the post-swap output into the selected bridge module instead of transferring it locally to the user. The destination output is delivered to the order beneficiary on the destination chain. +At settlement time, the protocol executes the winning solver's source-chain calldata through Portikus. If the order is crosschain, the settlement module sends the post-swap output into the selected bridge module instead of transferring it locally to the user. The destination output is delivered to the order beneficiary on the destination chain. For USDC routes, CCTP support is USDC-specific. Delta can still quote arbitrary source tokens when the source-chain leg swaps into the bridge token first, but the CCTP bridge leg itself moves USDC between supported chains. diff --git a/delta/how-it-works.mdx b/delta/how-it-works.mdx index 115aced..71647fb 100644 --- a/delta/how-it-works.mdx +++ b/delta/how-it-works.mdx @@ -4,7 +4,7 @@ description: "From signed intent to on-chain settlement: the full Delta flow end keywords: ["delta","architecture","flow","portikus","solver"] --- -Delta separates **what the user wants** (the intent) from **how it gets executed** (the solver fill). The user signs once, off-chain. Solvers on the [Portikus Network](/solver-network/portikus) race to fill the order at the best price, then settle on-chain via the Delta contract. +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 @@ -16,6 +16,7 @@ sequenceDiagram participant API as Velora API participant OS as Order Server participant Solvers as Portikus Network
(solvers) + participant Settlement as Protocol settlement participant Delta as Delta contract
0x...c96d User->>DApp: "Swap 1000 USDC for USDT" @@ -34,11 +35,12 @@ sequenceDiagram rect rgb(232, 245, 233) note over OS,Solvers: Off-chain auction OS->>Solvers: Broadcast order - Solvers-->>OS: Competing fill quotes + Solvers-->>OS: Competing fill calldata OS->>Solvers: Award winner end - Solvers->>Delta: settle(order, signature, fillData) + OS->>Settlement: Winning calldata + signed order + Settlement->>Delta: settle(order, signature, fillData) Delta-->>User: destToken delivered loop Until terminal status @@ -67,17 +69,17 @@ The user signs the returned `toSign` typed data with their wallet. The build res ### 4. Auction -You `POST /delta/v2/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 to fill the order with their own capital; they take on inventory and settlement risk in exchange for the spread. +You `POST /delta/v2/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 winning solver calls `settle(...)` on the Delta contract (`0x0000000000bbF5c5Fd284e657F01Bd000933C96D`, same address on every supported chain). 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. You track progress via `GET /delta/v2/orders/{orderId}` until the order reaches a terminal status (`COMPLETED`, `EXPIRED`, `FAILED`, or `CANCELLED`). +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. You track progress via `GET /delta/v2/orders/{orderId}` until the order reaches a terminal status (`COMPLETED`, `EXPIRED`, `FAILED`, or `CANCELLED`). ## Why this design - Users sign off-chain. Solvers pay gas and recoup it from their margin. + Users sign off-chain. Settlement gas is handled inside the Delta flow. Orders are auctioned privately. There's no public mempool to sandwich. diff --git a/delta/overview.mdx b/delta/overview.mdx index ae49be8..e40b0a0 100644 --- a/delta/overview.mdx +++ b/delta/overview.mdx @@ -3,13 +3,13 @@ title: "Why Delta" description: "Delta is Velora's intent protocol: gasless, MEV-protected, Crosschain swaps that settle in one signature. Here's what makes it different from a regular swap." --- -Delta is Velora's intent protocol. Instead of building, signing, and submitting an on-chain transaction yourself, you sign an off-chain **order** describing what you want, and a competitive network of solvers (the [Portikus Network](/solver-network/portikus)) fills it on your behalf. +Delta is Velora's intent protocol. Instead of building, signing, and submitting an on-chain transaction yourself, you sign an off-chain **order** describing what you want. A competitive network of solvers (the [Portikus Network](/solver-network/portikus)) submits fill calldata, and Delta settles the winning fill for you. ## What you get - The user never pays gas. Solvers cover execution cost out of their margin. + The user never pays gas. Execution cost is handled inside the Delta settlement flow. Orders are filled via sealed-bid auction. No public mempool. No sandwich risk. diff --git a/for-agents/decision-tables.mdx b/for-agents/decision-tables.mdx index 171cdef..6712093 100644 --- a/for-agents/decision-tables.mdx +++ b/for-agents/decision-tables.mdx @@ -11,7 +11,7 @@ Use these tables when an agent needs to choose the next Velora action. Prefer ex | User intent | Prefer | Agent action | Why | |---|---|---|---| | "Swap token A to token B" | `mode=ALL` | Call [`GET /v2/quote`](/api-reference/market/quote) with `mode=ALL`, `chainId`, token addresses, amount, slippage, and the app or project `partner` value. | Velora can choose the best available path. | -| "Gasless swap" or "I have no gas" | Delta | Call `GET /v2/quote` with `mode=DELTA`. Continue only if the response includes a `delta` block. | Delta uses an EIP-712 signature and solver settlement. | +| "Gasless swap" or "I have no gas" | Delta | Call `GET /v2/quote` with `mode=DELTA`. Continue only if the response includes a `delta` block. | Delta uses an EIP-712 signature, a solver auction, and protocol settlement. | | "Place a limit order" or "trade only if price reaches X" | Delta `LIMIT` order | Collect the target price, side, token pair, chain, amount, expiry, recipient, and partially-fillable preference before building the order. | New limit orders are Delta orders over the Delta API, not AugustusRFQ. | | "TWAP this trade" or "split this order over time" | Delta TWAP | Collect side, total amount, number of slices, cadence/interval, chain, token pair, slippage/price constraints, deadline/expiry, recipient, and max source spend for buy TWAPs. | TWAP is one scheduled Delta order, not repeated independent swaps. Preserve sell-vs-buy amount semantics. | | "Best price" | `mode=ALL` | Quote with `mode=ALL`, then branch on `delta` vs `market`. | Velora can choose the best available path. | @@ -98,7 +98,7 @@ Use these tables when an agent needs to choose the next Velora action. Prefer ex | HMAC or quote validation error | The quote payload is stale or mismatched. | Requote and rebuild from the same fresh response. | | Approval transaction succeeds but swap still fails allowance check | Approval went to the wrong spender or wrong chain. | Check the spender for the selected mode and ask for a new approval if needed. | | User rejects transaction or signature | User declined the action. | Stop. Do not retry automatically. | -| Delta order remains pending | Solver settlement is still in progress or the order may expire. | Poll status with backoff and show the latest order state. Do not resubmit blindly. | +| Delta order remains pending | The auction or protocol settlement is still in progress, or the order may expire. | Poll status with backoff and show the latest order state. Do not resubmit blindly. | | Transaction reverts | Market transaction failed on-chain. | Surface the revert, suggest requoting, and avoid replaying the same calldata. | ## Guardrails for agents diff --git a/for-agents/prompt-library/crosschain-aave-deposit.mdx b/for-agents/prompt-library/crosschain-aave-deposit.mdx index 385acda..af8fc35 100644 --- a/for-agents/prompt-library/crosschain-aave-deposit.mdx +++ b/for-agents/prompt-library/crosschain-aave-deposit.mdx @@ -20,7 +20,7 @@ Requirements: - The user holds (say) USDC on Polygon. They want to end up with aUSDC supplied to Aave v3 on Base. One signature. - Use Velora's Crosschain Delta V2 API. Endpoints: `GET /v2/quote` (with `mode=DELTA` and `destChainId` per [Crosschain Delta docs]), `POST /delta/v2/orders/build`, `POST /delta/v2/orders`. - Always set `partner` to the host app's partner identifier on every quote call (`my-app-name` is only a placeholder). -- The solver fills on Base; you provide a post-fill calldata hook that calls `aavePool.supply(USDC, amount, user, 0)` against Aave v3's Base pool address. +- The winning fill resolves on Base; you provide a post-fill calldata hook that calls `aavePool.supply(USDC, amount, user, 0)` against Aave v3's Base pool address. - Read the Aave v3 pool address from a constants file (do NOT hardcode in component code). - Surface clear status: "Quoting" → "Signing" → "Filling on Base" → "Depositing into Aave" → "Done". - On failure at any stage, return the user to a recoverable state. Cancel the Delta order if it hasn't filled. diff --git a/integrate/api/delta-swap.mdx b/integrate/api/delta-swap.mdx index 0ed9473..04999bb 100644 --- a/integrate/api/delta-swap.mdx +++ b/integrate/api/delta-swap.mdx @@ -4,7 +4,7 @@ description: "Integrate a gasless, MEV-protected Delta swap over the REST API: q keywords: ["delta api", "gasless swap", "intent", "quote", "orders build", "orders submit", "dETH", "native eth"] --- -A **Delta swap** lets your user sign one off-chain intent and have the [Portikus Network](/solver-network/portikus) settle it gaslessly, with MEV protection. This page walks the whole integration end to end: quote the trade, build the order, have the user sign it, submit it, and poll until it settles. Every example is a `curl` or `fetch` call against `https://api.velora.xyz`; no SDK required. +A **Delta swap** lets your user sign one off-chain intent that Delta settles gaslessly through the [Portikus Network](/solver-network/portikus), with MEV protection. This page walks the whole integration end to end: quote the trade, build the order, have the user sign it, submit it, and poll until it settles. Every example is a `curl` or `fetch` call against `https://api.velora.xyz`; no SDK required. For the conceptual model behind the auction and settlement, see [Delta → How it works](/delta/how-it-works). For a typed wrapper over these same calls, see [SDK → Delta](/sdk/products/delta). @@ -111,7 +111,7 @@ The relayer validates the signature, balance, and allowance, then enrolls the or curl 'https://api.velora.xyz/delta/v2/orders/{orderId}' ``` -Poll until the order reaches a terminal status. A market Delta order settles in seconds once a solver wins the auction, so a short interval is fine. +Poll until the order reaches a terminal status. A market Delta order usually settles in seconds once the auction has a winning fill, so a short interval is fine. For a human-readable view (status, fills, the settlement transaction), open the order in the Velora explorer at `https://explorer.velora.xyz/order/{orderId}`. It's handy for debugging and for linking users to their order. diff --git a/integrate/api/market-swap.mdx b/integrate/api/market-swap.mdx index 8644deb..5765eae 100644 --- a/integrate/api/market-swap.mdx +++ b/integrate/api/market-swap.mdx @@ -6,7 +6,7 @@ keywords: ["market api", "swap", "dex aggregator api", "price route", "build tra A **Market swap** routes through DEX liquidity and settles in a single on-chain transaction that **your user signs and broadcasts**. This page walks the whole integration request by request: get a price route, build the calldata, approve the router, and send the transaction. Every example targets `https://api.velora.xyz`; no SDK required. -Market is the right path when the user has gas and wants synchronous, atomic settlement. For gasless, MEV-protected swaps the solver network settles on the user's behalf, use a [Delta swap](/integrate/api/delta-swap) instead. For the conceptual model, see [Market → How it works](/market/how-it-works); for a typed wrapper, see [SDK → Market](/sdk/products/swap). +Market is the right path when the user has gas and wants synchronous, atomic settlement. For gasless, MEV-protected swaps that Delta settles from a signed intent, use a [Delta swap](/integrate/api/delta-swap) instead. For the conceptual model, see [Market → How it works](/market/how-it-works); for a typed wrapper, see [SDK → Market](/sdk/products/swap). ## The flow diff --git a/integrate/api/twap.mdx b/integrate/api/twap.mdx index 0480907..9b93768 100644 --- a/integrate/api/twap.mdx +++ b/integrate/api/twap.mdx @@ -1,10 +1,10 @@ --- title: "TWAP" -description: "Schedule a TWAP over the REST API. A TWAP is one Delta order the user signs once; solvers settle it slice-by-slice over time. Quote one slice, build with orderType TWAPOrder, end-to-end." +description: "Schedule a TWAP over the REST API. A TWAP is one Delta order the user signs once; Delta settles it slice-by-slice over time. Quote one slice, build with orderType TWAPOrder, end-to-end." keywords: ["twap api", "delta", "scheduled order", "slices", "time-weighted average price", "gasless", "TWAPOrder"] --- -A **TWAP** (time-weighted average price) splits a larger trade into slices executed over time. On Velora it's **one Delta order**, not a loop of swaps: the user signs a single scheduled order, and the [Portikus Network](/solver-network/portikus) settles each eligible slice gaslessly until the order completes or expires. This page walks the whole integration with direct calls to `https://api.velora.xyz`. +A **TWAP** (time-weighted average price) splits a larger trade into slices executed over time. On Velora it's **one Delta order**, not a loop of swaps: the user signs a single scheduled order, and Delta settles each eligible slice gaslessly through the [Portikus Network](/solver-network/portikus) until the order completes or expires. This page walks the whole integration with direct calls to `https://api.velora.xyz`. It's the [Delta swap](/integrate/api/delta-swap) flow with one wrinkle that trips people up: **you quote a single slice**, not the whole order, and the server multiplies it across the schedule. For the conceptual model, see [Product stack → TWAP](/overview/product-stack/twap). For a typed wrapper, see [SDK → TWAP](/sdk/products/twap). diff --git a/overview/product-stack/limit-orders.mdx b/overview/product-stack/limit-orders.mdx index 07bc934..debcfb7 100644 --- a/overview/product-stack/limit-orders.mdx +++ b/overview/product-stack/limit-orders.mdx @@ -15,7 +15,7 @@ Limit orders separate **trade intent** from **trade timing**. Delta represents t - The maker says what they are willing to sell or buy. - The maker sets constraints such as price, token pair, amount, expiry, and eligible taker behavior. - When the limit price becomes reachable, the order enters the Delta pricing auction. Solvers from the Portikus network act as takers and compete on fill quotes, so the user gets the best committed return, not just the limit price. -- Delta settles the order on-chain when the winning solver fills it. +- Delta settles the order on-chain when the winning solver's fill satisfies it. This gives users price control without forcing them to watch the market and submit a swap at the exact moment liquidity appears. diff --git a/resources/chains-and-contracts.mdx b/resources/chains-and-contracts.mdx index 75fa9f2..0d47592 100644 --- a/resources/chains-and-contracts.mdx +++ b/resources/chains-and-contracts.mdx @@ -56,7 +56,7 @@ Legacy router versions. Still operational but new integrations should target v6. ### Delta contract -On-chain entry point that validates signed Delta orders and dispatches settlement to Portikus solvers. The Delta contract is the spender on EIP-712 typed-data approvals: token approvals for Delta flows must be granted to this address, **not** to Augustus. Deployed at the same address across every Delta-enabled chain. +On-chain entry point that validates signed Delta orders and executes the winning Portikus fill through settlement. The Delta contract is the spender on EIP-712 typed-data approvals: token approvals for Delta flows must be granted to this address, **not** to Augustus. Deployed at the same address across every Delta-enabled chain. ### Delta Wrapped Native (dETH) @@ -64,7 +64,7 @@ The wrapped-native token Delta uses to represent native ETH (and other native ga ### Portikus settlement -The solver-facing settlement infrastructure. Solvers execute fills against Portikus; the Delta contract reconciles outcomes back to the user. +The solver-facing settlement infrastructure. Solvers compete by providing fills through Portikus; the Delta contract reconciles the winning outcome back to the user. ### AugustusRFQ diff --git a/resources/migrations/market-to-delta-parallel.mdx b/resources/migrations/market-to-delta-parallel.mdx index 1381f9d..f926c00 100644 --- a/resources/migrations/market-to-delta-parallel.mdx +++ b/resources/migrations/market-to-delta-parallel.mdx @@ -10,7 +10,7 @@ Nothing. This migration is opt-in. Your existing Market integration keeps workin ## Why migrate -Delta intents are gasless and MEV-protected: users sign once and the solver network fills. And you don't rewrite anything to get there. `GET /v2/quote` with `mode=ALL` returns either a Delta `delta` block or a Market `market` block (the same shape as `/prices`'s `priceRoute`). Velora picks the winner server-side; you branch on which block is present. See [Trading modes](/integrate/trading-modes). +Delta intents are gasless and MEV-protected: users sign once, solvers compete to fill, and Delta settles the winning fill. And you don't rewrite anything to get there. `GET /v2/quote` with `mode=ALL` returns either a Delta `delta` block or a Market `market` block (the same shape as `/prices`'s `priceRoute`). Velora picks the winner server-side; you branch on which block is present. See [Trading modes](/integrate/trading-modes). ## Steps diff --git a/sdk/products/delta.mdx b/sdk/products/delta.mdx index fae2ad4..6de137c 100644 --- a/sdk/products/delta.mdx +++ b/sdk/products/delta.mdx @@ -1,10 +1,10 @@ --- title: "Delta" -description: "Submit, sign, and track gasless Delta intents from sdk.delta, where solvers execute swaps on the user's behalf." +description: "Submit, sign, and track gasless Delta intents from sdk.delta, where solvers compete to provide executable fills." keywords: ["sdk", "delta", "intents", "gasless", "submitDeltaOrder"] --- -A **swap** in Velora settles through one of two execution paths: **Delta** (this page) or [**Market**](/sdk/products/swap). Delta wraps the [Delta API](/delta/overview): gasless, MEV-protected swaps where the user signs an off-chain order, and a network of solvers (Portikus) competes to fill it. The user pays no gas, and the solver covers execution cost out of their margin. +A **swap** in Velora settles through one of two execution paths: **Delta** (this page) or [**Market**](/sdk/products/swap). Delta wraps the [Delta API](/delta/overview): gasless, MEV-protected swaps where the user signs an off-chain order, and a network of solvers (Portikus) competes to provide the best fill. The user pays no gas; settlement happens through the Delta flow. Delta is also the engine behind two other products in the SDK: [Limit orders](/sdk/products/limit-orders) (a Delta order with a target price) and [TWAP](/sdk/products/twap) (a Delta order split into scheduled slices). This page covers the **market** Delta order, and those pages build on the same flow. @@ -16,7 +16,7 @@ Delta orders are **server-built**: you don't compose EIP-712 typed data locally. - The user shouldn't pay gas, or doesn't have gas on the source chain. - You want MEV protection. Orders fill via private auction, not the public mempool. -- You want a single signature to settle crosschain. See [Crosschain Delta](/delta/crosschain-delta). +- You want one signed intent to settle crosschain. See [Crosschain Delta](/delta/crosschain-delta). For swaps where the user submits the transaction themselves, see [Market](/sdk/products/swap). diff --git a/sdk/products/swap.mdx b/sdk/products/swap.mdx index b24faaf..79b1281 100644 --- a/sdk/products/swap.mdx +++ b/sdk/products/swap.mdx @@ -4,7 +4,7 @@ description: "Build, approve, and execute Market Swaps through sdk.swap. The use keywords: ["sdk", "swap", "market", "buildTx", "getRate"] --- -A **swap** in Velora settles through one of two execution paths: [**Delta**](/sdk/products/delta) or **Market** (this page). Market is the atomic on-chain path. It wraps the [Market API](/market/overview) for rates, allowances, and transaction-building, and the **user** signs and submits the transaction themselves. For gasless swaps where solvers settle on the user's behalf, see [Delta](/sdk/products/delta). +A **swap** in Velora settles through one of two execution paths: [**Delta**](/sdk/products/delta) or **Market** (this page). Market is the atomic on-chain path. It wraps the [Market API](/market/overview) for rates, allowances, and transaction-building, and the **user** signs and submits the transaction themselves. For gasless swaps that settle from a signed intent, see [Delta](/sdk/products/delta). This path is exposed as `sdk.swap` in code (the namespace predates the Delta/Market naming). `sdk.swap` is the Market execution path for swaps. diff --git a/sdk/products/twap.mdx b/sdk/products/twap.mdx index 9186b76..2fe238a 100644 --- a/sdk/products/twap.mdx +++ b/sdk/products/twap.mdx @@ -1,10 +1,10 @@ --- title: "TWAP" -description: "Split a large trade into scheduled slices from the SDK. In Velora, a TWAP is a Delta order the user signs once and solvers settle slice-by-slice over time." +description: "Split a large trade into scheduled slices from the SDK. In Velora, a TWAP is a Delta order the user signs once and Delta settles slice-by-slice over time." keywords: ["sdk", "twap", "delta", "scheduled", "slices", "gasless"] --- -A **TWAP** (time-weighted average price) splits a larger trade into smaller slices executed over time. In Velora, a TWAP is a **Delta order**: the user signs one scheduled order, and the [Portikus](/delta/overview) solver network settles each eligible slice gaslessly until the order completes or expires. +A **TWAP** (time-weighted average price) splits a larger trade into smaller slices executed over time. In Velora, a TWAP is a **Delta order**: the user signs one scheduled order, and Delta settles each eligible slice gaslessly through the [Portikus](/delta/overview) solver network until the order completes or expires. You build TWAPs through the same `sdk.delta` module as market Delta orders, using `submitTWAPDeltaOrder` (or the `buildTWAPDeltaOrder` split flow). The defining inputs are the **total amount**, the **number of slices**, and the **interval** between them. diff --git a/solver-network/portikus.mdx b/solver-network/portikus.mdx index 6179bee..d5dbdc7 100644 --- a/solver-network/portikus.mdx +++ b/solver-network/portikus.mdx @@ -116,7 +116,7 @@ An intent that doesn't fill in one [auction round](/solver-network/sealed-bid-au Solvers bid against each other for the right to fill. Your users get the best committed price, not the first one offered. - Solvers pay gas from their margin. The user signs an off-chain message and receives tokens. + Settlement gas is handled inside the Portikus flow. The user signs an off-chain message and receives tokens. A fill below the signed minimum reverts. No solver, including the winner, can deliver less. diff --git a/solver-network/sealed-bid-auctions.mdx b/solver-network/sealed-bid-auctions.mdx index d1ea5b5..663574b 100644 --- a/solver-network/sealed-bid-auctions.mdx +++ b/solver-network/sealed-bid-auctions.mdx @@ -4,7 +4,7 @@ description: "How sealed-bid auctions work, why they suit DeFi trading, and how keywords: ["sealed-bid auction", "solver auction", "MEV protection", "private auction", "delta auction"] --- -Sealed-bid auctions are a Portikus feature: they're how the [Portikus Network](/solver-network/portikus) fills intents for any app built on it, Delta included. In a sealed-bid auction, every bidder submits one private bid without seeing what anyone else offered. Every Delta order is filled through one: solvers bid blind, the bid with the best simulated outcome wins, and the settlement contract enforces the minimum the user signed. The result is a market where the only way for a solver to win is to quote its true best price. +Sealed-bid auctions are a Portikus feature: they're how the [Portikus Network](/solver-network/portikus) fills intents for any app built on it, Delta included. In a sealed-bid auction, every bidder submits one private bid without seeing what anyone else offered. Every Delta order is filled through one: solvers bid blind with executable calldata, the best simulated outcome wins, and protocol settlement executes the winning calldata while enforcing the minimum the user signed. The result is a market where the only way for a solver to win is to quote its true best price. ## How a sealed-bid auction works @@ -38,7 +38,7 @@ flowchart TB C --> D[Validate and simulate every bid] D --> F{Viable bid?} F -- "yes" --> G[Best simulated outcome wins] - G --> H[Winner settles on-chain] + G --> H[Protocol executes winning calldata] H --> I{Settled?} I -- "yes" --> J([Completed]) I -. "no" .-> A @@ -53,11 +53,11 @@ flowchart TB Three details do most of the work: -1. **A bid is a commitment, not a quote.** Solvers don't reply with a number; they reply with the exact calldata that executes the fill and the amount it delivers. There's no second look and no renegotiation after seeing the field. +1. **A bid is a commitment, not a quote.** Solvers don't reply with a number; they reply with the exact calldata the protocol can execute and the amount that calldata should deliver. There's no second look and no renegotiation after seeing the field. 2. **Bids are ranked by simulation, not by claim.** Before picking a winner, the order server simulates every bid against current chain state and ranks bids by what they actually produce. A solver that promises a great price but whose calldata reverts or underdelivers doesn't win. 3. **Surplus flows back.** When the winning fill beats the quoted price, the user receives the improvement; a portion is split between the integrator and the protocol. Solvers compete on execution quality, and users capture it. -If no viable bid arrives, or the winner's settlement fails on-chain, the order isn't stuck: it enters the next round and gets auctioned again, until it fills or its deadline expires. +If no viable bid arrives, or the winning calldata fails during on-chain settlement, the order isn't stuck: it enters the next round and gets auctioned again, until it fills or its deadline expires. ## What stops a malicious solver @@ -67,14 +67,14 @@ Each layer of the auction closes a different attack: |---|---| | Watch rivals' bids and undercut by a tick | Bids are sealed. Solvers see only the order, never each other's offers. | | Claim a great price, deliver a bad fill | Every bid is simulated before the award. The ranking uses the simulated result, not the solver's claim. | -| Win the auction, then settle below the quote | The user's signed minimum is enforced by the settlement contract. A fill below it reverts on-chain. | -| Settle orders without participating honestly | Only solvers registered in the Portikus registry contract can settle. A misbehaving solver can be removed, and removal is enforced on-chain. | -| Win, then refuse to settle (griefing) | The order re-enters the next auction round. The user's funds never moved, so the failed solver wasted only its own auction slot. | +| Submit calldata that would deliver below the quote | The user's signed minimum is enforced by the settlement contract. A fill below it reverts on-chain. | +| Submit fill calldata without participating honestly | Only solvers registered in the Portikus registry contract can provide executable bids. A misbehaving solver can be removed, and removal is enforced on-chain. | +| Win with calldata that later reverts or becomes stale | The order re-enters the next auction round. The user's funds never moved, so the failed solver wasted only its own auction slot. | The pattern across all five: the auction never has to trust what a solver says. Bids are verified by simulation before the award, and the user's floor is verified by the contract after it. ## Related pages -- [Portikus Network](/solver-network/portikus) — the intent infrastructure that runs and settles these auctions. +- [Portikus Network](/solver-network/portikus) — the intent infrastructure behind these auctions. - [How it works](/delta/how-it-works) — where the auction sits in the full Delta flow. - [Why Delta](/delta/overview) — what the auction buys you as an integrator: gasless, MEV-protected swaps.