Token buyback execution audit

It is the USD value of tokens that the protocol's destination buyback wallet actually received over a rolling window, divided by the USD value the protocol's published promise implies given the protocol's own fee revenue over the same window. A ratio of 1.0 means the program delivered exactly what the promise scaled to. Above 1.0 means the program executed more than the promise (rare, usually a window-edge effect or a one-off top-up). Below 1.0 means either the program is batched and the executed side is mid-cycle, or the executor address fell behind, or the documented share overstates what the program actually pays out. The benchmark reports the ratio at 7d and 30d so readers can distinguish 'mid-batch' from 'under-delivering'.

Cadence, not generosity. Hyperliquid's Assistance Fund executes HYPE buys on HyperCore as the protocol's fee stream accrues, so the executed line is roughly continuous and a 7-day window reads close to the long-run delivery. Sky's Smart Burn Engine pulls surplus DAI from the Maker / Sky protocol and market-buys SKY through Uniswap on a batched schedule, the SBE can sit for days accumulating surplus and then concentrate the on-market buys into shorter windows, so a 7-day snapshot taken mid-accumulation shows a low ratio. The 30-day window damps the effect but does not eliminate it because the batch frequency is irregular. Long-run delivery against the 100% surplus promise tracks closer to 1.0, the rolling ratio is a cadence signal, not a delivery verdict.

GMX V2 does not run a single on-chain buyback wallet whose inflows can be audited the way Hyperliquid's Assistance Fund or Sky's SBE can. V2 fees flow to GLP / GM pool LPs (paid out in ETH and stables) and to GMX stakers via the esGMX reward distributor system. There is no executor address that aggregates 'bought back GMX' on a measurable cadence. The original GMX treasury at `0x68863dDE…dea6A` has been dormant since August 2022 (verified via Etherscan v2). Reporting a ratio for GMX with this methodology would either be zero by construction or require imputing the buyback equivalent from staker-side distributions, which is a different benchmark. v2 of this bench will add Jupiter Litterbox Trust (50% of Jupiter fees → JUP buyback on Solana) and Aave's AFC once the executor addresses are confirmed.

The executed-side measurement is exact at the chain level, the SBE address holds the SKY Etherscan reports, the AF address holds the HYPE the Hyperliquid `info` API reports. Three noise sources sit on top. (1) Pricing, executed is USD-valued at scrape time, not at fill time, so a token that pumped between fill and scrape over-prices the executed side; drift is typically < 1% over a 5-minute window. (2) Promised, DeFiLlama's fees series occasionally revises historical days, and the harness recomputes the full window each scrape, so the ratio can move on prior-day revisions independent of fresh execution. (3) Pagination, the Etherscan v2 query for Sky paginates through transfers and any missing page would understate executed; `ocb_buyback_scrape_errors_total` surfaces failures.

Hyperliquid's 97% comes from the protocol's published fee allocation: 97% of HyperCore fees route to the Assistance Fund for HYPE buybacks, with the remainder funding HLP and other on-chain mechanisms. Sky's 100% reflects the Smart Burn Engine's design, the SBE is supposed to consume the entire Maker / Sky protocol surplus stream and convert it into on-market SKY purchases via Uniswap. Both numbers are the protocols' own published commitments; if either changes the harness config updates the share constant and the ratio rebases automatically against the new promise. The benchmark does not opine on whether 97% vs 100% is the 'right' share for a buyback program, it only measures whether the share that was promised showed up.

A burn chart shows what the destination wallet did with the tokens it received. This bench shows whether the destination wallet received what the protocol promised it would. Those are different questions and answer different concerns. A burn chart with healthy burns tells you the supply mechanic is working; a low execution ratio with healthy burns can still mean the protocol's promise is being under-funded relative to fees, just that the small amount that does arrive gets cleanly burned. The reverse is also true, a high execution ratio with no burns means the destination wallet is accumulating, which can be by design (the SBE holds SKY before burning in batches) or a warning sign (a treasury that promises buyback but never actually retires supply). The two numbers complement each other; OCB tracks the upstream one because it is the harder one to fake.

Every 5 minutes per protocol. The numbers are gauges over rolling 7-day and 30-day windows, so sub-5-minute resolution would not surface anything new, both the DeFiLlama promised side and the destination-wallet executed side are bounded by minutes-to-hours upstream cadences. The full window is recomputed on each scrape rather than carrying a running delta, so the ratio reacts immediately to DeFiLlama historical revisions or to a freshly indexed Etherscan transfer without needing a backfill pass.