Signed prices, on-chain

An asset now only acts on a price or value a named party has cryptographically vouched for. Not whatever a public source happened to report at the time.

Data feeds

Trust the signer, not the source

Regulated assets run on off-chain numbers: market prices, FX rates, and collateral valuations. A data feed is the channel that carries those numbers onto the chain where the asset reads them. In DALP 3.0, every feed value carries a cryptographic signature from a named issuer. The asset acts only on figures it can prove came from the right party, at the right time, and have not been tampered with in transit.

Signing

EIP-712

Oracle interface

AggregatorV3

Scope

Per token

Provenance

On-chain

Regulated assets have always needed off-chain numbers: net-asset values from fund administrators, collateral figures from custodians, and FX rates from market-data providers. The question was never whether to bring those numbers on-chain. The hard part is doing it in a way an auditor can verify and a compliance team can defend.

A public price oracle solves the plumbing. It does not solve provenance. Any party that can reach the contract can push a value. Nothing on-chain distinguishes the fund administrator's latest attestation from a stale figure pushed hours ago by a different system. For a regulated instrument, that is not a minor gap. A price the asset uses to compute a redemption, trigger a margin call, or size a fee is a financial input with legal weight. If you cannot prove who produced it and when, you cannot defend the trade it influenced.

Issuer-signed feeds close that gap. The signer's cryptographic identity and the freshness window travel with the figure all the way to the contract. Only a value that passed the issuer's key, within the allowed time window, can move an asset.

How it works

The feed lifecycle is short and verifiable at every step. An issuer creates an EIP-712 typed-data signature over a structured payload: the value, the token it applies to, the topic it covers, and a freshness bound. The platform writes that payload on-chain. The asset contract reads the value, verifies the signature against the declared issuer's registered key, and acts on it only if every check passes. A signature mismatch or an expired window is a hard stop.

1. 1
   Sign

   The issuer produces an EIP-712 typed-data signature over the value, the target token, and a freshness bound. The value is meaningless to the contract without it.

2. 2
   Push

   The signed payload is written on-chain through a single call, or in batch across many tokens at once. No intermediate relay can alter the signed contents.

3. 3
   Verify

   The asset contract recovers the signer address from the signature and checks it matches the declared issuer, and that the value is still within its freshness window.

4. 4
   Act

   Only after verification passes does the asset use the value: as a price, a collateral figure, or an exchange rate. A failed check is a hard stop, not a fallback.

EIP-712 is the Ethereum standard for signing structured, human-readable data. An issuer signs on a hardware key, an HSM, or any signing device and can see exactly what they are attesting to, not just a raw hash. An auditor reading the chain can reconstruct the same verification path without access to any off-chain system.

What the verification checks

The contract runs nine checks on every submitted update, in order. All nine must pass before the value is accepted.

1. The topic ID and schema hash in the signed payload match the values the feed was created with. A feed pinned to a specific topic cannot accept a payload for a different one.
2. The issuer is authorized for that topic on that subject token, according to the on-chain trusted-issuers registry. A party not listed in the registry cannot push, regardless of what key they hold.
3. The signature is valid. For a standard EOA signature, the contract recovers the signer address and checks it holds a claim key on the issuer identity contract. For smart-wallet signers, the same check applies before the EIP-1271 callback is triggered, so only a registered claim-key contract can initiate the external verification call.
4. The nonce is strictly sequential per issuer. Each issuer starts at nonce zero; every accepted update increments it by one. A replay of an old signature fails because its nonce no longer matches.
5. The deadline has not passed, if one was set. A value signed with a deadline is only valid until that timestamp. A value signed without a deadline carries no expiry of its own, but the asset's freshness configuration still applies on read.
6. The value is positive, if the feed was created with that requirement. A zero or negative value from a price feed usually signals a data error; the contract rejects it rather than recording and acting on it.
7. The observation timestamp is not zero. Every update must carry a time when the value was observed, which becomes the startedAt and updatedAt fields in the Chainlink-compatible output.
8. The observation timestamp is not too far in the future. The drift allowance is a configurable window, in seconds, that tolerates clock skew between the issuer's system and the chain. A value timestamped beyond that window is rejected.
9. The observation timestamp is newer than the last accepted one. A feed can only advance; you cannot push a historically backdated figure and have it overwrite a more recent one.

These nine checks run atomically. None silently succeed on partial failure.

History modes

Each feed is created with one of three history modes that controls how much round data is retained on-chain.

LATEST_ONLY stores only the most recent value. It costs the least gas per update and is the right choice for most price feeds, where consumers always want the current value and historical rounds are not needed on-chain.

BOUNDED keeps the last N rounds in a ring buffer, where N is set at feed creation. Once the buffer is full, the oldest round is evicted. This suits feeds where a short audit trail on-chain is useful, such as collateral valuations reviewed on a daily or weekly cycle.

FULL stores every round in an unbounded mapping. Use it only for low-frequency feeds where the full history needs to be queryable from the chain. For high-frequency price feeds, the storage cost compounds quickly.

Why the signature design matters

A price the asset acts on, whether it sets a redemption value, triggers a margin call, or computes a fee, is a financial input with regulatory consequences. For an auditor tracing a disputed trade or a regulator reviewing an instrument's valuation history, "a public feed reported this number at approximately this time" is not a chain of custody. The EIP-712 design gives you one.

The signed payload names the issuer, the target token, the exact value, and the validity window. That signature lives on-chain. An auditor can reconstruct who signed what, over which token, and when, from the ledger alone, without access to any off-chain system. A compromised relay, an unauthorized push, or a figure held past its freshness bound each produce a distinct, detectable failure. None of them silently succeed.

The domain separator in the EIP-712 envelope binds each signature to a specific feed contract address. A valid signature produced for one feed cannot be replayed against a different one. The strict sequential nonce per issuer means that replaying the same signature twice fails on the second attempt, even if the deadline has not yet passed.

Per-token feeds and batch creation

Before this release, price and value inputs were set at the asset level: a single base-price claim applied across all tokens in an instrument. That model has a structural problem. A fund with multiple share classes, or a bond with multiple tranches, carries genuinely different prices per token. A shared base-price claim means every token in the instrument reads the same figure. Representing class A and class B shares pricing independently required separate instruments.

In DALP 3.0, each token holds its own feed, set independently. A fund with multiple share classes or a bond with multiple tranches carries the right figure per token, with no shared-state risk. An update to one token's feed does not touch another.

Adding per-token granularity required batch feed creation to match. Creating dozens of feeds one transaction at a time is not practical for an instrument with many tokens. One batch call handles any number of tokens in a single transaction, and the same nine-step verification applies to every entry in the batch. Per-token and batch are complementary; they were designed together.

Subject-level feeds serve a token or identity contract. FX rate feeds and similar global values serve no single subject and are created with a zero subject address instead, making them readable across instruments without duplication.

Exchange-rate handling

Exchange-rate feeds now retry more intelligently on transient failures and expose their refresh configuration. You can tune the freshness window to match the volatility of the underlying rate without touching platform defaults. Retry behavior is deterministic. A failed refresh does not silently fall back to the last-known rate. It surfaces an error to the platform logs so an operator can act on it.

The practical consequence: an FX feed for a volatile currency pair can be configured with a short freshness window and aggressive retry, while a feed tracking a slowly-moving benchmark rate can use a wider window without generating unnecessary update traffic.

Deployment prechecks

Feed deployment now validates configuration before writing anything on-chain. A misconfigured issuer address, an unsupported token, or a freshness bound the contract would reject all surface at setup time, not after a confusing on-chain revert.

For a large instrument book, that matters. Discovering a misconfiguration after submitting a batch of feed-creation transactions means diagnosing which entries failed, fixing them, and retrying. Catching the same problem before submission means fixing it once.

Together, these improvements move the feed system from prototype to production. Each tranche or share class prices independently. You set up an entire instrument book in one transaction. Freshness tuning is explicit rather than buried in platform defaults, and misconfigurations surface before any on-chain state changes. The migration below is a one-time step. Once complete, every subsequent push carries the full provenance chain automatically.

Built on open signing and feed standards

The issuer-signed feed architecture rests on two Ethereum standards with broad adoption. Choosing open formats over proprietary ones means every signature can be independently verified, and every feed value can be consumed by existing on-chain tooling without a bespoke adapter.

EIP-712 typed data signatures. EIP-712 is the Ethereum standard for signing structured, human-readable data, not opaque byte blobs. When an issuer produces a feed update, they sign a fully typed payload: the numeric value, the target token, the topic it applies to, and a freshness deadline. Because EIP-712 encodes field names and types alongside values, a hardware security module, a browser wallet, or a custodial signing service can show the signer exactly what they are attesting to before the key is used. The same structure is what the asset contract reconstructs on-chain during verification: the recovered signer address is compared against the issuer's registered identity, so the custody chain is entirely on-chain and entirely inspectable. An auditor tracing a disputed valuation needs no access to any off-chain signing system. The typed data hash, the recovered signer, and the verification result are all readable from the ledger. EIP-712 also includes a domain separator that binds each signature to a specific feed contract address, so a valid signature for one feed cannot be replayed against a different one.

Chainlink-compatible price oracle interface. Every feed contract implements AggregatorV3Interface, the five-function surface (decimals, description, version, getRoundData, latestRoundData) that Chainlink established as the de facto price oracle standard. An interoperability choice, not a dependency. No Chainlink infrastructure is required to push or read feed values; the platform supplies and verifies its own signed data. Compatibility gives you access to tooling that already knows how to consume the surface. Smart contracts call latestRoundData(), off-chain dashboards poll decimals() and description(), and monitoring services track round freshness. A feed can be registered anywhere AggregatorV3Interface is accepted, and the values it returns carry the additional guarantee of an EIP-712 typed data signature that plain Chainlink feeds do not.

Together, EIP-712 and AggregatorV3Interface compatibility mean no proprietary lock-in at the protocol level. Issuers sign with widely-used tooling, verifiers check with open cryptography, and downstream consumers read with a broadly-supported interface. The signed-provenance layer sits above all of it, requiring only that a value passed the issuer's key before the asset acts on it.

What this covers

Create data feeds →