Feeds overview

Feeds give DALP a registry-backed way to resolve numeric data by asset and topic. A feed belongs to a (subject, topicName) pair: the subject is the asset or entity address, and the topic name describes the value, such as NAV or PRICE/USD. The API computes the on-chain topicId hash from the topic name.

Use feeds when DALP workflows, contracts, or external consumers need the same governed data point to be discoverable on-chain. The directory maps each subject and topic to a current feed address. Issuer-signed feeds let trusted issuers submit values through DALP-managed EIP-712 signing. External feeds let you register an existing scalar feed contract while its lifecycle and source operations stay outside DALP.

What feeds cover

Feeds are not a market-data provider by themselves. DALP uses feeds to register, resolve, and read scalar values from an authorised source. Issuer-signed feeds also let DALP submit signed updates to the feed contract.

Operating model

1. Install the feed modules for the system.
2. Create or register a feed for a subject and topic.
3. Submit values to issuer-signed feeds, or let the external feed continue updating outside DALP.
4. Resolve and read the feed through the API, CLI, adapter, or indexed data.
5. Replace or remove the directory mapping when the operating source changes.

Key concepts

Feed types

Issuer-signed scalar feeds are deployed through the IssuerSignedScalarFeedFactory addon. DALP prepares the typed data and submits the update. The feed contract verifies the issuer signature, nonce, and trusted-issuer configuration before storing the round.

External feeds are existing scalar feed contracts registered in the directory. DALP can resolve and read the registered address, but the external feed keeps its own update schedule, permissions, service levels, and source controls.

Aggregator adapters provide a stable contract address for consumers. The adapter resolves the current feed for a subject and topic, then exposes read methods such as latestRoundData(). Use an adapter when a consumer should not change address every time the underlying feed is replaced.

History modes

Choose LATEST_ONLY when only the current value matters. Use BOUNDED when consumers need a recent window. Use FULL only when the feed needs a complete on-chain value history and the storage cost is acceptable.

Indexed feed model

DALP indexes feeds from feed lifecycle events. The indexed feed row follows the directory entry for a (subject, topicId) pair. It stores the latest answer from the active feed source, so API reads, CLI reads, and list pages stay aligned with the on-chain directory after a replacement.

DALP-managed feeds and Chainlink-compatible feeds are indexed differently because each model exposes different operational data. DALP-managed issuer-signed feeds carry platform metadata, issuer trust configuration, and signed-update fields. Chainlink-compatible feeds keep their external operating model. DALP records the directory mapping, decimals, description, active source, and underlying aggregator when the feed uses a proxy.

Replacement and removal behaviour

The directory entry is the operator-facing source of truth for a subject and topic. Replacing a feed changes the active feed address behind that entry. The subject, topic, and adapter address stay stable. Consumers that read through an aggregator adapter keep the same configuration and resolve the new underlying feed on the next read.

After replacement, DALP clears the cached latest answer for that indexed mapping. The next FeedUpdated or AnswerUpdated event from the new source repopulates the latest value. Treat the value as unavailable until the replacement source emits an update or your integration reads the new source directly.

Removing a feed deletes the directory mapping on-chain and marks the indexed mapping inactive. API list calls can still show inactive history when requested, but resolve calls for the removed (subject, topic) no longer return an active feed.

Capability check

Before creating, submitting, or reading feeds, verify which feed modules are installed:

curl "$DALP_API_URL/system/feeds/capabilities" \
  -H "X-Api-Key: $API_KEY"

The response reports the chain ID, supported feed kinds, and installation state for the FeedsDirectory, IssuerSignedScalarFeedFactory, and ScalarFeedAggregatorAdapterFactory. A capability can be absent on a system where the corresponding addon has not been installed or indexed yet.

Operational checks

Next steps