Forex (Blend V2 pool)
oracle not gradableStenion publishes no safety score for Forex (Blend V2 pool) — not a low one, not a zero.
A Blend V2 market priced through a proxy oracle that forwards to a SEP-40 feed, and neither contract publishes a staleness tolerance or a deviation bound.
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 Forex (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 same pool wasm (a41fc53d…) Stenion already scores. Its oracle (CDCFT5QD…) exports five functions — decimals, lastprice, set_config, set_proxy, upgrade — and is a proxy: its CONFIG names a base_oracle at CB5OTV4G…, which is a full SEP-40 feed publishing base, assets, decimals, resolution, price, prices and lastprice.
Neither contract publishes what METHODOLOGY.md §2 grades against. The proxy exposes no max_age(), oracles() or asset_configs(); the feed one hop upstream exposes resolution() = 300 and no max_age either. That is not an oversight in either contract — SEP-40 simply does not define a maximum acceptable price age or a deviation bound, and leaves staleness checking to the consumer. Anchoring to the upstream would also anchor to a contract this pool does not itself publish or constrain, which would be a rule about somebody else’s configuration.
Reading its state on the same day gave a further reason not to force a number: three of its four reserves could not be priced at all. lastprice returned Error(Contract, #2) for CDIKUR…, CBN3NC… and CBCO65…, leaving XLM as the only priced reserve at $504.17, against 5,628 units of the unpriced CDIKUR… carrying live borrows. A market where most reserves have no readable price is one where every priced factor is computed from a fraction of the market.
The pool also read status 5 (Frozen) — borrowing and supplying disabled, withdrawals and repayments still available. Reported for completeness; it is a live operational state rather than a score, and it is not why this entry exists.
Verify this yourself
Take `oracle` from the pool’s Config in instance storage to resolve CDCFT5QD…, then read that contract’s own instance storage: its CONFIG record names base_oracle CB5OTV4G…. List the exports of both via getContractMethods — neither has max_age, oracles or asset_configs; the upstream answers resolution() with 300. Then simulate lastprice(Asset::Stellar(addr)) on the proxy for each address returned by the pool’s get_reserve_list and observe which return Error(Contract, #2).
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 Forex (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.