Skip to main content
Most Velora agent workflows follow the same loop:
  1. Normalize the user intent.
  2. Quote or construct the order.
  3. Build the executable payload.
  4. Ask the user to authorize the exact payload.
  5. Submit and track until the flow completes or fails.
The exact endpoint sequence depends on the selected execution path. Use Decision tables to choose the path before running this recipe.

​
Universal agent loop

StepAgent actionOutput
1. NormalizeResolve chain, tokens, amount, direction, recipient, execution preference, and constraints.Complete intent object
2. Quote or constructQuote swaps, or construct a limit order, TWAP, or OTC intent.Top-level delta, top-level market, or order draft
3. BuildBuild typed data or transaction calldata.EIP-712 payload or transaction request
4. AuthorizeAsk the user to review and sign or send.Signature or transaction hash
5. TrackPoll order status or transaction receipt.Filled, failed, expired, reverted, or pending
Do not ask the user to sign until chain, tokens, amount, recipient, order type, and execution path are final. If any material field changes, rebuild and ask again.

​
Delta Swap

Use Delta when the user wants gasless execution, MEV protection, solver competition, or a Delta-only flow. 
1. GET /v2/quote?mode=DELTA
2. POST /v2/delta/orders/build
   - pass the returned delta.route verbatim
   - set owner to the user's address
3. Ask the user to sign the returned toSign EIP-712 payload
4. POST /v2/delta/orders with order=toSign.value, signature, chainId, and partner
5. GET /v2/delta/orders/{orderId} until COMPLETED, FAILED, or EXPIRED
Agent rules:
  • Use chainId, not network, on quote requests.
  • Include a partner value on quote requests. Use the app or project partner key; examples use my-app-name only as a placeholder.
  • Pass the delta.route from the quote response into /v2/delta/orders/build unchanged, and submit toSign.value unchanged as order.
  • Do not grant approval to Augustus for a Delta order; approve the Delta contract (the spender from the quote response).
  • Track by Delta order ID, not by transaction hash.

​
Market Swap

Use Market when the user wants immediate on-chain settlement or when the selected quote response has a top-level market object. 
1. GET /v2/quote?mode=MARKET
2. POST /transactions/:chainId
3. Ask the user to review and send the transaction
4. Wait for the transaction receipt
5. Surface success, revert, or timeout
Agent rules:
  • Market is an on-chain transaction flow.
  • The user signs a transaction and pays gas.
  • Track with the transaction hash.
  • Requote if the transaction build fails, the quote expires, or balances materially change.
  • Do not submit a Market response as a Delta order.

​
Auto-route with mode=ALL

Use mode=ALL when the user asks for a normal swap or best available execution without choosing Delta or Market. 
1. GET /v2/quote?mode=ALL
2. If the top-level response field is delta, continue the Delta Swap flow from build onward
3. If the top-level response field is market, continue the Market Swap flow from transaction build onward
4. If neither field is present, stop and handle no-route
Agent rules:
  • mode=ALL returns one selected execution path, not both.
  • Branch on the top-level response field, not on the requested mode.
  • Ask before changing execution mode if the user explicitly requested Delta or Market.

​
Delta Limit Order

Use a Delta Limit Order when the user wants target-price execution, delayed settlement, or “only trade if price reaches X”. New integrations should describe the HTTP API flow directly: price the route, build a Delta order with type=LIMIT, sign the returned EIP-712 payload, submit the signed order, then track it through Delta order status. 
1. Normalize the target-price intent
2. GET /v2/delta/prices for the route
3. POST /v2/delta/orders/build
   - pass the returned route verbatim
   - set type=LIMIT at submission time
   - use limitAmount for the user's target-price constraint when needed
4. Ask the user to sign the returned toSign EIP-712 payload
5. POST /v2/delta/orders with order=toSign.value, signature, type=LIMIT, chainId, and partner
6. Track with GET /v2/delta/orders/{orderId}, GET /v2/delta/orders/hash/{hash}, or GET /v2/delta/orders
Agent rules:
  • Limit orders are Delta orders, not AugustusRFQ orders.
  • Preserve the user’s target price, side, amount, token pair, chain, recipient, expiry/deadline, and partially-fillable preference.
  • Treat LIMIT as the order type constraint; do not turn it into a Market Swap just because a spot quote is available.
  • Pass route into /v2/delta/orders/build unchanged, and submit toSign.value unchanged as order.
  • If the target price, expiry, amount, or recipient changes, rebuild and ask the user to sign again.

​
Delta TWAP

Use a Delta TWAP when the user wants one signed order to split execution across time. Delta exposes TWAP as advanced order families in /v2/delta/orders/build: orderType=TWAPOrder for sell-side schedules and orderType=TWAPBuyOrder for buy-side schedules. 
1. Normalize the TWAP schedule
2. GET /v2/delta/prices for one slice
   - Sell TWAP: route.origin.input.amount = floor(totalSrcAmount / numSlices)
   - Buy TWAP: route.origin.output.amount = floor(totalDestAmount / numSlices)
3. POST /v2/delta/orders/build
   - pass the returned route verbatim
   - set orderType=TWAPOrder for sell schedules, or orderType=TWAPBuyOrder for buy schedules
   - include interval and numSlices
   - include totalSrcAmount for TWAPOrder
   - include totalDestAmount and maxSrcAmount for TWAPBuyOrder
   - set deadline at least numSlices * interval seconds in the future
4. Ask the user to sign the returned toSign EIP-712 payload
5. POST /v2/delta/orders with order=toSign.value, signature, chainId, and partner
6. Track with GET /v2/delta/orders/{orderId}, GET /v2/delta/orders/hash/{hash}, or GET /v2/delta/orders
Agent rules:
  • Do not model TWAP as a loop of unrelated swaps; it is one scheduled Delta order.
  • Sell TWAP: preserve the total source amount to sell and split source amount across slices.
  • Buy TWAP: preserve the total destination amount to receive and split destination target across slices while capping source spend.
  • Preserve slice count, cadence/interval, deadline/expiry, token pair, chain, recipient, slippage or price constraints, and partially-fillable behavior.
  • If any schedule field changes, rebuild the TWAP order and ask the user to sign again.

​
Failure handling

FailureAgent action
Missing required fieldAsk the user for the missing field.
No routeAsk for a different amount, token, chain, or execution mode.
Quote expiredRequote and rebuild.
HMAC or quote validation errorRequote and keep the new response object paired with its new validation data.
User rejects signature or transactionStop. Do not retry automatically.
Transaction revertsSurface the revert and suggest requoting.
Delta order remains pendingPoll with backoff and show the latest order status.
Limit order or TWAP expiresSurface the expiry. Do not recreate automatically.

​
Guardrails

  • Never invent token addresses, chain IDs, quotes, transaction hashes, or order IDs.
  • Do not mutate top-level delta or market response objects.
  • Do not treat limit orders as AugustusRFQ.
  • Do not treat TWAP as unrelated swaps.
  • Do not retry rejected signatures automatically.
  • Ask before changing chain, recipient, order type, execution mode, amount direction, target price, schedule, or expiry.

Decision tables

Route user intent and API responses to the next action.

Delta quote

Quote Delta, Market, or auto-routed paths.

Market transaction

Build calldata from a Market response.

Troubleshooting

Per-endpoint failure modes: symptom, root cause, fix.
Last modified on June 14, 2026