Etherfuse

stellar·adapter BlendAdapterBlend V2 poolDeposits & borrowing disabled

liveScored 2026-10-09 07:30 UTC

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

Etherfuse 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.

Etherfuse: deposits & borrowing disabled

pool status 4 (Admin Frozen) — borrowing and supplying are disabled; withdrawals and repayments still work.

Operations currently refused: supply, borrow. Read from PoolConfig.status = 4 at 2026-10-09T07:30:19.000Z.

Only an admin could have set this state. 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

0% stale(0 of 50 observed runs)

Oracle prices remained fresh across all evaluated historical runs.

Verify this yourself

CDMAVJPF…QS5FPVAI Website Docs

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%94

2 of 5 reserves tied at the worst score — 319s old (fresh<300s, dead>600s); all reserves have a deviation bound

Price freshness94
2 of 5 reserves tied at the worst score — 319s old (fresh<300s, dead>600s); anchored to the aggregator's own resolution and max_age (600s)
Deviation bound100
all 5 reserves score the same — CAS3J7… bounded at 10% per 300s step; CCW67T… bounded at 5% per 300s step; CAL6ER… bounded at 5% per 300s step; CBLV4A… bounded at 5% per 300s step; CD6M4R… bounded at 5% per 300s step

Price age by feed (not scored)not scored
Other:XLM 319s, Other:USDC 319s, Stellar:CAL6ER… 19s, Stellar:CBLV4A… 19s, Stellar:CD6M4R… 19s — all 5 within the protocol's own 600s staleness limit. Reported, not graded: priceFreshness already scores the worst of these.
Bound tightness (not scored)not scored
per-reserve max_dev: CAS3J7… 10%, CCW67T… 5%, CAL6ER… 5%, CBLV4A… 5%, CD6M4R… 5%. Measured against the previous upstream record, so this bounds movement per publish interval. Reported, not graded — see METHODOLOGY.md §2.

Collateralweight 20%82

top reserve holds 46% of supplied value across 5 reserves (HHI 0.34)

Admin keyweight 20%10

single-key admin (1 signer(s), high-threshold 0), 200 op(s) in 30d

Liquidityweight 15%59

worst reserve (CAS3J7…) has 59% of supply as free liquidity

Utilizationweight 20%42

worst reserve (CAS3J7…) at 41% util vs 70% 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.

ExportCSV JSON

59Elevated 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.