Feeds system

Identity, claim topics, and trusted issuers are defined in the claims and identity model.

The Feeds system is the registry and operating model for price and foreign exchange data in DALP. The directory separates feed discovery from feed delivery. Platform workflows, token contracts, APIs, and external integrations can resolve the current feed without hard-coding the underlying source.

Related pages:

• Issuer-Signed Scalar Feed for issuer-attested price data
• Feeds update flow for the feed value lifecycle
• SMART Protocol integration (ERC-3643) for token contracts that consume feeds
• Execution Engine for workflows that use feed data

At a glance

• Feeds provide trusted price and FX data to the platform through a centralized directory
• The FeedsDirectory separates discovery (which feed serves a given subject + topic) from delivery (individual feed contracts)
• Two feed types: issuer-signed scalar feeds (factory-deployed capability) and Chainlink aggregator adapters (infrastructure wrapper)
• Feeds can be global (economy-wide FX rates) or token-specific (asset base prices)
• Only authorized roles can register, replace, or remove feeds

---

What feeds are in DALP

Feeds are on-chain data sources that supply trusted market information, including prices, exchange rates, and valuations, to platform consumers. Each feed is a contract that returns data in a pinned format. The FeedsDirectory maps a (subject, topic) pair to the feed contract address, so consumers never hard-code feed addresses.

When a feed is registered, the directory captures:

---

Price resolution for API consumers

DALP resolves token prices for API reads from the active FeedsDirectory for the token's system. The API first looks for a token-scoped base-price feed. It normalises the value to 18 decimals and checks the PriceResolver staleness policy. Currency conversion uses active global FX feeds in the same directory.

The feed directory is the operating source for API price reads. If a token base-price feed is stale, the API rejects the price read under the active PriceResolver policy. If no conversion path exists for the requested currency, publish the missing feed data first. You can also request a currency that already has an active FX path.

On-chain consumers that use the PriceResolver addon read from the same FeedsDirectory and receive 18-decimal normalised values. External systems that need a Chainlink-style interface can read through the aggregator adapter instead of calling the API.

Where feeds are used

---

Feed types supported

Issuer-signed scalar feed (capability)

A factory-deployed capability where the asset issuer cryptographically signs and publishes price data. Each feed instance is created through a factory contract, following the same pattern as other DALP capabilities (Airdrop, Vault, XvP Settlement, Token Sale).

• Deployment model: factory pattern, one instance per asset or subject
• Data format: fixed-point integer with configurable decimals
• Key properties: history modes (latest-only, bounded, full), drift allowance, positive-value requirement, signature verification

See Issuer-Signed Scalar Feed for configuration, signing model, and value format details.

Chainlink aggregator adapter (infrastructure)

A wrapper contract that presents any DALP feed through the AggregatorV3Interface, the de facto standard consumed by DeFi protocols, lending platforms, and external analytics tools.

Why it exists: External integrations need a stable address. Feed replacement does not change the adapter address. The adapter resolves the current feed from the FeedsDirectory on every call. Consumers do not need to update their pointers.

Use cases: DeFi protocol integration, cross-platform data sharing, portfolio valuation by external trackers, oracle aggregation, audit and compliance feeds for external systems.

---

Trust model & boundaries

• Feed registration is a privileged operation because unauthorized changes to pricing data could affect compliance decisions and valuations
• Schema hash pinning ensures consumers always know the expected data format; format changes require explicit feed replacement
• Global feeds, including address-zero subjects and deterministic currency-code subjects for FX data, can only be managed by the Feeds Manager, not by individual token governance roles

---

Operational model

Signals

• Feed registered / replaced / removed: directory events indexed by the chain indexer
• Value updated: feed-level events (issuer-signed feeds emit on each signed update)
• Outlier flagged: drift allowance exceeded on an issuer-signed feed

Deployment prerequisites

System and organisation deployment workflows prepare feed infrastructure before they create exchange-rate feeds. Each workflow registers the shared price topic, deploys the issuer-signed scalar feed factory, resolves the factory address, and waits for the indexer to make prior deployment events visible before continuing.

These steps are safe to repeat. If the topic already exists, the workflow continues. If the feed factory is already registered on-chain, DALP recovers the existing factory from indexed registry events instead of creating a duplicate. Temporary RPC, transport, or indexer visibility failures remain retryable so the workflow can resume once the dependency catches up.

Exchange rate refresh

DALP refreshes active FX feeds from the configured exchange rate provider on a recurring schedule. The refresh cycle groups active feeds by base currency, fetches one provider payload for each base, and submits validated rates in batches. Provider response keys are normalised to uppercase ISO currency codes before submission.

Production FX feeds are global platform data even when the feed subject is a deterministic ISO 4217 currency-code address rather than address zero. The indexer and currency-conversion graph use that scope to pick up active FX pairs separately from per-asset price feeds.

The refresh scheduler starts for every enabled network when exchange-rate auto-refresh is enabled. Operators can disable automatic refreshes or set the refresh interval in the exchangeRates configuration block. The interval accepts duration values such as 30m, 6h, or 1d, with a minimum of five minutes and a default of six hours.

The provider fetch uses a primary endpoint with a fallback mirror. The scheduler retries transient provider, network, timeout, and payload-shape failures with backoff. A base currency rejected by both endpoints as not found is treated as a permanent provider rejection for that cycle, so the scheduler logs the issue and waits for the next scheduled refresh instead of spending the retry budget on an unsupported base.

The refresh cycle does not submit a new on-chain value when the provider timestamp for that base has not changed. Timestamps are tracked per base currency, so a failed EUR refresh does not block USD, and a successful USD refresh does not suppress a later EUR retry.

Before submission, DALP drops missing quote currencies and rates that are zero, negative, non-finite, or outside the configured sanity bounds. If every feed for a base fails validation, the scheduler keeps that base eligible for the next refresh instead of advancing its stored timestamp.

Failure modes

See Feeds update flow for the full lifecycle including validation checkpoints and recovery.

---

Dependencies

On-chain:

• FeedsDirectory contract (central registry)
• Factory contracts (deploy issuer-signed feed and adapter instances)
• Token contracts (subjects for token-specific feeds)

Off-chain:

• Chain indexer (indexes directory and feed events for the platform UI and API)
• Execution Engine (orchestrates workflows that consume feed data)

---

See also

• Issuer-Signed Scalar Feed for configuration, signing model, and value format
• Feeds update flow for the feed value update lifecycle
• Compliance modules for how feeds support compliance checks