feat(ethena): run Ethena + LlamaRisk backing checks independently#320
Merged
Conversation
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
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Enables the previously-dormant LlamaRisk backing check as a second, fully independent USDe backing check, running alongside the Ethena transparency API check.
[Ethena API]or[LlamaRisk]. No more ambiguity about which feed fired.(collateral + reserve fund) / supply, alerting CRITICAL if< 1and HIGH if< 1.005.Motivation
We received:
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
/solvency/reserve-fundendpoint, which matches LlamaRisk's figure exactly — no cross-provider dependency).totalSupply()cross-validation.main()runs both checks, each wrapped so one crashing can't stop the other.Bug fixes in the LlamaRisk path
supplyvs itself → always0).totalSupply()double-divide by 1e18 in the log line.get_tokens_supply()returningNone.get_tokens_supply()now returns(None, None)on contract-init failure instead of bareNone(which broke tuple unpacking).Testing
ruff format/ruff checkclean;tests/test_monitoring_config.pypasses (9/9).Docs
protocols/ethena/README.mdandmonitoring.yamlto document the two independent, labelled checks.🤖 Generated with Claude Code