Skip to content

feat(ethena): run Ethena + LlamaRisk backing checks independently#320

Merged
spalen0 merged 3 commits into
mainfrom
ethena-dual-provider-backing-check
Jul 21, 2026
Merged

feat(ethena): run Ethena + LlamaRisk backing checks independently#320
spalen0 merged 3 commits into
mainfrom
ethena-dual-provider-backing-check

Conversation

@spalen0

@spalen0 spalen0 commented Jul 21, 2026

Copy link
Copy Markdown
Collaborator

Summary

Enables the previously-dormant LlamaRisk backing check as a second, fully independent USDe backing check, running alongside the Ethena transparency API check.

  • Two independent checks — each provider is checked in isolation, so a failure or false positive in one source never suppresses the other.
  • Provider-labelled alerts — every message is prefixed with the source that triggered it: [Ethena API] or [LlamaRisk]. No more ambiguity about which feed fired.
  • Both checks compute (collateral + reserve fund) / supply, alerting CRITICAL if < 1 and HIGH if < 1.005.

Motivation

We received:

🔴 🚨 USDe NOT FULLY BACKED!
Backing Assets: $4,029,208,667.82
Total Supply: 4,031,893,924.09
Backing Ratio: 0.9993 (-0.07%)

This was a false positive: the active check used collateral-only, which hovers right around 1.0 and dips fractionally below it in normal operation. USDe holds its buffer in a separate reserve fund (~$62M) the check ignored. Including it → ratio 1.0154, comfortably backed. LlamaRisk independently reported 1.0424 at the same moment.

Changes

  • Ethena check now includes the reserve fund (from Ethena's own /solvency/reserve-fund endpoint, which matches LlamaRisk's figure exactly — no cross-provider dependency).
  • LlamaRisk check re-enabled as an independent second opinion with the same ratio/thresholds, plus its on-chain totalSupply() cross-validation.
  • New main() runs both checks, each wrapped so one crashing can't stop the other.

Bug fixes in the LlamaRisk path

  • Removed the dead self-comparison (supply vs itself → always 0).
  • Fixed the on-chain totalSupply() double-divide by 1e18 in the log line.
  • Guarded against get_tokens_supply() returning None.
  • get_tokens_supply() now returns (None, None) on contract-init failure instead of bare None (which broke tuple unpacking).

Testing

  • Live dry-run of both checks with Telegram stubbed: both run independently, log their provider, no false alerts (Ethena ratio 1.0154, LlamaRisk 1.0424).
  • Forced sub-1.0 ratios to confirm each provider produces a correctly-labelled CRITICAL alert.
  • ruff format / ruff check clean; tests/test_monitoring_config.py passes (9/9).

Docs

  • Updated protocols/ethena/README.md and monitoring.yaml to document the two independent, labelled checks.

🤖 Generated with Claude Code

spalen0 and others added 2 commits July 21, 2026 11:07
Enable the previously-dormant LlamaRisk backing check as a second,
fully independent USDe backing check alongside the Ethena transparency
API check. Each provider is checked in isolation so a failure or false
positive in one source never suppresses the other, and every alert is
prefixed with the provider that triggered it ([Ethena API] / [LlamaRisk]).

Both checks now compute (collateral + reserve fund) / supply and alert
CRITICAL if < 1, HIGH if < 1.005. Previously the active Ethena check used
collateral-only, which false-positived CRITICAL on fractional dips below
1.0 that the separate reserve fund comfortably covers.

Also fixes bugs in the LlamaRisk path:
- removed the dead self-comparison (supply vs itself, always 0)
- fixed the on-chain totalSupply() double-divide by 1e18 in logging
- guarded against get_tokens_supply() returning None
- get_tokens_supply() now returns (None, None) on contract-init failure
  instead of bare None (which broke tuple unpacking)

Reserve fund is sourced from Ethena's own /solvency/reserve-fund endpoint
(matches LlamaRisk's figure exactly), so no cross-provider dependency.

Updated README and monitoring.yaml to document the two independent checks.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The on-chain supply-consistency gate compared LlamaRisk's Z-suffixed
(UTC) timestamp — parsed as a naive datetime — against datetime.now(),
which is naive *local* time. On a non-UTC host (e.g. Europe/Zagreb during
DST, UTC+2) fresh chain data computed as >2h old, so the check returned
early and the on-chain validation silently never ran.

Route through the existing is_stale_timestamp() helper, which compares
against naive UTC now and already treats unparsable timestamps as stale.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@spalen0
spalen0 marked this pull request as ready for review July 21, 2026 09:18
…hecks

The Ethena check queries /positions/current/collateral?latest=true, whose
totalBackingAssetsInUsd is a NET backing figure tracking supply ~1:1. The
LlamaRisk check (and the same Ethena endpoint without latest=true) report
GROSS collateral, ~2.7% higher. They agree asset-by-asset to ~0.04%, so the
~2.7% ratio gap between the two checks is definitional, not staleness or a
backing problem.

The two checks are therefore two independent lower-bounds on backing,
intentionally NOT reconciled against each other (a direct collateral
comparison would fire on every run). Documented in the function docstring
and README so this isn't re-derived later. No behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@spalen0
spalen0 merged commit 6d786b2 into main Jul 21, 2026
3 checks passed
@spalen0
spalen0 deleted the ethena-dual-provider-backing-check branch July 21, 2026 09:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant