# Market data infrastructure

Source: https://docs.settlemint.com/docs/business/market-data-infrastructure
How DALP market data feeds connect issuer-signed prices, exchange-rate feeds,
directory registration, adapter reads, and token valuation controls.




## Pricing integrity as an operating control [#pricing-integrity-as-an-operating-control]

DALP market data feeds record prices and exchange rates with a clear issuer, a registered subject and topic, a timestamp, and update history. Asset valuations can then use the same registered feed data for compliance checks, redemption calculations, and investor reporting.

Feed contracts and the trust model are covered in [Architecture: Feeds System](/docs/architects/components/infrastructure/feeds-system). API fields and conversion-path responses are covered in [Token price resolution](/docs/api-reference/tokens/token-price-resolution).

## Why this matters in production [#why-this-matters-in-production]

Market data is a control point. A stale, unapproved, or untraceable price can affect NAV, collateral, and reporting workflows, and create reconciliation exposure for redemptions.

DALP gives you registered feed sources and signed update trails, so your review team can see the exact value used and its source feed.

DALP does not choose the economic source of truth. Your institution decides which issuer, oracle, treasury desk, administrator, or provider is approved for each feed. That decision belongs to your programme governance, not to the platform.

<Mermaid
  chart="graph LR
    Issuer[Approved issuer or provider] -->|signed update| ScalarFeed[Issuer-signed scalar feed]
    FeedDirectory[Feeds directory] -->|subject plus topic| ScalarFeed
    FeedDirectory -->|stable pointer| Adapter[Chainlink-compatible adapter]
    ScalarFeed --> PriceResolver[PriceResolver]
    GlobalFX[Global FX feeds] --> PriceResolver
    PriceResolver --> API[Token price API]
    Adapter --> External[External consumers]
    API --> Review[Valuation, redemption, NAV, and reporting review]"
/>

The diagram separates the three control layers. Issuers or providers submit signed values to feeds. The directory decides which feed is active for a subject and topic. Consumers read through the PriceResolver, API, or adapter without treating a screenshot, spreadsheet, or one-off address as the source of truth.

## What DALP provides [#what-dalp-provides]

DALP provides market data through the Feeds system. The model combines issuer-signed feed updates, a feed directory, and Chainlink-compatible adapter contracts for systems that expect the standard aggregator interface.

### Feed registration [#feed-registration]

Feeds are registered by subject and topic. A subject is a token address or a global feed identifier. The topic identifies what the feed represents, such as a price or exchange rate.

### Signed updates [#signed-updates]

Issuer-signed scalar feeds accept EIP-712 signed values from issuers authorised for the feed. Each accepted submission records the signed value together with its observation time, the signer identity, and the full round history.

### Adapter stability [#adapter-stability]

Scalar feed aggregator adapters keep a stable address for consumers. Each adapter resolves the current scalar feed for its subject and topic through the feed directory, then exposes Chainlink-compatible methods such as `latestRoundData()`.

### Operational safeguards [#operational-safeguards]

Feed creation is permissioned. Global feeds require the Feeds Manager role. Token-scoped feeds can also be created by an address with governance authority on that token. Feed updates reject stale observations and observations beyond the configured drift allowance.

### What reviewers can verify [#what-reviewers-can-verify]

Your review team should check the registered feed source before using a price in NAV, redemption, collateral, yield, or reporting workflows. DALP records the feed identity and update history. Your institution decides whether that issuer, oracle, or provider is approved for the asset programme.

| Source evidence           | What DALP records                                                                                                    | What the operator still approves                                                                     |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Issuer-signed scalar feed | Subject, topic, value, observation time, signer, round history, and directory registration                           | Whether the signer and feed topic are approved for the programme                                     |
| Chainlink-compatible feed | Registered proxy or adapter source, latest indexed value, observation time, and consumer-facing aggregator read path | Whether that external oracle is an approved pricing source for the asset                             |
| FX conversion path        | Base currency, requested currency, selected feed hops, and whether a conversion path exists                          | Whether the resulting display currency may be used for investor, NAV, redemption, or reporting views |

If the API returns a base price with `convertible: false`, DALP has not found a usable FX path to the requested currency. Do not treat that as an approved converted price; refresh or register the missing feed before using that currency in downstream controls.

![Asset-scoped feed creation links pricing infrastructure directly to tokenized assets.](/docs/screenshots/real-estate/real-estate-doha-business-towers-create-data-feed.webp)

## Valuation model [#valuation-model]

DALP valuation starts from an indexed token-specific base-price feed.

The feed description carries the price currency, for example `TOKEN / USD`. DALP normalizes the value to 18 decimals before API consumers read it.

If a PriceResolver is active for the token's system, DALP reads the resolver's configured FeedsDirectory, applies its maximum-staleness rule to the base-price feed, and builds FX conversion paths from active global FX feeds in the same directory. Each FX feed adds a direct edge and an inverse edge. DALP chooses the shortest path to the requested display denomination, up to three FX hops, and returns the conversion path in the response.

If DALP finds the base price but cannot find an FX path to the requested display currency, the API returns the base-price denomination with `convertible: false`. Treat that as a feed-setup signal: the token has a price, but the configured FX graph does not connect the base denomination to the requested one.

## Example: base price plus FX conversion [#example-base-price-plus-fx-conversion]

A tokenized real-estate asset can publish its base price as `TOKEN / AED`. The feed update records the issuer, the signed value, and the observation time. When an investor portal requests the token valuation in USD, DALP reads the base-price feed, looks for active global FX feeds in the same directory, and returns both the converted amount and the conversion hops.

If the AED to USD path is missing, the API still returns the AED base price with `convertible: false`. Operations should treat that as market-data setup work. Add or refresh the missing FX feed before using that display denomination in NAV, redemption, or investor-reporting views.

For the API fields, conversion-path response shape, and setup checks, see [Token price resolution](/docs/api-reference/tokens/token-price-resolution).

## Business impact [#business-impact]

| Capability               | Business impact                                                                                      |
| ------------------------ | ---------------------------------------------------------------------------------------------------- |
| Issuer-signed pricing    | Records who authorised a value and when that value was observed                                      |
| Feed registration        | Gives operators one registered source for each subject and topic                                     |
| Base-price resolution    | Lets integrations read the current indexed token price and its source currency                       |
| FX conversion paths      | Shows which feed hops DALP used when converting a token price into another fiat currency             |
| On-chain price history   | Preserves round history for audit, reporting, and reconciliation workflows                           |
| Stable adapter addresses | Lets external systems consume the current registered feed without hardcoding a changing feed address |
| Drift checks             | Rejects stale observations and observations too far in the future                                    |

![Verification settings centralize the authoritative data feed registry.](/docs/screenshots/settings/verification/5-data-feeds.webp)

![Create-feed workflows support new market data sources without breaking consumers.](/docs/screenshots/settings/verification/6-data-feeds.webp)

## Who manages market data [#who-manages-market-data]

The Feeds system uses role-based access control. Feeds Manager can create global feeds and manage feed directory operations. For token-scoped feeds, a token governance authority can also create feeds for that token.

## Regulatory fit [#regulatory-fit]

Reliable pricing records help institutions produce evidence for valuation, NAV, fair-value reporting, and redemption calculations. DALP supplies the technical record: registered feed identity, signed submission provenance, and on-chain round history. Your institution remains responsible for choosing approved sources and meeting its regulatory obligations.

## Related resources [#related-resources]

* [Feeds system architecture](/docs/architects/components/infrastructure/feeds-system): directory model, feed types, and trust boundaries
* [Issuer-Signed Scalar Feed](/docs/architects/components/capabilities/issuer-signed-scalar-feed): signed update format, history modes, and drift allowance
* [Feeds update flow](/docs/architects/flows/feeds-update-flow): validation steps from submission through consumer read
* [Create feeds](/docs/developers/feeds/create-feeds): registering token-scoped and global feeds
* [Token price resolution](/docs/api-reference/tokens/token-price-resolution): API fields and no-path behaviour
* [Feeds overview](/docs/developers/feeds/overview): feed concepts and operating checks
