Refuse the wrong number
The Ledger Index now follows blocks by identity rather than height so a reorganization cannot mix data, and an inexact price is refused instead of rounded.
DALP 3.2 checks block hashes and network identity before advancing indexed state. It also isolates stalled chains and rejects prices that exceed feed precision.
Checks for block identity, chain identity, and precision
A reorganization, meaning a recently accepted block replaced by a competing one, is the moment indexed data is most likely to go subtly wrong. Following blocks by their identity rather than their position is what makes that moment safe.
- Block identity
- Followed by hash
- Wrong chain
- Refused, not indexed
- Stalled chain
- Isolated from the rest
- Inexact price
- Rejected at submission
A block is now identified, not just numbered
Two blocks can carry the same height and be different blocks. That is exactly what a reorganization produces, and it is the case that has to be handled by identity rather than by position.
Near the chain tip, the platform now tracks the block it is following by its hash, the value that identifies that specific block, and fetches its records against that hash. If the data coming back belongs to a different block than the one being followed, the platform rebuilds rather than continues. Previously the head was tracked by height alone, so a replacement block at the same height could contribute records that were then recorded under the block that had been replaced. Nothing announced that, which is precisely the problem.
Network identity checks stop indexing the wrong chain
The first time the platform successfully uses a network, it records that chain's founding block and its declared identifier. If either later disagrees, the platform stops with a configuration error and writes no progress.
This protects against a mundane and expensive mistake: an endpoint edited to point at a different chain than the one it is configured for. Without the check, that endpoint answers normally and the platform indexes another chain's history into your records. With it, the platform refuses to proceed rather than producing a mixture no one can later separate.
One stalled chain no longer stops the deployment
A failure on one network no longer makes every healthy network unavailable.
A failing endpoint used to be able to park its chain for the life of the process, and a single stopped chain made the whole deployment report itself unhealthy, taking it out of rotation. Now a transport failure or a timeout lets the chain resume when the endpoint recovers, and one stopped chain no longer fails the readiness of a deployment whose other chains are indexing normally. A genuine contract rejection is still treated as a rejection, because that is a real answer rather than a failure to get one.
Catching up on history also spreads across the deployment rather than being pinned to one process, so historical indexing progresses with the capacity you actually run.
A price is published exactly or not at all
A feed publishes prices at a fixed precision. Submitting a price carrying more precision than the feed can hold used to round it toward zero and publish the rounded value, which meant the published number could differ from the approved one. The sharp case was a price smaller than the feed's smallest unit: it became zero, and the feed answered zero.
The platform now refuses that submission. The check is a round trip rather than a rounding rule, so it catches any conversion that would lose value, and it returns a non-retryable error saying the price carries more precision than the target feed can publish. The fix is on your side and is stated with the error: round the price to the feed's precision before submitting it, or create the feed with enough precision to carry it.
Check price precision before upgrading. A submission that previously succeeded with a silently altered value now fails. Integrations that submit prices at higher precision than their feed must correct the value before sending it.
Statistics no longer double-count a replayed conversion
A conversion that arrived twice, through a replay or two concurrent deliveries, could add its principal to the running totals twice even though only one record was stored. Recording the conversion is now what gates the counting, so a duplicate delivery adds nothing.
The correction has a limit: this stops the totals from drifting further. It does not go back and correct a total that already drifted. If you have reason to think a conversion total is overstated, raise it rather than assume the upgrade repaired it.
Compatibility
No API changes, other than the price-feed rejection described above.
This release rebuilds indexed data. The platform retains the previous projection during the rebuild and promotes the new one after it catches up. Reads that require unavailable data can return a retryable rebuilding response. Schedule capacity for replaying the deployment's chain history.
Understand indexed reads → · Understand market data → · Watch index health → · If indexing stalls →
Networks & RPC
The platform runs its own connection layer: admins define networks and endpoint pools, traffic leaves a lagging node, and an organisation can use many chains.
TypeScript SDK
The client keeps its namespaced shape with types from the platform's own routes, one flat argument per call, a bounded wait on writes, and query factories.