Ledger Data

The record holds business data, not raw chain data: who holds what, every transfer, every fee, already decoded, so a holder list or a year of transfers costs one database query rather than a walk of the chain.

The index carries a progress point for each network and answers nothing past it. A block's records and its progress point commit together, so no read ever sees half a block.

When a network replaces recent blocks, the index deletes the records above the fork and replays the canonical chain, so the same blocks always produce the same figures.

Why an indexed record mattersCopy Anchor Link

Ledger Data lets you answer a business question about a ledger network with one query, instead of decoding its blocks and events yourself. It keeps a record of every network the platform follows, current as blocks arrive, organized into holdings, transfers, and the other records a network node's raw events do not carry on their own.

Ledger Data is the one record every stage of an instrument's life writes to and reads from, not a stage itself. Asset Lifecycle names the risk that record removes as seam count, not tokenization. A programme that runs issuance, custody, trading, and reporting as separate systems decodes the same chain a second way in each one. Every one of those junctions is a reconciliation where an instrument's ledger state and its legal record can drift apart. From a primary sale through a coupon payment to a delivered trade, every stage answers from the one record Ledger Data keeps, so none of them owns a second decoder that the others have to trust.

Who held this security on 31 March. Every transfer for one holder across a tax year. Whether an address was on the investor register at the moment a particular transfer settled. Answering these questions directly from ledger data requires event decoding and historical reconstruction. Ledger Data performs that work for supported contracts.

The risk Ledger Data removes on top of that is a wrong number returned with confidence. A balance that omits a transfer restored after a chain reorganisation, or a fee total that counts a corrected block twice, becomes a finding the moment someone compares it against the chain. Ledger Data corrects by deletion and replay rather than by editing a figure in place, so the same query over the same blocks returns the same answer every time. That repeatability is what makes a historical balance evidence rather than a dashboard reading. The historical balances token feature is the on-chain counterpart: it checkpoints balances and total supply so that a record date can be answered on chain too.

Its limits matter just as much. Ledger Data does not change what a network treats as final, does not prove reserves held anywhere else, and covers only the contract types the platform knows. Evidence about an external bridge, a custody provider's own books, or an off-chain reserve comes from a separate source.

Watching the index day to dayCopy Anchor Link

Day to day, watching Ledger Data means watching a process rather than operating one. It follows every network the deployment has enabled, and the number that matters is how far its progress point sits behind that network's newest block. Everything else on the monitoring surface explains why the gap is what it is.

The index normally follows the network head. It can also catch up, backfill a contract's earlier history, roll back a replaced block, or rebuild after a change to its records.

The monitoring surface reports block lag, block age, how far the network sits ahead of its own settled point, whether the first full pass over history has finished, how much contract backfill remains, and whether a rebuild is running. Lag and staleness each drive the same chain toward one of two severities, degraded then critical, and a verdict changes only after several consecutive samples agree, so one slow block never flaps the board. The ledger indexing stalled runbook states the exact thresholds and the checks that tell ordinary catch-up from a chain whose ingest has actually failed.

You also decide, for each system the platform has discovered, whether the index keeps reading it. Excluding a system costs nothing today: its already-indexed data stays exactly as it is and stays readable, and the index stops claiming new work for it and for everything it deployed. Re-including that system costs a full backfill, because the index replays its entire history from its starting block rather than resuming where it left off. Indexing scope is where a platform administrator makes that choice, system by system, network by network.

A rebuild is the expensive case. A release that changes how the index records an event declares its own rebuild, and it reprocesses a network's full history under the new rules before a replacement copy takes over. The rebuild runs behind an already-serving deployment rather than gating it: existing reads keep answering from the current copy until the replacement has caught up, and only then do the two swap in a single step. Historical figures for the period a rebuild is still redoing read as provisional until it finishes, so check whether one is running before treating an old figure as final. The upgrades and migrations guide covers what a release requires and how to confirm a rebuild has actually finished, since a release reporting complete does not mean the rebuild has.

How the record stays correctCopy Anchor Link

Ledger Data sits behind an explicit trust boundary: it is a derived cache, rebuilt from the ledger network's own blocks and never the reverse. Indexed API reads use its progress and consistency rules. Operations that require a live network value use separate network reads.

One writer per network. Exactly one process holds the write lease for a network at a time, and each handover raises an ownership number that stamps every progress write. When a superseded owner finishes work late, the platform rejects its whole batch rather than letting it move progress after the handover. Settled history needs no single owner, because it cannot change. The owner splits that history into leased ranges any replica can claim, so catching up goes faster on a larger deployment while live following stays with one writer.

One batch, one write. The index reads a network in batches: a contiguous run of blocks that narrows to a single block near the live edge, where a reorganisation is still possible, and widens while catching up on older, settled history. A batch's decoded records, its progress point, the block hashes it keeps for reorganisation checks, and the change events its blocks produce all commit in one database transaction, or none of them do. The index tracks progress on two axes: how far it has read blocks in an unbroken run, and how far back it has filled in the history of every contract it discovered along the way. Reads use the second, stricter axis, because the index can read a block while a contract it found inside that block still owes its earlier history. That is what keeps a half-filled contract out of your results: rather than serving partial history for it, the index holds the answer back until the gap is closed.

The index follows a network's newest block rather than waiting for that network to declare a block settled, so a record appears within processing time of its block. A network declares a block settled through its own finality signal where it publishes one, and otherwise after a number of confirmations the deployment configures for it. The cost of following the newest block is that a network can still replace a recent one, and the design answers that directly. The index keeps a hash for every block inside a retained window, configured per network. The shipped defaults are 65 blocks on Ethereum, 200 on Polygon, 240 on Arbitrum, 24 on Base and Optimism, and 64 on any other network until a deployment sets its own. The configured window limits retained hashes; the network's finality signal is a separate boundary. Detection walks stored hashes and nothing else, so a rollback cannot reach past the oldest hash the index still keeps: the window is the bound on how far back a rollback can go, not a convention. Set it below the network's actual worst-case reorganisation depth and a replacement past that point is never detected, so a wrong figure survives uncorrected. Set it deeper than the network's own finality distance and the extra depth is pruned once its blocks are finalized, so it costs storage and comparison work for a bound the network already retired. Review the configured depth against the network's finality model and your operational requirements. A configured depth is not proof of the maximum possible reorganisation.

Detection walks back from the last processed block, comparing stored hashes against the network's current ones. Height alone would miss the case that matters: a replacement block can sit at the same height as the one the index already processed, so nothing appears to have moved and only the hash reveals the change. On a detected fork the index deletes every record above the fork point, rewinds its progress point, and retracts the change events it already delivered, all in one transaction. It then replays the canonical blocks. When no stored hash matches anywhere in the window, the index rolls the whole window back and replays it.

Running totals (figures the index folds forward as it processes, rather than recomputing per query) are the one place the index does wait. It folds a total forward only to whichever comes first, its own progress point or the newest block the network has declared settled, so it never has to un-fold a total. Point-in-time reads carry no such delay, because the index recomputes them from records a rollback can remove.

The integration contractCopy Anchor Link

An integration reads chain state from Ledger Data, not from the network. The platform's application programming interface (API) answers holdings, transfer history, balances at a past block, and compliance state out of the index. A live call to the network is the exception, kept for infrastructure checks and for the few values the index does not hold.

On-chain confirmation and indexed visibility are separate outcomes. A queued write that uses the indexer barrier waits until its block is available for indexed reads. If that wait expires, a retryable error identifies the transaction and states that it succeeded on-chain while indexed data is not ready. Check that transaction's outcome before resubmitting anything.

Follow the handle to the operation's Settlement VerdictA Settlement Verdict lets you report success only when an operation actually happened, not from acceptance alone, across four recorded end states.Read the concept, the recorded end state that states whether the operation completed, failed, or was set aside, then check the resource or indexing progress required by your integration.

Coverage is explicit, and discovery and registration answer different questions. For the contract types the platform knows, discovery is automatic: the platform finds each new contract through its own on-chain registries and fills in that contract's history from its deployment block, so nothing below the point of discovery is missing. A contract of a type the platform does not know, an externally issued token for example, stays invisible until someone registers it, and a query against it returns an empty result rather than an error. A balance at a past block is a direct lookup rather than a replay. The index also records derived figures, such as what a position was worth on a given day, as it processes the event that causes them. A history request therefore costs what its date range holds, not everything the deployment has ever seen.

The platform can also push committed changes to your endpoints through Webhook DeliveryWebhook Delivery retries a signed notification for three days and records whether a counterparty was told, so an integrator skips its own retry logic.Read the concept, the transport that delivers each committed change to your endpoint. It writes those events in the same database transaction as the indexed rows they describe, so you never receive an event for a movement the index does not hold. When a reorganisation removes the source block, the platform sends a follow-up Platform EventA Platform Event tells an integration what happened, under a name and shape that cannot change, so it never has to poll the chain or re-derive finality itself.Read the concept, the typed record for a pushed change that your handler matches against, marked as a retraction. That event names the earlier event it supersedes, so your handler can match the two. Keep your ingestion idempotent and reconcile against the indexed record after a rollback; what you do about work you already did on the retracted event is your own business rule, not something the platform decides for you.

What it evidences, and what it does notCopy Anchor Link

A control function reads Ledger Data as the evidence layer, not the enforcement layer. Enforcement happens on chain, inside the transfer itself, under Transfer-Path Compliance. The index records what the chain did, in a form you can query, export, and defend.

It produces the register at any past block, so a quarter-end holder list is a lookup rather than a reconstruction. Per holder it produces every transfer with its counterparty. Per period it produces fees collected and exemptions applied, yield accrued and paid, and redemptions. Each event it stores names the transaction sender, the contract that emitted the event, and the addresses involved. It keeps each address twice, as the raw address and as the identity the platform resolved it to, so a query by participant returns their activity whether you filter by a wallet or by the party behind it.

Two properties make the record defensible: repeatability and provenance. The same query over the same blocks returns the same figure. A correction is a deletion and a replay that the network's own canonical chain drives, not an operator editing a number, and every figure holds a progress point stating which blocks it covers.

Three limits belong in any control narrative. Coverage stops at the contract types the platform knows, so anything outside that set needs registering before it appears. The index observes ledger networks only, and holds nothing about a custody provider's own books, an external bridge, or an off-chain reserve. History exists for the period the platform has processed under the current recording rules, so a release that changes how the index records a derived figure leaves earlier periods incomplete until its rebuild finishes. Reads stay live while that rebuild runs, so those earlier periods answer incompletely rather than returning an error or nothing at all. Watch for one trap during that window: a chart calculated backwards from a current total still draws a line, so a populated chart on its own is no evidence that the rebuild has run. Check the monitoring surface instead: it shows whether a rebuild is running, and an active rebuild shows at once.

Frequently asked questionsCopy Anchor Link