Independent look at ENS Endowment execution quality (CoW Protocol, rolling 90d

Hi all — out of interest in the Endowment’s execution (and because everything needed is public on-chain), I built an independent dashboard measuring the execution quality of the Endowment’s large trades over a rolling 90-day window:

On deep-market pairs, the Endowment’s volume-weighted execution cost is about half a basis point (+0.53 bps) versus the public mid at the minute of execution — across ~$39M in orders of $250k or more — with zero gas borne by the treasury and atomic settlement on every fill. By traditional TCA standards, that is a strong execution record.

:bar_chart: https://dune.com/mrdaniel9554/ens-dao-endowment-on-chain-execution-quality

Notes on how it’s built:

  • Every figure traces to a transaction hash, and every query behind the page is public and forkable.

  • Benchmarks are public minute-level mids, so orders in yield-accruing or thin tokens (sUSDS, ETHx, eETH) are shown in the log but flagged indicative rather than rolled into the headline. Where I spot-checked the largest sUSDS order against the on-chain redemption rate at its execution block, the fill was within ~2 bps of fair value — better than the market feed suggested.

  • The dashboard self-updates; nothing is cherry-picked to a window.

I’m unaffiliated with ENS, karpatkey, and Steakhouse — this is just careful use of public data. If anything looks off — methodology, attribution, a benchmark you’d have chosen differently — I’d genuinely like to know, and corrections will be applied and credited.

@kpk @Steakhouse

— Daniel

Mid at the minute of execution measures the fill, which is exactly what solver competition and atomic settlement are built to win, so +0.53 bps across 39M is a fair read on that part. What it leaves out is delay, the distance between the price when a rebalance was decided and the price when the order reached the book, and for a treasury rebalancing on a schedule rather than into a deadline that leg is usually the larger cost.

That’s a fair and welcome point — this is the implementation-shortfall decomposition

(decision → arrival → execution), and you’re right that the dashboard currently measures

only the execution leg. The +0.53 bps says the fills are excellent *once orders reach the

auction*; it says nothing about what the wait cost.

Part of the delay leg is measurable from public data: CoW’s orderbook API records each

order’s creation time, so placement → fill drift can be benchmarked the same way as the

fill itself (for example, the $13.5M DAI→USDC order on Jul 15 was created at 18:22:46 UTC

and filled at 18:25:23 — about 2.6 minutes of market exposure). I’ll add that as a panel in

the next update and credit this thread for the correction.

The decision → placement leg is the honest limit of public data: it needs the decision

timestamp, which only the manager has. For anyone in the thread who benchmarks that leg

internally — I’d be curious what reference you use: decision-time mid, previous close, or

something schedule-aware.