Blockchain is 77% one over-deployed Alephium explorer, and running exceeds ordered

[2ndtlmining]

Prompted by "is 500 Alephium instances correct?". Short answer: the number is real and our arithmetic is right — but it does not mean what it looks like, and chasing it turned up something that contradicts a standing assumption.

Measured on live data, 2026-09-13.

The number

alephium/explorer:latest      569 running containers

That is the ~500 seen. It is not 500 Alephium nodes. It is one app, alphexplorer, and its containers break down as:

component frontend   569
component postgres   569
component backend      1
component daemon       0

569 copies of an explorer web frontend and its postgres, one backend, and no Alephium daemon at all. Whatever else it is, it is not 500 Alephium blockchain nodes.

It dominates the category

blockchain category    1,499 running containers
the two alephium apps  1,148   (77%)

alphexplorer alone is 1,139 of those. So the Blockchain bar on APP ECOSYSTEM is mostly this single deployment. Everything is being counted correctly — categorizeAppSpec matches thetrunk/alephium-standalone on the alephium keyword and applies that category to every container of the app, which is the intended app-level behaviour — but "Blockchain 1,499" reads as network diversity when three-quarters of it is one app's web frontend.

The part that contradicts a documented assumption

alphexplorer's spec says instances: 30 across 4 components — so at most ~120 containers were ordered. 1,139 are running.

The repo's standing assumption is the opposite. From the README/CLAUDE notes and #144's rationale: globalappsspecifications counts what was ordered, stats.runonflux.io/fluxinfo counts what is running, and ordered "always reads higher". Here running exceeds ordered by ~9.5x.

Worth deciding:

1. Is that a real over-deployment, stale containers never reaped, or a spec whose instances was recently lowered? (It changes whether the network data is wrong or our reading of it is.)
2. Does anything in the codebase actually rely on ordered >= running? If so it is wrong for this app today.
3. Should a single app be able to dominate a category bar without that being visible? The per-category drill-down does show alephium/explorer 569 if you expand it, so the information is reachable — the question is whether the collapsed bar is misleading enough to warrant a note.

No code change proposed yet — filing the measurement so the decision is made on numbers rather than on the surprise.

[2ndtlmining]

Ran the audit across the whole network. alphexplorer is a single outlier, not a trend — the standing "ordered reads higher than running" assumption holds everywhere else.

Data: 1,459 specs (387 enterprise excluded, 1,072 analysable); 6,371 node records; 8,319 containers parsed, every name well-formed. 6,418 containers (77.1%) matched a non-enterprise spec across 938 apps; of the 1,901 unmatched, 1,860 belong to enterprise specs (expected — compose: []) and only 41 containers across 33 app names have no spec at all. Numbers verified against a second live fetch.

Top 10 by running containers

app	ordered	running	ratio	excess	components
alphexplorer	120	1,139	9.49	+1,019	frontend 569, postgres 569, backend 1, daemon 0
probeamericas	100	102	1.02	+2	single
FoldingAtRunOnFlux10	100	100	1.00	0	single
globalping-probe	100	100	1.00	0	single
FoldingAtRunOnFlux22	100	100	1.00	0	single
softethervpn-test	100	100	1.00	0	single
FoldingAtRunOnFlux29	100	99	0.99	−1	single
FoldingAtRunOnFlux25	100	99	0.99	−1	single
FoldingAtRunOnFlux12	100	99	0.99	−1	single
FoldingAtRunOnFlux23	100	99	0.99	−1	single

Ranks 11–20 are more FoldingAtRunOnFlux* at 94–98 of 100. alphexplorer is the only multi-component app in the top 20; every other one lands within 6% of its order.

Aggregates (938 matched non-enterprise apps)

• Overall 6,418 running vs 6,157 ordered → ratio 1.042. Strip alphexplorer and it is 5,279 / 6,037 = 0.874 — the network as a whole is under-deployed.
• ratio > 1.5: 5 apps. ratio > 3: 1. ratio > 10: 0.
• Only 11 apps are over-deployed at all. alphexplorer contributes 1,019 of the 1,036 total excess containers — 98.4%. The other ten are +17 containers combined (worst: two WordPress at +3).
• 394 apps run below spec, aggregate shortfall 775 containers. Among the 54 apps with instances >= 10, median ratio 0.99.

The shape of the anomaly

alphexplorer spec: instances: 30, components [daemon, postgres, backend, frontend] — so 30 of each expected.

daemon      0     0.00x
backend     1     0.03x
postgres  569    19.00x
frontend  569    19.00x

Confirmed across 569 distinct node IPs, so it is genuine distribution, not duplicated node records. This is not a uniform 9.5x scale-up — two components are at 19x while the other two are effectively absent. I am reporting the shape only; the data does not identify a cause.

Component imbalance is actually common across the network, but almost always in the opposite direction — a component missing rather than multiplied (owncloudoffice owncloud=0 of 5, as01/ch01 vless=0 trojan=0, whoogleflux ddns=0 onion=0). alphexplorer is the only app whose imbalance runs far above spec.

Answering the three questions from the issue

1. Real over-deployment, stale containers, or a lowered spec? Still open — but the 19x/0x split rules out a clean "spec was recently lowered", which would have scaled all four components together.
2. Does anything rely on ordered >= running? Worth a separate check, but the exposure is narrow: this is one app out of 938, and the assumption holds for the other 937.
3. Should one app be able to dominate a category bar invisibly? This is the part still worth a decision. Blockchain reads 1,499 and is 77% this one deployment.

Script and full output are in the session scratchpad (overdeploy.py, overdeploy_report.txt). No repository files were touched.