Transfer → Investment Ledger
Observed transfer becomes normalized DLT state; Investment Ledger interprets ownership transfer / reallocation and ownership lineage.
Product module
Blockchain indexing for Tokenistry modules
The Indexing Engine tells Tokenistry what happened on-chain. Higher-level modules determine meaning — confirmation tracking, reorg handling, normalized state and recovery underneath.
Tokenization backends need a durable view of chain reality. The Indexing Engine supplies that observed state. Domain modules own interpretation and reconciliation — for example turning a transfer into an ownership transfer in the Investment Ledger, or reconciling whitelist state in Compliance.
How state flows
dlt.state.path
Blockchain
Indexing Engine
Normalized DLT State
Domain Module
Whitelist → Compliance
Observed whitelist state is read back from the registry, so what a token will actually permit can be checked against what was asked for.
What it reports
- DLT event indexing
- transaction monitoring
- historical blockchain data
- confirmation tracking
- reorg handling
- normalized chain state
- application synchronization
- observed state for domain modules
- audit trails
- alerting
Reconciliation is not owned by the Indexing Engine as a product. Domain modules own expected-vs-actual checks using the observed state this module supplies.
Where it sits
DLT
Indexer
Customer DB
Product / Ops
Indexed data stays in your environment under the default customer-hosted model.
FAQ
Is this a public blockchain explorer?
No. It is application-oriented indexing for the events and entities Tokenistry modules care about. It tells you what happened on-chain; higher-level modules determine meaning.
Does the Indexing Engine own reconciliation?
No. It supplies observed / normalized DLT state. Domain modules such as Compliance and the Investment Ledger own reconciliation against expected domain state.
How does this relate to the Transaction Engine?
Transaction infrastructure owns outbound orchestration. Indexing observes chain reality so domain modules can align application meaning — including cases the application did not initiate.
What this module owns
Owns
- normalized events and contract state
- confirmation depth and reorg handling
- backfill and recovery
- what happened on chain
Does not own
- what any of it means — the domain modules decide that
- ownership semantics
- transaction submission
- business rules of any kind
Technical surface
Networks and contracts are registered, then subscribed to. Events are read back normalized, by page or as a stream, with the confirmation depth the network was registered with.
- GET /v1/networks
- POST /v1/networks
- GET /v1/contracts
- POST /v1/contracts
- GET /v1/contracts/{id}/status
- POST /v1/contracts/{id}/reindex
- GET /v1/contracts/{id}/subscriptions
- GET /v1/events
- GET /v1/events/stream
Every mutating call carries an Idempotency-Key and returns an operation that is polled to a terminal state, so a retry returns the original operation instead of issuing a second one. Rejections before signing, conflicts and reverted executions are distinct failures rather than one generic error. The full schema is served as OpenAPI by the deployment itself.
Deployed as a container image with a Helm chart and Terraform modules, single-tenant in your own cloud account, against a PostgreSQL database you hold — see the deployment model.
Related
Chain state your product can rely on
We can map indexing and normalized DLT state into the domain modules that own meaning and reconciliation.
Discuss your architecture