Feeds update flow
How DALP accepts issuer-signed feed updates, validates them on chain, indexes accepted rounds, and exposes current values to contracts, APIs, and the Asset Console.
DALP feeds turn signed issuer values into current data for asset workflows. The update path has four boundaries: submitter authority, contract validation, indexed activity, and consumer freshness checks.
System context
A feed update starts with an authorised issuer identity and ends as a current value available to contracts, the Unified API, and the Asset Console. DALP keeps the write path narrow: the submit route resolves the signer, the transaction queue executes the on-chain call, the feed contract enforces validation, and the indexer records accepted events for off-chain reads.
Flow overview
- An authorised issuer prepares a scaled value and observation timestamp for a registered feed.
- The caller submits the update through the DALP feed submit route.
- The route resolves the submission signer and issuer identity for the feed topic.
- The transaction queue calls the feed operation and returns a transaction result when execution completes.
- The feed contract verifies the issuer, nonce, timestamp, deadline, and positive-value rule before storing the round.
- Accepted rounds emit feed events. The chain indexer writes them into DALP's off-chain data model.
- Consumers read the value on chain, through a Chainlink-compatible adapter, through the Unified API, or in the Asset Console.
Submission authority
DALP uses topic-aware submission rules.
| Feed topic | Authorisation model | Signing identity |
|---|---|---|
| Price topic | The caller must hold the system-level feeds manager role. DALP signs on behalf of the organisation identity registered for the price topic. | Organisation submission signer and organisation identity |
| Other feed topics | The executing user's identity must be registered as a trusted issuer for the feed topic in the feed's trusted issuers registry chain. The trusted issuer entry is the authorisation. | User signing wallet and user identity |
The submit route checks the feed's indexed topic and trusted issuers registry before signing. When the feed row is not indexed yet, the route fails closed with a retryable signer-resolution error rather than guessing the topic.
Validation checkpoints
| Checkpoint | What DALP verifies | Where it is enforced | Failure outcome |
|---|---|---|---|
| Issuer authority | The signer identity can issue values for the feed topic. | Submit route pre-check and feed contract | The submit route returns a permission error, or the on-chain call reverts. |
| Nonce ordering | The issuer identity uses the next expected nonce for the feed. | Feed contract | The update is rejected and no round is stored. |
| Observation time | The submitted timestamp is acceptable for the feed contract. | Feed contract | The update is rejected when the timestamp fails validation. |
| Positive value | The value is greater than zero when the feed requires positive values. | Feed contract | The update is rejected. |
| Decimal encoding | The value is submitted as an integer string scaled by the feed's decimal precision. | Caller, route payload, and feed contract | Incorrectly encoded values produce the wrong economic value or fail contract validation. |
| Drift allowance | The submitted value is compared with the previous value according to the feed configuration. | Feed contract | The round can be marked as an outlier for consumers that enforce stricter tolerance. |
Stored and indexed state
Accepted updates store a new feed round on chain. The current API surface exposes the transaction hash, feed address, submitted value, and nonce for the submission result. Follow-up reads can fetch the latest value, a specific round, the feed configuration, and staleness status.
The indexer gives off-chain consumers a searchable activity and data view, but on-chain reads remain available directly from the feed contract. Staleness checks read the latest round from the feed contract and compare its update timestamp with the current chain timestamp, so callers can decide whether the latest value is fresh enough for a pricing, collateral, redemption, or reporting workflow.
Sequence diagram
Failure modes
| Failure mode | What happens | Operator response |
|---|---|---|
| Feed not indexed yet | The submit route cannot determine the feed topic or trusted issuers registry. | Wait for the indexer to catch up, then retry the same request with the same idempotency key where applicable. |
| Caller lacks topic authority | The caller is not the feeds manager for a price-topic feed, or the user's identity is not a trusted issuer for a non-price topic. | Register the correct trusted issuer or use an account with the feeds manager role. |
| Invalid nonce | The submitted update does not match the next nonce for the issuer identity. | Read the current nonce and resubmit with the next expected nonce. |
| Invalid value | The value fails positivity, timestamp, decimal, or other feed validation. | Correct the payload before retrying. |
| Stale feed | No accepted round falls within the consumer's maximum age. | Block or flag the dependent business operation according to the product policy using that feed. |
| Indexer lag | On-chain state is newer than indexed API or console data. | Use direct contract reads for critical confirmation, or wait for the indexer to catch up before using indexed views. |
| Removed feed | Directory resolution no longer returns an active feed for the subject and topic. | Register a replacement feed or update consumers to use the new source. |
Consumer reads
Consumers should pick the read surface that matches the job.
| Consumer need | Read surface | Notes |
|---|---|---|
| Contract-to-contract pricing | Feed contract or Chainlink-compatible adapter | Use this when another contract needs current on-chain data. |
| API integration | Unified API feed endpoints | Use latest, round, config, and staleness reads for application workflows. |
| Operations and audit review | Asset Console and indexed activity | Use the indexed activity view to review submissions and feed lifecycle changes. |
| Freshness gate | Staleness endpoint | Compare ageSeconds with the maximum age your workflow accepts. |
Related pages
- Submit feed updates explains the API procedure and request payload.
- Read data feeds covers latest, round, config, and staleness reads.
- Feeds system explains the registry, feed types, and adapter model.
- Issuer-signed scalar feed describes the feed primitive and configuration model.
- Signing flow explains the transaction signing path used by feed submissions.
- Chain indexer explains how on-chain events reach DALP's off-chain database.
Compliance Transfer
Step-by-step sequence for how DALP validates token transfers through recipient identity checks, token-specific compliance modules, global compliance policy, and post-transfer state hooks.
Digital Asset Initial Offering
How a DALP Digital Asset Initial Offering models primary distribution through a token sale configuration, investor participation, settlement, refunds, and vesting.