A blockchain index, built into the platform
A live, multi-chain index that decodes every on-chain event the moment a block is final, reorg-safe and queryable as business data, with balances at any block.
Quarterly audits, tax filings, and compliance checks all require the same thing: a complete, queryable record of what happened on-chain and when. That record is now part of the platform, with no separate indexing stack to run or reconcile.
Querying on-chain history no longer means replaying the chain
The Ledger Index decodes every event once a block is final and replays automatically when the chain reorganizes. The result lands as plain business data: holdings, transfers, fees, and redemptions, queryable at any past block.
- Decoding
- Before storage, not at query time
- Subgraphs to host
- None
- Reorgs
- Detected and replayed automatically
- History
- Queryable at any past block
An EVM node exposes chain state and logs. Historical state reads can require an archive-capable node, and business questions still need event decoding. Ledger Data stores those decoded records for supported platform queries.
Building that layer is non-trivial work. You author mappings for each contract. You keep the indexer in step with the chain across upgrades. You handle chain reorganisations (the short branch replacements that happen on every proof-of-work and many proof-of-stake networks) so a correction at the tip of the chain does not silently corrupt your history. Then you reconcile the result against your own records, because an index that drifts is worse than none at all.
In DALP 3.0 that system is the platform. The Ledger Index finds your contracts on-chain on its own, decodes each event as it arrives, and keeps the full history in a form you query directly.
How it stays current
It runs live and historical at the same time. One pass follows each chain head as blocks finalise and backfills complete history behind it, across each network you operate on. Decoding happens on the way in, so what lands in the database is typed business data: not hex-encoded raw logs to parse later, not a raw event schema you reverse-engineer at query time.
- 1Follow
Subscribes to every chain head as blocks finalize, and backfills full history behind it, across each network you run.
- 2Decode
Turns each event into typed, human-readable values on the way in. No hex, no raw logs to parse downstream.
- 3Reconcile
Holds the result reorg-safe. A chain reorganization rolls back and replays deterministically: the same history every time.
- 4Serve
Balances, fees, yield, and redemptions become direct queries through the Platform API, the moment they are final.
Why it matters
For a bank, an asset manager, or a fund administrator, the question is never just "what does the ledger say today?" Quarterly audits want balances at a specific date. Tax filings require a transfer-by-transfer record for each holder. Compliance checks ask whether a given address was on the investor register at the time of a particular transfer. None of those questions have answers without an indexed read model.
An integration can query an indexing service or reconstruct the required records from chain data. DALP provides the indexed model as part of the platform.
- Stand up a separate indexing service next to your platform.
- Author and redeploy a mapping every time a contract changes.
- Reconcile its data against the chain, and against your record.
- Hope a reorg or a backfill did not leave it quietly wrong.
- It discovers your contracts on-chain and follows them for you.
- Decoded history and live state arrive in one place, already queryable.
- It reads from the same data the compliance and settlement paths write.
- The result is reorg-safe and deterministic: queries follow the indexed canonical history.
Correctness is the point
An index that can be wrong is worse than no index at all. A wrong number returned with confidence (a balance that excludes a transfer that happened after a reorg, or a fee total that double-counts a corrected block) becomes a finding when an auditor compares it to the chain.
The Ledger Index stores a hash for every entry in the reorg-detection window. When a chain reorganisation occurs, it walks backwards from the last processed block, comparing stored hashes against canonical hashes from the node. It identifies the fork point, reverses every mutation from that range in exact reverse order, then replays forward from there. A reorganization can change which block occupies a block number. Reconcile historical results against the canonical block identity. That is what makes a historical balance audit evidence rather than a dashboard reading.
When the index changes shape, a new version rebuilds the entire dataset in the background and swaps in atomically.
Fast enough to stand up cold
Speed is held to the same standard as correctness: every optimisation must return byte-for-byte identical results to the naive path. In 3.0, the Ledger Index groups contiguous contracts into shared block scans, batching addresses together so one RPC call covers many contracts in one range. It learns and remembers the block where each network's first relevant event appears, so backfills skip dead ranges instead of scanning them. Finalised history is cached so a restart does not re-fetch what is already known. Backfill duration depends on the indexed history, contract count, and RPC capacity.
Review finality and rollback settings for each network. Network configuration explains the startup checks and operator responsibilities.
New in 3.0: indexed for the questions a book gets asked
We widened what the Ledger Index captures well beyond current balances. What is now tracked is the financial detail a servicer, an auditor, or a regulator actually asks for. Each is queryable at any past block.
Pull who held what on any past date. An auditor can verify the register at quarter-end, and a governance log reflects voting power at the exact block a vote was cast.
Collections, exemptions, and accruals are indexed and persist across fee-token changes, so a servicer can reconstruct the complete fee total for a period without replaying the chain.
Consumed interest, closed accruals, payout schedules, and claim records are kept, not re-derived, so treasury yield reconciles against the ledger without re-running calculations at read time.
Maturity-redemption events are tracked per holder, so the servicing record for a bond or debt instrument is a direct lookup, not a manual reconstruction from raw events.
Durable transactions
Every transaction carries explicit state across preparation, approval, broadcast, and confirmation, so a stuck step recovers and a retry never resends.
Data feeds
Push off-chain prices and values into assets through issuer-signed, per-token feeds. An asset only acts on a figure a named party has vouched for.