UTXO To Virtual State To Indexer

First Contact#

UTXO state is the spendable-state model. Virtual processing produces state consequences. Indexers and APIs organize observations. These layers should reinforce each other, not replace each other.

Working Model#

Applications that care about durable state need to know whether they are looking at protocol objects, virtual-state consequences, indexer replay, or API presentation. The same field name can be reassuring only after the source path confirms what the field means.

Expanded State And Observation Bridge#

UTXO state, virtual processing, and indexer observation form a chain of evidence, not a single interchangeable object. UTXO state is the spendable-output model. Virtual processing is where consensus consequences update accepted data and state. Indexers and APIs can expose useful views of those consequences, but their correctness depends on source behavior, replay, recovery, and field preservation.

This matters for application design. An application that only reads an indexer row should know what the row represents, how it was derived, and what would happen during replay or disagreement. A page can use an indexer observation as a labeled observation, but it cannot use that observation alone to prove base protocol behavior.

The safe reading path is: understand the UTXO model, then virtual-state consequences, then accepted evidence, then indexer/API representation. The implementation page owns exact fields and edge cases.

A concrete review pattern is to name the layer before trusting the field. A UTXO entry is not the same thing as a wallet balance display. A UTXO diff is not the same thing as a general explorer row. An indexer endpoint can be useful only after the reader knows whether it is showing protocol state, a derived view, a cache, or a replayed observation. This page should therefore train readers to ask where the data came from before using it as evidence.