The endpoint that answers questions it cannot answer

Measured 5 August 2026 · every figure read directly from the endpoints named · method and control below

Terra Classic's public REST endpoint returns historical token supply figures. The same node's RPC interface, asked the same question at the same height, returns failed to load state at height N; no commit info found. One of those is the truth. The REST layer does not say which, and it does not return the same answer twice.

The same question, three times, three answers

Supply of uluna at a height in the pruned past, asked through terra-classic-lcd.publicnode.com on one afternoon:

run	height	answer	agreement
1	7,544,910	724,941,531 LUNA	11 of 12 reads
2	7,544,910	738,900,463 LUNA	8 of 9 reads
3	7,454,731	728,433,205 LUNA	3 of 7 reads, 3 distinct

Each run reached what looked like a majority. Each majority was different. A client that queried once — which is what a client does — would have received a plausible number with no indication that asking again would produce another.

The same endpoint also returned identical supply for heights 7,300,000, 7,603,700 and 8,000,000 — a window during which Terra Classic's supply demonstrably changed by orders of magnitude. Whatever it is serving, it is not the state at the height requested.

What the node itself says

$ curl "…/abci_query?path=%22/cosmos.bank.v1beta1.Query/SupplyOf%22&height=7454731"
  ERROR: failed to load state at height 7454731; no commit info found

$ curl -H "x-cosmos-block-height: 7454731" "…/cosmos/bank/v1beta1/supply/by_denom?denom=uluna"
  {"amount":{"denom":"uluna","amount":"728433205285946"}}

Same operator, same chain, same pruned state. The RPC layer propagates the error. The REST layer returns a number.

The control — and the theory it killed

The hypothesis was that this is a Cosmos SDK problem — that the REST gateway swallows pruning errors generally, and every Cosmos chain's historical REST data is suspect. That would have been a much larger finding. It is wrong, and the test that showed it was wrong is the reason this report is worth reading.

Three other Cosmos chains, queried through the same provider, at a comparably pruned height, on the same afternoon:

chain	REST at pruned height	RPC at pruned height	agree?
Cosmos Hub	HTTP 500	failed to load state	yes
Osmosis	HTTP 500	failed to load state	yes
Juno	HTTP 500	failed to load state	yes
Terra Classic	a number	failed to load state	no

Cosmos in general behaves correctly. Terra Classic does not. A report claiming otherwise would have been published had this table not been produced first.

Every public endpoint, tested

Seven REST endpoints for Terra Classic, seven reads each, at three heights:

endpoint	historical state	reports which height it answered at
autostake	dead (404)	—
terrarebels	dead (no route to host)	—
everstake	dead (no route to host)	—
hexxagon	HTTP 500, consistently	yes
stakely	HTTP 500, consistently	yes
binodes	returns current state for any height	yes — detectable
publicnode	returns unstable values	no — undetectable

None of the seven serve historical state. Two fail honestly. One ignores the request but reports the height it used, so a careful client can detect it. The one that appears to work is the one that is wrong, and it is the only one that gives a client no way to notice.

Why only this chain — a plausible mechanism, unconfirmed

Terra Classic is the only chain here that ships mantlemint, a Terra-specific accelerator that serves LCD queries from its own store rather than the node's. The same provider publishes two separate archive snapshots for this chain — a 20.6 TB node archive and a 5.5 TB mantlemint archive — because there are two separate stores [3].

That would explain a REST layer answering where RPC refuses, and answering inconsistently if requests are balanced across instances backed by different stores. It is a hypothesis. It has not been confirmed with the operator, and this report does not assert it.

Test any endpoint yourself

The script used here is published. It checks whether a REST gateway agrees with its own node's RPC, and whether it answers the same question the same way twice. It works on any Cosmos chain [4].

node cosmos-endpoint-check.mjs \
  https://terra-classic-lcd.publicnode.com \
  https://terra-classic-rpc.publicnode.com uluna

  current state      stable (7 reads)
  reports its height NO — a client cannot tell which height it answered at
  historical (REST)  728433205285946 — 3/7 agree, 3 distinct
  historical (RPC)   ERROR: failed to load state at height 7454731

  VERDICT: REST returned a value the node's own RPC says does not exist.
           Do not trust historical figures from this endpoint.

What is measurable, and what is not

Queries without a height header are stable on every live endpoint — seven of seven reads, one value. Current state is fine. It is only historical state that is unreliable, which is what makes the failure easy to miss: the endpoint works perfectly until the moment you ask it about the past.

Terra Classic today, read consistently: chain columbus-5 at height 29,818,925, producing blocks; supply 6,453,019,171,451 LUNA; 6,078,274,435 UST still in existence; 90 bonded validators [1].

What this report cannot see

Terra Classic's actual historical supply. Not at any height, from any public endpoint. That figure is unavailable to this report and to anyone reading it.
Whether mantlemint is the cause. Consistent with every symptom, confirmed by nobody. Stated as a hypothesis and labelled as one.
Whether the values returned are corrupt or merely mis-addressed. They may be real state from the wrong height, or not state at all. Both produce the same wrong answer.
How long this has been true, or whether it was ever otherwise.
Whether other Terra Classic REST endpoints outside the Cosmos registry behave differently. Seven were tested; the registry lists four and three more were found.
Whether any published analysis of Terra Classic history relied on these figures. Plausible, and not something this report attempts to establish.

Method

Every figure was read on 5 August 2026 from the endpoints named. Each measurement is seven reads of an identical request; a value is only reported as the endpoint's answer if it won an outright majority, and the number of distinct answers is given alongside. The control chains were queried through the same provider on the same afternoon, at a height scaled to the same fraction of chain history. Where a run disagreed with an earlier run, both are published.

Sources

Direct queries to terra-classic-lcd.publicnode.com and terra-classic-rpc.publicnode.com, 5 August 2026. Endpoints listed in the Cosmos chain registry (github.com/cosmos/chain-registry, terra/chain.json), plus three found outside it.
Control chains via cosmos-rest / cosmos-rpc, osmosis-rest / osmosis-rpc and juno-rest / juno-rpc at publicnode.com, same date.
Snapshot sizes and types from publicnode.com/snapshots, retrieved 5 August 2026: Terra Classic Pruned 25.5 GB, Archive 20.6 TB, mantlemint Archive 5.5 TB. Both archives are marked available on Allnodes bare metal only.
The test script: github.com/vanedotreport/vane/blob/main/scripts/cosmos-endpoint-check.mjs

Vane reports observables, not intent. Nothing here asserts that anyone configured anything wrongly on purpose, and no operator was asked to comment before publication. The behaviour described is reproducible with the script above.