Orbit (Blend V2 pool)
oracle not gradableStenion publishes no safety score for Orbit (Blend V2 pool) — not a low one, not a zero.
A Blend V2 market whose oracle is a bridge contract publishing no staleness tolerance and no deviation bound — the two parameters oracleSafety is anchored to.
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 Orbit (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.
Orbit is a market on Blend V2, running the same pool contract (wasm a41fc53d…) that Stenion already scores twice. Everything on the pool side reads normally: four reserves, a multisig admin, and prices for every one of them. It is the oracle that stops it.
The pool’s oracle (CAD2MCFU…) is a bridge contract, not Blend’s oracle-aggregator. Its entire exported interface is five functions — __constructor, add_asset, decimals, lastprice, set_admin — read out of its own wasm rather than probed by guessing names. It publishes no max_age(), no oracles() and no asset_configs(), which are the three reads METHODOLOGY.md §2 grades price trust against. None of them is part of SEP-40, which defines no staleness tolerance and no deviation bound at all.
There is a second problem specific to this market, and it is the reason a fallback would be worse than no score. Its largest reserve (CBZPEX…) held $189,999.50 of the pool’s $190,862.93 total — 99.5% — and returns a price of exactly 1.0 stamped at the current ledger time, without touching any upstream contract. On Blend’s aggregator such base assets are excluded from oracleSafety rather than graded, because there is no oracle-derived price to grade; that exclusion is driven by the aggregator’s base() and BaseAssets, and this bridge publishes neither. So the reserve holding almost the entire market would be graded as a permanently-fresh feed. A confident 100 derived from a hardcoded constant is worse than no number, which is why this market is unscored rather than scored around.
Nothing here says Orbit is unsafe, and nothing says its oracle is a bad one — a bridge that maps assets onto upstream feeds is an ordinary design. What is reported is that the specific parameters this factor is anchored to are not published, so the number cannot be computed from the market’s own data. Note separately that the pool read status 4 (Admin Frozen) when we looked: borrowing and supplying were disabled, withdrawals and repayments were not. That is a live operational state, not a score, and it is not the reason this entry is here.
If the oracle later publishes a staleness tolerance and a per-asset deviation bound, this market becomes scorable with no rule change — a BLEND_POOLS entry and the deletion of this entry, in one PR.
Verify this yourself
Read the pool’s instance storage via Soroban RPC getLedgerEntries and take `oracle` from its Config — that resolves CAD2MCFU…. Fetch that contract’s wasm (getContractWasmByContractId) and list its exports from the contractspecv0 section, or call getContractMethods: five functions, none of them max_age, oracles or asset_configs. Then simulate lastprice(Asset::Stellar(CBZPEX…)) against it and compare the returned timestamp with the current ledger close time — they match, and the simulation footprint names no contract other than the oracle itself. Call get_reserve_list on the pool and total each reserve for the balances.
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 Orbit (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.