Skip to main content
Stenion
Registry

YieldBlox

stellar·adapter BlendAdapterBlend V2 poolBorrowing disabled

liveScored 2026-10-09 07:30 UTC

Last run 2026-10-09 07:30 UTC · updated on every indexer cycle

YieldBlox is a Blend V2 pool, not an independent protocol

It runs Blend’s contract code rather than its own, so Stenion scores it with the same adapter. It gets its own entry because everything the score is computed from — the reserves, the oracle configuration, the admin — belongs to this market and not to Blend, and those differ enough to produce a different number.

Being a Blend V2 pool is not itself a risk finding, and it is not scored. It is stated so this entry is not read as a third protocol where the chain has a second market.

YieldBlox: borrowing disabled

pool status 3 (On-Ice) — borrowing is disabled; supplying, withdrawing and repaying still work. Blend's backstop can impose this restriction on its own — when the pool's backstop deposits fall below the required threshold, or when a large share of them is queued for withdrawal — and it can also be set deliberately. Which happened here is not readable from the status alone.

Operations currently refused: borrow. Read from PoolConfig.status = 3 at .

The chain does not say whether an admin or the protocol’s own mechanism set this. Nothing here says whether that is good or bad, and it is not scored: a pause can mean an admin containing a threat or a market being abandoned, and no on-chain data tells the two apart. The score above reflects the same five factors it always does — read it alongside this, not through it.

Historical oracle staleness
100% stale(50 of 50 observed runs)

Oracle prices were stale in 50 of the last 50 runs (100% of time). Persistent staleness indicates feed refresh gaps or unaligned TTLs.

Verify this yourself

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.

Factor breakdown

Why the score is what it is — each factor on a 0–100 scale, higher is safer.

Oracleweight 25%0

2 of 5 reserves tied at the worst score — max_dev 0 — deviation check disabled

  • Price freshness97

    all 5 reserves score the same — 317s old (fresh<300s, dead>900s); anchored to the aggregator's own resolution and max_age (900s)

  • Deviation bound0

    2 of 5 reserves tied at the worst score — max_dev 0 — deviation check disabled

  • Price age by feed (not scored)not scored

    Stellar:CAS3J7… 317s, Stellar:CDTKPW… 317s, Stellar:CAUIKL… 317s, Stellar:CBLV4A… 317s, Stellar:CAL6ER… 317s — all 5 within the protocol's own 900s staleness limit. Reported, not graded: priceFreshness already scores the worst of these.

  • Bound tightness (not scored)not scored

    per-reserve max_dev: CAS3J7… 0%, CDTKPW… 10%, CAUIKL… 0%, CBLV4A… 10%, CAL6ER… 10%. 3 base asset(s) excluded — priced 1:1, not oracle-derived. Measured against the previous upstream record, so this bounds movement per publish interval. Reported, not graded — see METHODOLOGY.md §2.

Collateralweight 20%47

top reserve holds 73% of supplied value across 8 reserves (HHI 0.59)

Admin keyweight 20%60

admin is a contract (CANSYF…) — not introspectable via Horizon; neutral baseline

Liquidityweight 15%1

worst reserve (CCCRWH…) has 1% of supply as free liquidity

Utilizationweight 20%0

worst reserve (CCCRWH…) at 99% util vs 90% cap

Score history

Every indexer run, on a fixed 0–100 axis and a real time axis. The line breaks wherever the score is unknown — a failed run, an indexing gap, or a methodology change — rather than drawing through it.

ExportCSVJSON
034671008 Oct 21:009 Oct 00:0003:0006:00
22High risk
9 Oct 07:30 UTC · methodology v1
safety score
Showing 50 runs · 8 Oct 19:15 → 9 Oct 07:30 UTC · 12h 15m · typically every 15m

Recent runs

The last 50 scoring runs, newest first. Open a scored run to see the factor breakdown it produced.