Solv (Blend V2 pool)

A Blend V2 market on the same pool wasm (a41fc53d…). Its oracle (CBMGLKUQ…) is the closest of the four to a standard feed — a SEP-40 registry exporting base, assets, decimals, resolution, price, prices and lastprice alongside owner-only add_feed, update_feed and remove_feed. It is the only one of the four that implements SEP-40 at all.

It still publishes neither of the parameters METHODOLOGY.md §2 needs: no max_age(), no oracles(), no asset_configs(), and no deviation bound anywhere in its interface. That is a property of SEP-40 rather than of this contract — the standard defines no maximum acceptable price age and no deviation bound, and explicitly leaves staleness checking to whoever reads the price.

The one field that looks like an anchor is resolution(), and using it would produce a worse outcome than declining to score. resolution() is a publish interval, not a staleness tolerance, and this oracle reports 43200 — twelve hours. Fed into Stenion’s freshness window with no max_age to pair it with, a twelve-hour tick yields a twenty-four-hour dead line, so every price younger than a day scores the top of the scale. Its own feeds demonstrate the problem: two were live to the second when read, while USDC was 10,285 seconds old and one further feed 21,739 seconds old. All four would have published a freshness of 100. That is the fabricated confidence the rule against invented numbers exists to prevent, so the anchor is refused rather than used.

The contract is unusually candid about this, which is worth recording rather than paraphrasing: its own documentation flags two deliberate departures from SEP-40 — that decimals is not immutable, and that resolution “should never change after deployment” but here can, through an owner-callable set_resolution. A value the owner can move is not an anchor even in principle. Separately, the market held $175.69 in total supplied value when read.