DelvoAssertExecutor

Revert unless it holds.

You write the outcome you accept: at least this much out, at most this much in, no allowance left behind, before this time. The executor runs the route and checks your balances at the end. If any check fails, the whole transaction reverts and nothing moves; you pay only gas.

DelvoAssertExecutor is new and has had no independent security review. It moves tokens inside one transaction and holds nothing after it, but it should be reviewed before real volumes. Start with small amounts.

Statusnot deployed

Not deployed on Elysium yet. Until it is, a route preview creates a copy of the executor inside the simulation (at ), so you can see exactly what it would do on today’s pools. Sending stays off.

Deploy gas measured in the Foundry gas report: 2,427,511 (executor and its runner together).

Preview a checked swap
The checks you can write

MinGainYour balance of the output token rose by at least this much, measured on your address (so a token with a transfer fee is measured by what really arrived).

MaxSpendYour balance of the input token fell by at most this much. For HYPE, the value you send counts as spent.

MaxAllowanceAt the end, the allowance you gave a spender is at most this. Delvo's swaps approve exactly the amount and require 0 left.

DeadlineThe plan expires at a unix time you choose. Elysium reports the parent chain's number as block.number, so only the timestamp is used.

How it is built
  1. Users approve only the executor. It makes no arbitrary calls: it pulls from msg.sender only and hands the tokens to its runner.
  2. The runner makes the calls of the plan. Nobody approves the runner, so a plan cannot reach someone else's approval through it.
  3. Raw approve / increaseAllowance / setApprovalForAll / permit / Permit2 approve steps are refused. A step approves through approveToken: exact amount before the call, reset to 0 after, and the executor checks it is 0.
  4. Every input must arrive in full. Fee-on-transfer and rebasing inputs are refused (InputNotReceived).
  5. At the end the runner and the executor must hold exactly what they held before, token by token and in HYPE (BalanceLeftBehind).
  6. One plan at a time: a token or a router that calls back into the executor is refused (Reentrancy).
  7. No owner, no admin, no fee, no pause, no upgrade. A bug cannot be patched in place: a new executor would be deployed.
What a revert means

ExpiredThe plan's deadline has passed. Build it again.

BadPlanThe plan is malformed (steps, checks or pulls out of bounds).

ReentrancyA call tried to re-enter the executor during the plan. Refused.

InputNotReceivedLess of the input token arrived than was pulled (a transfer fee or a rebasing token). Refused.

GainTooLowYou would receive less than your minimum. The whole transaction reverts; nothing moves.

SpendTooHighYou would spend more than your maximum. The whole transaction reverts; nothing moves.

AllowanceTooHighAn allowance would be left behind above your limit. The whole transaction reverts.

RunnerAllowanceLeftThe runner kept an approval to a contract. Refused.

BalanceLeftBehindThe executor or runner would keep a balance. Refused.

TokenCallFailedA token call failed or returned false.

OnlyExecutorOnly the executor may use its runner.

StepRefusedA step was refused (raw approvals, the executor itself, or a target without code).

StepFailedOne of the plan's calls reverted.

NativeRefusedNative HYPE was sent to the runner outside a plan.

NativeSendFailedYour address refused the native HYPE sent back to it.

Limits: the checks trust what a token reports in balanceOf and allowance; a token that lies can pass a check it should fail. The routers and pools a plan calls run their own code. Tests: unit, fuzz, invariant and hostile-token cases, plus fork tests on real Elysium pools (listed on /method).