DEV Community: Elliot

Counting Cardano builder activity: weekly commits and 30-day releases across 15 core repos from the GitHub API

Elliot — Wed, 21 Oct 2026 00:12:18 +0000

At The Cardano Record most of what we publish comes from our own cardano-db-sync node. This segment is the exception. You can't read builder activity from the chain, so it comes from GitHub, and no db-sync table is involved.

The question it answers is narrow. How many commits landed on the default branch of a fixed set of core Cardano repos last week? How does that compare with their recent weeks? And how many releases did those repos publish in the last 30 days?

What is measured

We take two readings per repo:

Commits per week on the default branch, from GitHub's /stats/commit_activity endpoint. One call per repo returns the last 52 weeks, with one commit count per week.
Releases published in the last 30 days, from the /releases endpoint.

From those we derive four figures per repo:

last week's commits
the average of the 12 weeks before last week
the 52-week total
the percent change of last week against that 12-week average

The same figures are also computed across all repos combined. The baseline is the 12 previous weeks, so the week being judged is not part of its own average.

The repo list is fixed, and it is a sample

The list doesn't change from run to run, and it is shown on screen whenever the segment airs. It covers the core stack:

node, ledger, consensus and networking
Plutus, the CLI and the API
db-sync and GovTool
Aiken, Hydra, Mithril and Dolos
the wallet backend and the Mesh SDK

That makes 15 repos. It isn't "all of Cardano", and the segment is not allowed to call it that. Most of the ecosystem's dapps, wallets and libraries are outside the list. Because the list is fixed, this week's total and last quarter's total always count the same repos.

Fetching: unauthenticated on purpose

The fetcher reads no credential. GitHub allows a small number of unauthenticated calls per hour, and one refresh fits inside that allowance. A refresh makes one commit-activity call per repo, at most one retry per repo, and one releases call per repo. Cron runs it once a day.

python3 sources/builders.py --refresh      fetch from GitHub, write CACHE
python3 sources/builders.py                print the cached block

The commit-activity endpoint has one quirk to plan for. If GitHub hasn't computed a repo's statistics yet, it doesn't return them. It replies that it is still computing, and the fetcher has to ask again. That is what the retry budget is for.

The refresh writes a cache, and the episode reads the cache. So the GitHub data is always a little older than the episode snapshot, and we report by how much.

How it is checked

Coverage. The block records how many repos answered next to how many are listed, plus a missing field that names any repo that failed. In this run 15 of 15 answered and missing was empty. A total over 14 repos should never be presented as a total over 15.
The totals add up. We added the per-repo figures while writing this. Last week's commits sum to 391, which matches the reported total. Releases split as 3 (Plutus) + 3 (Cardano CLI) + 1 (Node) + 1 (Aiken) + 1 (Wallet backend), which is 9 across 5 repos, also matching.
Freshness. The data was fetched at 2026-10-18 10:21:04 UTC. The snapshot it fed was taken at 2026-10-19 07:30:01 UTC, so the data was 21.2 hours old when used. The week being measured starts 2026-10-11.
No second source today. Our rules ask for a cross-check against an independent source where one exists, and for us to say so when one isn't done. Here it isn't done. We read GitHub's own statistics and don't recount commits from the git history ourselves.

Traps

A commit is not progress. One large feature can be one commit, and a typo fix is another. The segment says "commits" and never "progress" or "development speed". Comparing repos by commit count mostly tells you how each team commits.

Default branch only. Work on feature branches isn't counted until it is merged. Four repos had zero commits on their default branch last week: Networking, db-sync, Aiken and the Wallet backend. Two of those four still published a release in the last 30 days: Aiken v1.1.24 and Wallet backend v2026-10-07. A zero week on the default branch is a fact about the default branch, nothing more.

Small baselines make large percentages. The Mesh SDK had 6 commits last week against an average of 2.4. That is 150% above average (our calculation) and only a few commits in absolute terms. db-sync's baseline is 1.2 a week. We show the raw counts next to any percentage so its size can be read.

One week is noisy. Hydra had 5 commits last week against an average of 29.1, yet 1,509 over 52 weeks. Node had 4 against 19.3. The weekly figure says what happened last week. Read without the longer series beside it, it doesn't describe a trend.

Release names aren't comparable. The latest tags read 1.72.0.0, cardano-cli-11.4.0.0, 11.1.3, v1.1.24 and v2026-10-07. Each repo has its own scheme, some numbered and one dated. We count releases and list the latest tag, and we never compare version numbers across repos.

Results

Week starting 2026-10-11. Fetched 2026-10-18 10:21 UTC and used in the snapshot of 2026-10-19 07:30 UTC.

Repo	Last week	Avg previous 12 wks	Last 52 wks	Releases 30d	Latest release
Consensus	85	43.2	1,454	0	-
Plutus	63	44.9	2,524	3	1.72.0.0
Mithril	61	62.9	3,146	0	-
Cardano CLI	52	12.9	433	3	cardano-cli-11.4.0.0
Ledger	45	43.8	1,891	0	-
Dolos	35	16.2	556	0	-
GovTool	23	16.2	293	0	-
Cardano API	12	30.2	1,088	0	-
Mesh SDK	6	2.4	141	0	-
Hydra	5	29.1	1,509	0	-
Node	4	19.3	975	1	11.1.3
Networking	0	5.8	570	0	-
db-sync	0	1.2	194	0	-
Aiken	0	7.6	237	1	v1.1.24
Wallet backend	0	24.4	901	1	v2026-10-07
All 15	391	360.2	15,912	9 (5 repos)

Last week was 8.6% above the 12-week average across all 15 repos.

The archive of our episodes, each with its transcript and the figures it used: https://cardanorecord.com/episodes.html

Measuring Cardano stablecoin supply from db-sync: mint history for four coins, a reserve vault for DJED

Elliot — Wed, 21 Oct 2026 00:10:52 +0000

At The Cardano Record we publish one set of stablecoin numbers each week: how many of each coin are circulating, and how many were net issued over 7, 30 and 90 days. It sounds like one query. It turned out to need two, because Cardano's stablecoins don't all issue the same way. Use the wrong model and you get either a coin with a trillion in supply or a coin whose supply never changes.

Here a stablecoin means a token designed to track one US dollar. We track six tokens: iUSD, USDM, USDA, USDCx, DJED and SHEN. SHEN is Djed's reserve token and isn't pegged to the dollar, so it is measured but left out of the dollar total.

Model 1: supply is the mint history

For iUSD, USDM, USDA and USDCx, supply changes only when tokens are minted or burned. db-sync records every mint and burn in ma_tx_mint, and burns count against mints. So SUM(ma_tx_mint.quantity) for an asset, up to now, is its circulating supply. Net issuance over a window is the same sum limited to that window. Because each event is either a mint or a burn, it also splits into gross minted and gross burned.

This week's USDCx shows what that split adds. Over 7 days there were 114 mint events: 415,116.32 tokens minted and 1,937,318.05 burned, for a net of -1,522,201.73. The net figure alone would hide how much went in each direction.

Model 2: supply is what has left the vault

DJED and SHEN work differently. The protocol minted its entire cap of 1,000,000,000,000 tokens once, at launch, into a vault script. It issues coins by releasing them from that vault. Two things follow:

The token's reported total supply is the cap. Our editorial rules name exactly this failure: never report a minting cap as supply.
Mint history is no use either. There are no new mint events, so net issuance computed from ma_tx_mint would be zero forever, even while the coin is issued and redeemed every day.

So for these coins, circulating supply is minted all time minus what the vault still holds. In this run the vault held 999,998,550,991.03 DJED, which leaves 1,449,008.97 DJED circulating. By our calculation that is about 0.000145% of the headline figure. SHEN works out to 31,196,162.38 circulating.

Net issuance for these two is the change in vault holdings over the window. That means there is no gross minted and burned split. The pipeline doesn't write a zero in that field. It records the reason instead: "pre-minted issuer: mint history records no events, so issuance is only measurable as a change in vault holdings".

How it is checked

A pool scan for the four mint-model coins. A separate scan of liquidity pools also reports each coin's supply. This run, iUSD, USDM, USDA and USDCx all matched it with a 0.0% gap.
An exhaustive check on the vault subtraction. When the module was built, the cheap vault read was compared with a full anti-join over every DJED output ever created. That query adds up all unspent DJED across every live UTxO. It came to exactly the cap, and the vault was a single UTxO holding almost all of it. The two methods agreed to the lovelace. The weekly figure uses the cheap vault read.
The total, valued a second way. At reference prices the dollar total is $65,210,616.44. Valued at pool prices from the pool scan, the total differs by 0.271%.
DJED's price from two sources. The reference price was $1.004743. A separate Djed reserve monitor read $1.0021. The two differ by 0.432%. We keep both figures and don't average them.

Traps

Tokens and dollars are different units. Net issuance is counted in tokens. The aggregate is in dollars, valued at each coin's reference price. Those prices are not all $1: iUSD was at $0.984365. Dollar fields carry _usd in the name, and token counts never do.
A cap disguised as supply. Any token whose reported supply is above a floor of 100 billion gets its supply recorded as absent, not zero, and no supply ratio is computed from it. This run, no supply was suppressed, because DJED and SHEN supply now comes from the vault subtraction.
A thin pool's price is not a peg reading. If a pool price differs from the reference by more than 5%, it is marked unreliable and dropped. This run, USDCx's pool price was 37.0% off its reference. That reflects a thin or one-sided pool, not a depeg, so USDCx carries no pool price at all.
Not every stable token is a dollar. SHEN is listed in its own row with its reason for exclusion. It never enters the dollar total quietly.

What the dollars are doing

A second module asks what stablecoins are being moved for. It reads token outputs from ma_tx_out over 24 hours and sorts them into outputs to plain wallets and outputs to scripts. It publishes only shares of each token's own volume, for two reasons:

Decimals. A ratio of two quantities of the same asset doesn't depend on decimals, so it can't be thrown off by assuming the wrong number of decimal places.
Overcounting. Output volume isn't the same as net transfers. A single swap produces several outputs, and change returning to a pool is counted again. An absolute turnover figure from this data can't be defended, so we never publish one.

The gap between count and volume matters here. For USDCx, outputs to wallets outnumbered outputs to scripts, 2,856 to 2,602. By volume, though, only 2.9% went to wallets. Most transfers are small and go wallet to wallet, while most of the dollars sit in contracts. This feed is a file written by another job, so we check its age before using it. This run it was 232.3 minutes old and not flagged stale.

Results

Data as of 2026-10-13 17:30 UTC. Net issuance is in tokens. Supply in dollars uses reference prices. Wallet share covers the 24 hours computed at 08:42:55 UTC.

Coin	Circulating (tokens)	Net issued, 7d	Share of dollar supply	Wallet share of output volume
USDCx	44,758,043.71	-3.289%	68.63%	2.9%
USDM	13,561,872.76	-0.058%	20.75%	14.0%
USDA	4,133,624.64	-2.362%	6.33%	14.8%
DJED	1,449,008.97	-0.89%	2.23%	2.6%
iUSD	1,368,245.16	-4.872%	2.07%	5.8%
SHEN (not a dollar)	31,196,162.38	-0.087%	excluded	not tracked

Aggregate	Value
Dollar stablecoin supply	$65,210,616.44
Change, 7 days	-$1,711,680.87 (-2.558%)
Change, 30 days	+$3,513,544.66 (+5.695%)
Change, 90 days	+$8,464,163.46 (+14.916%)
Peak in series	$66,941,653.17 on 2026-10-01

The archive of our episodes, each with its transcript and the figures it used: https://cardanorecord.com/episodes.html

Measuring a Cardano perpetuals venue: volume, cross-venue price gaps, funding and maker markout on Strike Finance

Elliot — Tue, 13 Oct 2026 23:21:08 +0000

Most of what we publish at The Cardano Record comes from our own cardano-db-sync node. This segment doesn't. Strike Finance is Cardano's perpetuals venue, and the numbers that describe how well it works as a market (volume, spread, funding, how it prices against other exchanges) aren't something you can read cleanly out of ledger tables. So this post covers a different kind of pipeline: one that reads off-chain feeds, checks how fresh each one is, and decides when to stay quiet.

Some definitions first. A perpetual is a futures contract with no expiry. A funding rate is the periodic payment between longs and shorts that keeps the perpetual's price close to the underlying asset. A basis point (bps) is a hundredth of a percent.

Why funding alone wasn't enough

We already aired Strike's funding rates from a module called sources/perps.py. Its own docstring names the limitation: the feed carries the rate but no open interest or volume. It shows what a position costs, not how much money is behind it. A rate on a market nobody trades is noise.

So we added sources/strike_market.py, which brings in size and venue quality. Strike doesn't publish any of these as history:

24-hour traded volume per market, fetched live from Strike's public ticker.
Quoted bid/ask spread and maker markout, computed from a trade tape that another job on the same box saves every 30 minutes.
The gap between Strike's mark price and the same contract on OKX and Hyperliquid, from a monitor that runs every 20 minutes.

The sign convention, written next to the code

The funding monitor's convention was checked against its source rather than assumed: positive funding means longs pay shorts. That gives two cases:

funding > 0: shorts receive, longs pay, and the long side is crowded
funding < 0: longs receive, shorts pay, and the short side is crowded

If you get this backwards, every sentence in the segment inverts. The convention is written in the module's docstring next to the code that depends on it, and each market in the output carries both a receive_side and a crowded_side, so whoever reads the output doesn't have to re-derive it. A rate of exactly zero is recorded as flat, with neither side crowded. In this snapshot, 7 markets had longs receiving, 6 had shorts receiving, and 18 were flat.

Markout: does resting liquidity pay?

A quoted spread tells you what a maker could capture in principle. Markout is the more honest measure. For each filled resting order, it measures how far the price moved against that maker 1, 5 and 30 minutes later. If the price consistently moves against makers after they're filled, the spread is paying for losses rather than profit. We take the tape, find maker fills, and measure the price at each horizon.

We report the fill count and the hours the tape covers next to every markout. A markout from a few thousand fills over six weeks isn't the same strength of evidence as one from tens of thousands of fills over two weeks, and the reader should be able to see which one they're looking at.

Staleness is a hard gate

Every input here is a file written by another cron job, which means any of them can go cold without warning. The pipeline doesn't fetch these files itself, so it checks their age before using them:

The cross-venue file is dropped if it's older than 90 minutes.
The markout report is dropped if it's older than 36 hours.
The funding feed is dropped if it's older than three hours. The monitor runs hourly.

When something is dropped, the segment says which input is missing. It never quietly reuses an old figure. In this snapshot the cross-venue file was 11 minutes old, the markout report 22.2 hours, and the funding feed 2.5 minutes, so all three passed.

Traps

Two feeds, two clocks. The cross-venue file and the funding feed both report Strike's ADA funding, and they don't agree exactly: 42.74% against 42.97% annualised. That isn't a bug. They're sampled minutes apart. We publish each figure with its own source and age rather than averaging them or picking one silently. The market counts differ for the same reason: 29 markets in the ticker and 31 in the funding monitor.
Annualised doesn't mean earned. An annualised funding rate is the current rate scaled to a year. It describes the cost at this moment, and nobody should read it as a yield. Our editorial rules forbid quoting a yield without its capacity, and this feed has no capacity data at all.
No size in the funding feed. The only size-like filter is the monitor's notable flag, and we use it. Volume from the ticker partly fills the gap, but it's Strike's own number, and there's no second source to cross-check it against today.
Thin markets look dramatic. NIGHT-USD showed 189.54% annualised funding and a 135.2 bps spread. Its markout came from 3,828 fills over 1,050.8 hours. ADA-USD's came from 40,930 fills over 354.6 hours. The NIGHT figures are real measurements of a much thinner market.
A gap is a measurement, not a trade. The segment states what each venue measured. It never says a gap or a markout is an opportunity. Fees, latency and capacity all sit between a printed gap and anything you could act on, and we measure none of them.

Results

Data as of 2026-10-12 12:17 UTC. The share percentage is the pipeline's own. Dollar figures are rounded.

Measure	Value
Strike markets (ticker)	29
24h volume, all markets	$4,477,948
24h volume, BTC-USD	$1,576,202
24h volume, ADA-USD	$289,123 (6.46%)
ADA funding, Strike vs OKX (annualised)	42.74% vs 10.95%
ADA gap vs OKX / Hyperliquid	7.18 bps / 1.2 bps
Median absolute gap vs OKX	5.96 bps
ADA maker spread	4.02 bps
ADA markout 1m / 5m / 30m	0.24 / 1.66 / 2.4 bps
ADA maker sample	40,930 fills over 354.6 hours
Funding receive side: long / short / flat	7 / 6 / 18

Our live Strike Finance dashboard (volume, cross-venue price gaps, funding): https://cardanorecord.com/strike.html

Disclosure: we make a daily data show about Cardano (The Cardano Record on YouTube), and this is one of its segments.

Do Cardano's governance vote rationales still resolve? Measuring it with db-sync and a blake2b-256 check

Elliot — Tue, 13 Oct 2026 23:19:27 +0000

Under CIP-1694, a Cardano governance vote can carry an anchor: a URL to a document that explains the vote, plus a blake2b-256 hash of that document. The hash goes on-chain and stays there. The document does not. It lives on someone's IPFS gateway or GitHub repo, and nothing in the protocol keeps it there.

That turns a vague question into one you can measure: is Cardano's governance record durable? If someone reads a vote years from now, will the reasoning still be there, and will it be the same document the voter hashed?

This post covers how we measure it from a local cardano-db-sync Postgres database plus our own fetcher, how we check the method, and the trap that nearly gave us a badly wrong headline.

Two tiers, kept apart

The measurement has two parts that answer different questions. We never combine them into one figure.

Tier 1, the census, is plain on-chain arithmetic: of all votes cast, how many carry an anchor at all? It needs no network calls and no judgement. A vote with no anchor published no rationale, and the ledger alone settles that.

Tier 2, the probe, asks whether anchored documents can still be fetched and still match their hash. That needs the network, so it runs on a sample and is reported with a confidence floor.

Tier 1: the census

Votes are in db-sync's voting_procedure table, one row per vote, along with who cast it. A vote that carries an anchor points to a row in voting_anchor, which holds the URL and the data_hash. The census counts votes, groups them by voter role (DRep, stake pool operator, Constitutional Committee member) and splits each group by whether an anchor is present.

(A DRep, or delegated representative, is an account that ADA holders delegate their governance voting power to.)

The census never touches the network, so it is the most solid number in the set.

Tier 2: the probe

For the probe, we draw a random sample of anchors, fetch each URL ourselves, hash the bytes we get back with blake2b-256 and compare the result with voting_anchor.data_hash. Each anchor lands in exactly one of three buckets:

resolves, hash matches: the record is intact
resolves, hash differs: the document changed after the vote was cast
does not resolve: gone, from here, today

Each fetch has a 12-second timeout. The sample currently holds 3,500 anchors, and the latest run probed 25 of them.

The resolve rate is always published with its Wilson lower bound. Our editorial rules say a rate never goes out without a confidence floor, and a sample is not the whole population.

How we checked the method

Before trusting the probe, we ran it on anchors that db-sync had already fetched and validated. In every case, our blake2b-256 of the fetched bytes matched the on-chain data_hash exactly. That confirms we hash the same thing the voter hashed. Without that check, a "hash differs" result could just be our own bug.

The trap: db-sync's own fetch errors

db-sync runs its own off-chain fetcher and records the results in two tables: off_chain_vote_data for documents it fetched and validated, and off_chain_vote_fetch_error for failed attempts. The error table has far more rows than there are vote anchors, and only a small fraction of anchors had ever been validated. Taken at face value, it says almost every vote rationale on Cardano can't be retrieved. That would have been the most quotable number we had ever produced.

It is false. We picked anchors at random from those db-sync had marked with a JSON decode error and fetched them by hand. Every one returned HTTP 200 with valid CIP-100 JSON-LD. The error table measures our node's fetcher (its timeouts, retry policy and ability to reach gateways) and says very little about whether the documents exist. A table that looks authoritative can still be reporting on your own plumbing.

So off_chain_vote_fetch_error and off_chain_vote_data are never the basis of a published figure. We read them only to decide what to probe, and the pipeline still flags the db-sync fetcher as unreliable in this run's output.

Other traps

"Does not resolve" is local. It means our fetcher didn't get the document today within 12 seconds. It doesn't prove the document is gone from everywhere, and we don't phrase it that way.
Report mismatches, don't characterise them. The chain tells you the bytes differ from what was hashed. It doesn't tell you why.
Hosts are concentrated. Group anchors by URL host and one host holds 34.6% of them. A single host's availability can move a large share of the result, so we publish the host list next to the rate.
Superseded votes. If you move from the census to vote tallies, note that voting_procedure keeps every row when a voter changes its vote. Counting all rows double-counts. Our tallies take only the latest vote per voter (DISTINCT ON ... ORDER BY id DESC), which is the vote that actually counts.
Keep the tiers apart. Mixing a network-dependent sample into an on-chain census produces a number neither tier supports.

Results

Data from our own node, as of 2026-10-07 17:30 UTC (epoch 660). The percentages are the pipeline's own.

Measure	Value
Votes cast	36,540
Votes carrying an anchor	12,145 (33.2%)
DRep votes anchored	11,024 of 31,289 (35.2%)
SPO votes anchored	151 of 4,254 (3.5%)
Constitutional Committee votes anchored	970 of 997 (97.3%)
Anchors in probe sample	3,500 (25 probed this run)
Resolves, hash matches	2,313 (66.1%)
Resolves, hash differs	27
Does not resolve	1,160
Resolve rate	66.9% (Wilson lower bound 65.3%)
Largest host share	34.6% (4,207 anchors, most-brass-sun.quicknode-ipfs.com)
Second host	raw.githubusercontent.com, 1,943 anchors

These are counts, not verdicts on any voter. We are not affiliated with Intersect, Input Output, the Cardano Foundation or any project covered. Our live governance dashboard (stake-weighted votes and treasury flow) is at cardanorecord.com/governance.html.

Reading a lending protocol's whole loan book straight from Cardano's ledger

Elliot — Tue, 06 Oct 2026 21:19:21 +0000

We wanted one number: how far does ADA have to fall before a real share of Indigo's loans gets liquidated? Indigo is a Cardano protocol where you lock ADA and mint synthetic assets (iUSD, iBTC, iETH…) against it. Each position is a CDP, a collateralized debt position.

The protocol's own API was the obvious place to start. When we started (September 9) it listed only the v3 positions: 50 CDPs holding about 6,300 ADA. The real book was about 3,000 times bigger, and it was sitting in plain sight on chain.

This post shows how we read it from a local cardano-db-sync Postgres database, and how we check that the decode is complete. That check matters more than the decode itself.

1. Find where the positions live

On Cardano, a smart contract's funds are UTxOs locked at a script address. Every CDP is one UTxO at Indigo's v2 CDP validator, and that address's payment credential is ff0b10bff20e4b68b491492e5ba6c8048a704763b0a45ce2995da0be.

We found it by working backwards: take recent transactions that mint iUSD and look at which script output each one creates. Every one of them lands on that credential.

2. Pull the unspent outputs and their inline datums

db-sync ships a utxo_view of unspent outputs. Every CDP carries its state as an inline datum, and db-sync stores those already decoded to JSON in the datum table:

SELECT u.value::numeric          AS lovelace,
       d.value::text             AS datum_json
FROM   utxo_view u
LEFT   JOIN datum d ON d.id = u.inline_datum_id
WHERE  u.payment_cred = decode('ff0b10bff20e4b68b491492e5ba6c8048a704763b0a45ce2995da0be', 'hex');

On 2026-10-06 that returned 314 UTxOs. 311 decode as CDPs; the 3 that don't are reported as undecoded.

3. Decode the datum

The v2 CDP datum is nested Plutus constructors. Stripped down:

con0[ con0[ con0[ bytes owner_pkh ],
            bytes  iasset_name_hex,          -- "iUSD", "iBTC", ...
            con0[ bytes policy, bytes name ], -- collateral; ("", "") = ADA
            int    minted_raw,                -- the debt, 6 decimals
            con0[ int updated_ms, int interest_acc ] ] ]

In Python:

import json

def decode_cdp(lovelace, datum_json):
    f = json.loads(datum_json)["fields"][0]["fields"]
    asset = bytes.fromhex(f[1]["bytes"]).decode()
    if not asset.startswith("i"):
        raise ValueError("not a CDP")
    return {
        "asset": asset,
        "owner": f[0]["fields"][0]["bytes"],
        "collateral_ada": int(lovelace) / 1e6,
        "collateral_is_ada": f[2]["fields"][0]["bytes"] == "",
        "debt": int(f[3]["int"]) / 1e6,
    }

Anything that doesn't fit the shape gets counted, not dropped. A decoder that quietly skips rows it doesn't understand will tell you the book is smaller than it is, and it will look fine while doing it.

4. Prove it's complete

Every iAsset is minted under one policy (f66d78b4a3cb3d37afa0ec36461e51ecbde00f26c8f0a68f94b69880). The total minted minus the total burned is the amount of each iAsset that exists. If our decode has found every position, the decoded debt per asset should equal that number:

SELECT encode(ma.name, 'escape') AS iasset, SUM(mtm.quantity)::numeric AS net_minted
FROM   ma_tx_mint mtm JOIN multi_asset ma ON ma.id = mtm.ident
WHERE  encode(ma.policy, 'hex') = 'f66d78b4a3cb3d37afa0ec36461e51ecbde00f26c8f0a68f94b69880'
GROUP  BY 1 ORDER BY 1;

Result on 2026-10-06: iADA, iBTC, iETH, iEUR, iJPY and iSOL reconcile to 100.00%. iUSD comes to 95.2%. We have ruled out the redemption script, which holds reference datums rather than CDPs. We still don't know where the rest is, so we publish the gap rather than round it away, and our pipeline refuses to publish if any asset falls below 85%.

5. The traps

Liquidation leftovers. 14 UTxOs (on 2026-10-06) hold only the minimum ADA (exactly 1.8619 ADA each) plus a stale debt field, so their ratio looks absurd (one came out at 0.00014). They are positions that were already liquidated. We filter out anything with ≤ 5 ADA and a ratio ≤ 0.5, and report how many we removed.
No price, no stress test. 6 iSOL positions are left out of the dollar figures because we had no cross-checked USD price for iSOL that run. They still count toward the coverage check above.
iADA doesn't belong in an ADA-price stress test. Its debt is in ADA, so its collateral ratio doesn't move when the ADA price does. Including it overstates the risk.
There is no single minimum ratio to hardcode. The indexer returns mcr = null for every asset, so we show the curve across 110%, 120%, 130% and 150% instead of pretending to know one.

6. What the book looks like

As of 2026-10-06 13:18 UTC, with ADA at $0.276:


Positions in the stress test	287 (of 311 decoded)
iAsset debt	$1.89M
Collateral	17.4M ADA (~$4.81M)
Whole-book collateral ratio	2.54
ADA price where 10% of the debt is under 120%	$0.175 (−36%)
ADA price where 50% of the debt is under 120%	$0.143 (−48%)

It's a snapshot, not a forecast. The live version, with the full curve and CSVs, is at cardanorecord.com/risk.html, and it's refreshed several times a day from the same node.

We run The Cardano Record, a daily show built entirely from our own node's data, with every prediction it makes scored in public, the misses included. Not financial advice.