Skip to main content
Stenion
Registry
Coverage note · not a score

Spectra PTs (Blend V2 pool)

oracle not gradable

Stenion publishes no safety score for Spectra PTs (Blend V2 pool) — not a low one, not a zero.

A Blend V2 market priced by a deterministic bond model rather than a feed, so its price can never be stale and a freshness score would be meaningless.

Oracle publishes nothing to grade price trust against

These markets can be read, and four of the five factors compute normally for them. What their price feeds do not publish is a staleness tolerance or a deviation bound — the two on-chain parameters oracleSafety is anchored to, neither of which SEP-40 defines. Scored anyway, the nearest substitute rates a price that is hours old as perfectly fresh, and dropping the factor instead would rank a market higher for having an oracle we cannot inspect. Not a judgment about these protocols or their oracles: it says only that this particular number has nothing to be computed from.

Why Spectra PTs (Blend V2 pool) isn’t scored

What we found, stated as what is verified and what is inferred. None of this is a risk finding, and none of it feeds a number.

A Blend V2 market on the familiar pool wasm (a41fc53d…), with a single reserve: a Spectra principal token. Its oracle (CC4VF5DW…) is not a price feed. Its own get_description returns “Spectra Deterministic Oracle - Zero Coupon Bond Model”, and its stored state is a start time, a maturity, an implied APY and a target value at maturity — from which it computes a price at whatever the current ledger time happens to be.

That makes freshness meaningless rather than merely unanchored, and this is the distinction that decided the entry. There is no publish event, so a price is never old: the timestamp it returns is the ledger clock, the measured age is always about zero, and any freshness formula would return the top of the scale permanently, whatever happened to the underlying token. A score that cannot move is not a measurement. The contract is also explicit that its lastprice ignores the asset it is asked about — its own documentation says the parameter “is ignored… It exists solely for interface compatibility” — so it is bound to one token by construction.

It publishes no max_age(), oracles() or asset_configs(), and no deviation bound of any kind. The one lever that can move its output is set_future_pt_value, callable by its owner. That is an admin control rather than an oracle deviation bound, and the taxonomy has no way to grade it as either.

None of this is a criticism of the design. Pricing a principal token by accretion toward maturity is a coherent and common approach, and it is arguably more predictable than a feed. It is simply not something a factor built to measure price staleness and single-step deviation can grade. Recorded separately: this market held $9.88 in total supplied value and read status 2 (Admin On-Ice) on the same day — either would be worth noting on its own, but the oracle is the reason it is here.

Verify this yourself

Resolve the oracle from the pool’s Config (CC4VF5DW…) and call get_description, get_maturity, get_start_time, get_initial_implied_apy and get_future_pt_value on it — they return the bond parameters, and its instance storage holds the same values under apy, maturity, start_t and future_pt. List its exports with getContractMethods: nineteen functions, none of them max_age, oracles or asset_configs, and the doc comment on lastprice states that its asset argument is ignored. Simulate lastprice twice a few minutes apart and compare the returned timestamps against the ledger close time.

CDZVHCO7…UREBUMUY

Figures above read on . Balances change; re-read them rather than relying on this date.

This page is a coverage decision, not an assessment of the protocol’s safety, and nothing on it feeds any score. If Spectra PTs (Blend V2 pool) becomes scorable, this page goes away in the same change that registers it — it is replaced by a real entry in the registry, with a number derived from its own contracts.

Protocol names, logos and trademarks belong to their respective owners and are shown for identification only. Their presence here and any link to a protocol's own site or documentation does not imply endorsement, partnership, or any relationship with Stenion, in either direction.