# A blockchain index, built into the platform

Source: https://docs.settlemint.com/docs/changelog/dalp-3-0/ledger-index
A live, multi-chain index that decodes every on-chain event the moment a block is final. Reorg-safe and queryable as plain business data, with balances at any past block.



**We built a full blockchain index into the platform. The chain now reads like a database: live state, complete history, every event decoded and ready to query.**

<Video src="/media/dalp-3-0/indexer.mp4" title="A blockchain index, built into the platform: DALP 3.0" description="A live, multi-chain index that decodes every on-chain event the moment a block is final, reorg-safe and queryable as plain business data." />

<Spotlight
  eyebrow="Ledger Index"
  title="The chain, as one queryable ledger"
  aside="<FactList items={[
  { label: &#x22;Decoded views&#x22;, value: &#x22;40+&#x22; },
  { label: &#x22;Subgraphs to host&#x22;, value: &#x22;None&#x22; },
  { label: &#x22;Reorgs&#x22;, value: &#x22;Rolled back and replayed&#x22; },
  { label: &#x22;History&#x22;, value: &#x22;Every block, queryable&#x22; },
]} />"
>
  Holdings, transfers, fees, and redemptions: decoded the moment a block is final, held reorg-safe, and queryable as plain business data. The work you would otherwise hand to a separate indexing stack is now part of the platform you already run.
</Spotlight>

An EVM node answers one question well: what is true right now. It holds the current state of every account and contract, but it has no memory. Ask who held a security token on 31 March, or show every fee collected since an instrument launched, and a node gives you nothing. Those questions require a separate layer that reads each block as it finalises, decodes the events inside, and stores the result in a form you can actually query.

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 [#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.

<Pipeline
  caption="One pass, every block: the same path runs live at the chain head and backfilling history behind it."
  stages="[
  { title: &#x22;Follow&#x22;, detail: &#x22;Subscribes to every chain head as blocks finalize, and backfills full history behind it, across each network you run.&#x22; },
  { title: &#x22;Decode&#x22;, detail: &#x22;Turns each event into typed, human-readable values on the way in. No hex, no raw logs to parse downstream.&#x22; },
  { title: &#x22;Reconcile&#x22;, detail: &#x22;Holds the result reorg-safe. A chain reorganization rolls back and replays deterministically: the same history every time.&#x22; },
  { title: &#x22;Serve&#x22;, detail: &#x22;Balances, fees, yield, and redemptions become direct queries through the Platform API, the moment they are final.&#x22; },
]"
/>

## Why it matters [#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.

Without one, institutions typically choose between three paths: run a third-party indexing service in parallel and reconcile its output against the chain; replay blocks manually at query time; or tell an auditor the data is not available. None is acceptable on a regulated book.

<BeforeAfter
  before="{
  title: &#x22;Reading the past, the usual way&#x22;,
  points: [
    &#x22;Stand up a separate indexing service next to your platform.&#x22;,
    &#x22;Author and redeploy a mapping every time a contract changes.&#x22;,
    &#x22;Reconcile its data against the chain, and against your record.&#x22;,
    &#x22;Hope a reorg or a backfill did not leave it quietly wrong.&#x22;,
  ],
}"
  after="{
  title: &#x22;With the Ledger Index&#x22;,
  points: [
    &#x22;It discovers your contracts on-chain and follows them for you.&#x22;,
    &#x22;Decoded history and live state arrive in one place, already queryable.&#x22;,
    &#x22;It reads from the same data the compliance and settlement paths write.&#x22;,
    &#x22;Reorg-safe and deterministic. The answer is the same every time.&#x22;,
  ],
}"
/>

## Correctness is the point [#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.

So the guarantee comes first. 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. The same query against the same block number always returns the same answer. That is what makes a historical balance audit evidence rather than a dashboard reading.

The same determinism guarantee applies across upgrades. When the index changes shape, a new version rebuilds the entire dataset in the background and swaps in atomically.

<Callout title="Reindex without downtime">
  Nothing reading the index goes dark during a reindex. The previous version keeps serving until the new one has fully caught up, then the swap is atomic. No query window, no stale reads.
</Callout>

## Fast enough to stand up cold [#fast-enough-to-stand-up-cold]

<Metric value="~26 min" label="to re-index a 1,287-contract chain across ~147,000 blocks, down from roughly 90 minutes, with identical results" source="DALP 3.0 Ledger Index backfill benchmark, at stock RPC limits." />

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. A fresh environment, or one recovering after an upgrade, becomes queryable in minutes.

A new deployment needs no manual tuning. Safe rollback depths ship pre-configured for Ethereum, Polygon, Arbitrum, and generic L2s, so the Ledger Index knows how far back to look on each chain out of the box. The block range tunes itself to the RPC endpoint it is given.

## New in 3.0: indexed for the questions a book gets asked [#new-in-30-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.

<Cards>
  <Card title="Balances at any block" href="/docs/api-reference/token-features/historical-balances">
    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.
  </Card>

  <Card title="Fees, in full" href="/docs/api-reference/token-features/transaction-fee-accounting">
    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.
  </Card>

  <Card title="Yield you can account for" href="/docs/api-reference/token-features/fixed-treasury-yield">
    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.
  </Card>

  <Card title="Redemptions per holder" href="/docs/api-reference/token-features/maturity-redemption">
    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.
  </Card>
</Cards>

[Read historical balances →](/docs/api-reference/token-features/historical-balances) · [Browse the token-feature APIs →](/docs/api-reference/token-features)
