The governed directory selects one active feed for each subject and topic from issuer and aggregator sources, and consumers read it as one series.
Valuation, compliance, and reporting all draw the same governed price, so none of them keeps a private copy of the market that could diverge from the others without anyone noticing.
A subject names what a value belongs to, and a topic names what it means, so the same two keys always resolve to the one feed active for them.
A read through the price resolver against a feed whose last observation has aged past its window is refused rather than served. The scalar-feed adapter and the feed contract return the aged value with its timestamp, so a consumer reading them checks the age itself.
Why price needs a governed source
An institution running tokenised assets needs a price in more places than one moment suggests. A collateral desk marks a position to compute a margin call. A compliance check screens a transfer against a threshold. A fund report values holdings from a net asset value that a feed supplies. Each of these draws from Market Data, and each draws the same value for the same subject and topic at the same moment.
Without a governed source, each of those workflows would keep its own copy of the market, refreshed on its own schedule from whatever source it happened to integrate. Two copies drift the moment their update cadences differ, and a drifted copy is invisible until someone compares two numbers that should have matched and finds they did not. Asset Lifecycle names the general shape of this problem. A programme that runs each stage of an instrument's life in its own system meets a reconciliation at every handoff between those systems, and a reconciliation is where two records that should agree are instead found apart. A private price copy is the same problem for a single number: two records that should agree, maintained apart. An auditor asking which price was official at a given moment gets an answer that depends on which system they asked.
Governance keeps a shared price defensible. The institution, not the platform, decides which issuers or external aggregators it trusts and how long a value may age before the platform treats it as stale. Market Data's job is to hold that decision on chain and serve one answer from it. A shared price then traces back to a source someone chose and can name.
Why this governance runs on the platform, not beside it
The alternative to platform-governed pricing is a market-data terminal or a vendor feed, integrated once by whichever system needs it that quarter. That system picks its own idea of a stale quote, its own retry behaviour when the vendor goes down, and its own storage shape for the number it keeps. Nothing forces it to match the next system that integrates the same vendor differently. An institution running compliance, reporting, custody, and a trading venue behind one platform would then repeat that integration once per consumer, each with its own definition of current.
Market Data closes that gap by sitting inside the same platform as its consumers instead of beside it. Each token has at most one reference market on a Trading Venue, and that market writes its official close to the token's price feed in Market Data when the token has one and its asset class takes its price from a reference market rather than from exchange-rate feeds. A compliance screen or a reporting run reads that same feed for the same subject and topic. The rule that decides when a value is too old to serve is derived once and applies wherever a consumer asks for it, so current means the same thing to every workflow that asks. An institution that wants a different one of its trusted sources to answer changes it in one governed place, and every consumer sees the change at the same moment instead of catching up on its own schedule.
What a subject and topic name
Market Data organises every value it serves under two keys. A subject names what the value belongs to: the zero address for a global series, a token's own address for an asset-specific one. A topic names what the value means, pinned to a schema when its feed is created, so a price and a valuation for the same token are two different feeds even though they share a subject. Platform foreign-exchange feeds use a deterministic address derived from a currency's ISO 4217 numeric code as the subject, with the base and quote currencies recorded in the feed's own description.
Ask for a subject and a topic, and Market Data returns whichever feed the directory holds active for that pair. It never merges two sources into one answer and never asks the caller to choose between them: that choice was already made when the feed was registered.
Running feeds day to day
Operators manage feeds as a set of named slots. For each subject and topic, they register a compatible feed, watch its latest observation, and remove or replace it when the source changes.
Each feed is pinned to one topic and one schema at creation: the schema is that topic's registered encoding signature, the shape a value must take. An update naming a different topic or schema is refused before anything else runs.
A trusted issuer can publish a signed scalar update stating the value, the observation time, an expiry that bounds how long it may be submitted, and the next issuer nonce. The feed then runs its checks in order, starting with that pinned topic and schema, and any one of them failing leaves the last accepted observation exactly where it was.
Ten guards run in order, and the previous observation survives any one of them failing.
A feed built on an external aggregator can be registered in the same directory and selected the same way, since the directory still holds only one active feed for each subject and topic. A scalar-feed adapter, a contract with a fixed address that reads whichever feed is active, lets consumers keep one address while the feed is replaced. Replacement must preserve the feed kind, schema, and decimal precision. Operations can therefore change the source without changing every consumer address, while the registration and update events remain available for reconciliation.
Taking prices from a provider instead of a person
An issuer of regulated bonds or funds usually gets its prices from a custodian, a vendor, or a counterparty. If a person copies each price into a feed, the feed shows who typed the number but not which provider quoted it, and a typo reaches valuations and compliance rules. A price source moves the provider into the governed path: the organisation registers the provider once, maps its ISINs, the 12-character securities identifiers, to token price feeds, and the platform publishes only the prices that pass its checks.
A delivered price becomes an observation that records the ISIN, price, currency, price type, and the provider's observed time. Ordered gates then decide its fate: a repeat is dropped, an observation older than the feed's latest is never moved forward to fit, a currency that differs from the feed's quote currency is rejected, and a price that moved less than the publish threshold is skipped. Every outcome is stored on the observation, so an auditor can see why a provider price never reached the feed as well as why one did.
A price that moved beyond the hold tolerance, or that corrects an earlier price from the same provider, is held for review when the organisation's Prices approval rule is on. Every approval rule starts off. With the Prices rule off, such a price publishes, and the platform records a waived approval for that observation in place of a review. With it on, a feeds manager or the governor of that token approves or rejects it with a wallet verification, and the people who configured the source or queued the delivery cannot. With the rule on, a second person sits between an unusual provider price and a feed that valuations read.
Freshness counts from the provider's observed time, not from the moment the platform published. A late approval therefore cannot make a feed look fresher than the provider's price is. When a mapped feed passes its staleness bound, the platform opens one operations case for that stale episode and names the likely cause, such as a paused source or a held price. The case closes when a fresh price lands.
The platform stores a source's settings and credential and applies the checks, review, and stale alert to any delivery it receives. The platform fetches the deliveries itself: it polls SFTP servers for CSV and reda.001 files, keeps a FIX market data session open to a counterparty, and asks Bloomberg Data License and LSEG DataScope Select for the prices of the source's mapped ISINs at the times the source names. The Bloomberg and LSEG requests follow each vendor's public documentation and are untested against the live services. The routes are in Read and submit price feeds.
Deciding how long a value stays current
Market Data serves one active value for each subject and topic, and a value is only useful while it is recent. The platform enforces that rather than leaving it to each consumer. When a read finds the active feed's observation older than the window that applies, the on-chain price resolver refuses the read with DALP-1111 instead of returning the aged value. That refusal states the subject, the topic, the timestamp of the observation it rejected, and the window it measured against. That is how a consumer tells a stale feed from a subject and topic that has no feed registered at all: the second answers DALP-1022, and no fresh observation fixes it.
One window applies to a read, and it is decided in two layers: a deployment-wide default, and an optional override on a single feed that takes three forms.
Read the effective window for a subject and topic when you need to know what applies. The answer names both the window and the layer that produced it, so an override someone set months ago stays visible rather than inferred.
Choosing how much history a feed keeps
Retention decides how many rounds the feed contract keeps in its own storage, separate from the indexed history the API serves. The platform's issuer-signed feed create flow always uses Latest only and rejects zero or negative observations, so it cannot create a feed for an interest rate or an exchange-rate movement that can cross zero. An externally deployed feed may have different value and retention rules. Registering it does not change those rules.
The platform's create flow does not offer Bounded or Full retention, although the underlying feed contract supports both. Use the indexed API when a consumer needs the history of accepted native observations.
Retention is fixed in each feed contract. A consumer that requires older rounds directly from a contract needs a separately deployed compatible feed with that retention mode. Replacing the directory entry can select that feed if its kind, schema, and decimal precision match. The replacement starts with its own history, while the previous feed's rounds remain readable at its address for as long as it is deployed. Indexed history follows the events both contracts emit.
What the domain covers
Market Data separates three duties: the on-chain directory selects the active feed, each feed contract owns its own accepted observations, and the index follows their events to serve current and historical API views. An API response is an indexed view of on-chain state, not a fresh call to the source.
The directory permits one active entry per key. It verifies that the topic exists, that the feed schema matches the topic, and that a scalar feed exposes the AggregatorV3 interface. Subject zero is global. Any other subject binds the feed to that address. A replacement keeps the same semantic and numeric contract, which protects consumers from a silent unit change.
The directory neither aggregates sources nor derives rates. An external aggregator computes its own answer upstream and publishes it through a compatible feed. Separately, the indexed foreign-exchange graph derives available cross-rates from confirmed currency-pair observations. It retains observation time and history, so a derived rate can still be tied to its underlying market-data series.
Three related values are outside Market Data. A token's own resolved price, and the price history that cascades onto that token's record, are outputs the token domain computes from this domain's feeds, not values Market Data stores as its own. A portfolio's or a system's value history is the same kind of downstream output, owned by the portfolio domain. A trading venue's official close is a number the venue decides from its own trading under the instrument's close methodology. The platform submits it on chain through this domain's submission path. The number stays the venue's, and this domain derives nothing from it.
The integration contract
Developers address Market Data by subject and topic. Feed-management routes register, replace, remove, submit, resolve, and read observations. Exchange-rate routes expose the latest positive observation, configured pairs, supported currencies, and paginated history for an ISO 4217 base and quote pair.
A feed value is a scaled integer. Its decimals define the scale, while its observation timestamp states when the source observed the value. Read both. A successful submission means the signed update passed the feed's authority, replay, time, and value checks and was recorded on-chain. A mutation request that was only accepted by the platform does not prove that the feed changed. Use its transaction outcome and then the indexed feed state.
Consumers that need a stable contract address can use the scalar-feed adapter. It resolves the current feed from the directory on every call and forwards the AggregatorV3 reads. If no scalar feed is registered for that subject and topic, it fails rather than returning a default. An adapter changes only how consumers read the feed. An issuer-signed feed behind an adapter still accepts signed updates from its trusted issuers, and the platform still treats it as issuer-signed. Indexed API reads can lag the chain briefly, so do not treat an immediate missing record after registration as proof that the on-chain slot does not exist.
Match each refusal by its error code. A subject and topic with nothing registered answers DALP-1022. An address that does not answer the AggregatorV3 interface answers DALP-9519, which usually means the address is wrong. An observation timestamp further ahead of chain time than the feed's drift allowance answers DALP-0639. Check the observation timestamp and the signer host's clock before retrying. Price-topic submissions through the feed route require the Feeds manager role and use the organisation's submission signer. Token price operations also expose their own authorisation rules.
Controls and evidence
Market Data separates the authority to select a source from the authority to publish an observation. Feed managers govern directory entries. For issuer-signed feeds, only an issuer trusted for that subject and topic can submit, and the signature must come from a key authorised by that issuer.
A price that comes from a provider adds a review duty. The person who configures a price source cannot approve a price that source held, and the governor of a token can approve a held price only for that token. The raw message behind each source price is kept off chain with its hash, so a reviewer reads what the provider sent.
The feed prevents replay and stale overwrites before state changes. Within a feed, each issuer has its own strictly increasing nonce. An optional deadline bounds submission. Observation time must be present. An observation older than the current one cannot replace it. The platform's native issuer-signed feeds require positive values and allow no future drift from chain time. Other compatible feed contracts may enforce different value and time rules, fixed by their own contracts.
On-chain events record feed registration, replacement, removal, and accepted updates. An accepted signed round records the value, observation time, issuer, and signer. Those events are the durable record, while the configured history mode determines only how many rounds the contract itself keeps in its own storage. The indexed history provides the operational query surface. These records show what the platform accepted, and which trusted issuer and signing key submitted it. They do not prove that the off-chain market observation was economically correct, which remains part of source governance.
Frequently asked questions
Is a topic the same as a currency pair?
No. A topic defines the value's meaning and schema. Platform foreign-exchange feeds use the price topic and a deterministic currency address as the subject. The feed description records the base and quote currencies, such as EUR / USD.
Does replacing a feed change the decimals or scale of values a consumer already read?
No. A replacement is accepted only if it keeps the same feed kind, schema, and decimal precision as the entry it replaces, so a value a consumer already stored keeps the same meaning and scale. What resets is the upstream source and its round history: the new feed contract starts with no rounds of its own, while the previous feed's rounds stay readable at its own address for as long as it remains deployed.
Can more than one issuer publish to the same feed?
Yes. The trusted issuers registry can authorise several issuers for one subject and topic, and the feed accepts a signed update from any of them once its checks pass. Each issuer keeps its own strictly increasing nonce, so issuers never compete over sequence numbers, but the staleness check compares an incoming observation against whichever issuer's update is latest, not against that one issuer's own history. A newer submission from a second issuer can therefore supersede an older one from the first.
What happens if a signed update's nonce falls out of sync?
A submission is refused unless its nonce is exactly one more than the last nonce that issuer had accepted, even when the value and observation time are otherwise valid. The first accepted nonce is 1. Read the issuer's current nonce, sign a new update with the next value, and submit it. Observation time may equal the latest accepted timestamp. An earlier timestamp is rejected.
Does the platform calculate a fund's net asset value?
No. The platform computes no net asset value of its own. A fund share class takes its net asset value per unit from a governed data feed, which a trusted issuer or a configured provider publishes. The fund register, a report of a fund's classes and holders, multiplies each class's feed price by the units held and states the value in the feed's own currency. A class with no feed price has no value there. The “Client asset summary” report first converts the feed price into the organisation's base currency, and it leaves the value empty when the class has no feed price or no exchange rate links the two currencies. With the Primary market add-on, a fund redemption settles at a net asset value that the feed published between 12:00 on the dealing day named in the settlement call and 12:00 on the next dealing day, both in Coordinated Universal Time (UTC). A dealing day is a weekday, Monday to Friday, counted in UTC. Without a net asset value from that window, the platform rejects the settlement call with DALP-14099, and the redemption requests stay open until a net asset value is published and settlement runs again. Fund Dealing covers the dealing rules.
Does a change to the global default window affect a feed that already has its own override?
No. A per-feed override in seconds stays fixed for that feed regardless of what the global default becomes, until someone changes or clears it. Only a feed with no override, or one explicitly set to inherit the global default, picks up a change to that default. Reading the effective window for a subject and topic always shows which layer produced the answer, so an old override never hides behind a number that changed without notice.