Stablecoin Dashboard
An automated factory for structural risk reports on stablecoins: it reads each token's backing
on-chain at one pinned block, scores how far that backing can be verified, and stress-tests it
with a model of the token's own liquidation mechanism. The thesis is that judgment belongs at
design time: an analyst rules once per archetype and once per token, and code enforces those
rulings on every run. Numbers never originate from a model: every figure comes from the data
table, through one formatter. The rulings, the gates and the record of decisions are the
artifact; the reports are samples of what it produces.
Site: https://amohazab.github.io/stablecoin_dashboard/
| token | last published block | prose written by | open notices on the page |
|---|
| LUSD | 26060799 | the local model, under the figure guard | none |
| crvUSD | 25974925 | API models, September evaluation runs | 3 kinds: gate failure, harness error, judge instability |
| GHO | 25974932 | API models, September evaluation runs | 4 kinds: freeze coverage below target, off-venue share 92.4%, gate failure, harness error |
How it runs
Windows Task Scheduler on the author's laptop runs everything unattended. Weekly, it
refreshes the behavioral tier (peg, liquidity and holder data fetched from Webacy) and
rebuilds the site. Monthly, it runs the full chain for one token per night: on-chain reads,
the verifiability tree, the stress model, the report. Each run commits its record and pushes,
and a push that changes the site deploys it to GitHub Pages. A run that fails still commits
its evidence. The click-through is in docs/scheduler.md.
What is checked
96 registered rubric checks run in four stages: S0 config integrity (3), S1 adapter output
before analysis (23), S2 verifiability and stress output (41), and S3 the rendered report (29).
Every trigger declares a severity:
- Level 1 publishes with a visible notice;
- Level 2 withholds the token's report;
- Level 3 halts the pipeline for that token.
Every firing goes into a public log. Some things the checks and the loop actually caught:
- crvUSD's page printed "$6 of bad debt" beside "structurally zero" (two template sentences). No
prose revision could reach it, so the fix went to the template. crvUSD's page still shows it
until a crvUSD run publishes.
- The generation guard rejects any figure the data table does not print: for example "$260" and
"0.00%" in GHO drafts, and "7 days" in a crvUSD draft, each refused before it reached a page.
- A blocked run keeps the last good page. crvUSD and GHO were blocked in each attempt from
25 to 26 September; their pages did not change, and each attempt is in the log.
Known limitations
- The LLM judge is withdrawn in the local configuration. A 9B local model failed a control run
(it missed a planted wrong figure and flagged correct ones), so its six prose criteria are
recorded as not evaluated. The deterministic checks still run on every page.
- LUSD's summaries are written by the local 9B model under the guard, with no second reviewer.
- crvUSD's and GHO's summaries come from the September API-model runs: the local model's drafts
for those two tokens do not pass the guard.
- One archetype so far: collateralised debt positions (CDP).
Reproduce a page
Python 3.12 with uv. Keys come from the environment or from .env at the repo root, by name:
ETH_RPC_URL (an archive node), ETHERSCAN_API_KEY, and WEBACY_API_KEY (behavioral tier).
uv run python -m factory.run <TOKEN> # pinned reads, S0/S1 gates, the bundle
uv run python -m factory.tree <TOKEN> # the verifiability tree (no RPC)
uv run python -m factory.stress <TOKEN> # the stress cells (reads at the bundle's block)
uv run python -m factory.report <TOKEN> # table, pages, report-stage gates
uv run python -m factory.site # the selector and methodology pages
<TOKEN> is crvUSD, GHO or LUSD. factory.report <TOKEN> --llm writes the prose with a
local Ollama server running qwen3.5:9b. Without --llm the run is a
rehearsal, and its pages stay in out/rehearsal/. Tests: uv run python -m pytest; lint:
ruff check src tests.
Where the rulings live
docs/context/: the design record, read in order. The brief sets the project; the CDP
archetype memo makes the class-level rulings; the intake sheets instantiate them per token;
the evaluator rubric (rubic_v1.md, filename as-is) owns every check and trigger.PROGRESS.md: one entry per confirmed decision, in order. Start at the Step 7 and Step 8
status lines near the top. The AS-COUNTED lines record errors on both sides, the builder's
and the design layer's.
What is next
USDe, as the second archetype (a synthetic, delta-hedged dollar), with its report reconciled
against a manual benchmark. Then more tokens, chosen by archetype coverage.
License
MIT; see LICENSE.
