Feeds system
The Feeds system provides reliable, system-guaranteed price and foreign exchange data for digital assets through a centralized directory with multiple feed types and subject scopes.
Purpose: Central hub for understanding how price and foreign exchange data flows through DALP — the registry, supported feed types, trust model, and operational boundaries.
- Doc type: Explanation
- What you'll find here:
- FeedsDirectory as central registry and discovery layer
- Feed types supported: issuer-signed scalar and Chainlink aggregator adapter
- Where feeds are consumed across the platform
- Trust model and access control boundaries
- Operational model and failure signals
- Related:
- Issuer-Signed Scalar Feed — factory-deployed capability for issuer-attested price data
- Feeds update flow — end-to-end lifecycle of publishing and updating feed values
- SMART Protocol integration (ERC-3643) — token contracts that consume feeds
- Execution Engine — workflows that incorporate 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 — 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:
| Field | Description |
|---|---|
| Subject | Token address or global subject (address zero) for economy-wide data |
| Topic | Data type the feed provides (base price, FX rate) |
| Feed contract | Address applications query for data |
| Feed kind | Scalar (numeric) or bytes (structured) |
| Schema hash | Pins the expected data format for consistency |
Where feeds are used
| Consumer | Purpose | Failure impact |
|---|---|---|
| Compliance modules | Limit checks and valuation requirements | Transfer blocked if feed stale or missing |
| Yield / distribution | Determine distribution amounts based on current prices | Distribution delayed or calculated on stale values |
| Asset Console | Display current portfolio value in preferred currency | UI shows outdated valuations |
| Execution Engine | Incorporate feed data into multi-step workflows | Workflow paused pending fresh data |
| External DeFi protocols | Consume prices via Chainlink-compatible adapter interface | Integration returns stale round data |
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. If the underlying feed is replaced (new provider, upgraded contract), the adapter address stays the same. The adapter resolves the current feed from the FeedsDirectory on every call, so consumers never need to update their pointers.
| Property | Detail |
|---|---|
| Interface | Chainlink AggregatorV3Interface (latestRoundData, decimals, description) |
| Address stability | Permanent — survives feed replacement in the directory |
| Resolution | Dynamic — queries FeedsDirectory per call for current feed address |
| Configuration | Subject + topic pair (same mapping as the directory) |
| Deployment | One adapter per (subject, topic) combination |
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
| Action | Who can do it | Scope |
|---|---|---|
| Register / replace / remove feed | Feeds Manager role (system-level) | Any subject, including global feeds |
| Create feed + adapter | GOVERNANCE role holder on a specific DALP token | That token only (not global feeds) |
| Read feed data | Any contract or off-chain caller | Unrestricted |
- Feed registration is a privileged operation — 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 (address zero subject) 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
Failure modes
| Failure | System behavior |
|---|---|
| Feed stale (no updates) | Consumers read last-known value; compliance may block |
| Feed removed from directory | Discovery returns zero address; consumers must handle |
| Invalid signature | Issuer-signed feed rejects the update on-chain |
| Drift exceeded | Value flagged as outlier; consumers decide risk tolerance |
| Adapter target missing | Adapter call reverts; external integrations see failure |
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 — configuration, signing model, value format
- Feeds update flow — end-to-end lifecycle of feed value updates
- Compliance modules — how feeds support compliance checks
EVM RPC Node
The EVM RPC Node provides the direct interface to blockchain networks, handling JSON-RPC requests for transaction submission, state queries, and event subscription across public and private EVM-compatible chains.
Asset Contracts
DALPAsset is the recommended contract type for all new tokenization projects. Configure token features and compliance modules per instrument. Specialized types remain supported for existing deployments.