Issuer-Signed Scalar Feed

Purpose: Describe the Issuer-Signed Scalar Feed capability — how issuers attest to price data on-chain through a factory-deployed feed contract with signature verification, history modes, and drift protection.

• Doc type: Explanation
• What you'll find here:
  • Factory deployment model and lifecycle
  • Configuration surface: history modes, drift allowance, decimals
  • Cryptographic signing model and verification
  • Fixed-point value format
  • Integration with FeedsDirectory for discovery
• Related:
  • Feeds system — central registry and feed types overview
  • Feeds update flow — end-to-end lifecycle of publishing feed values
  • Capabilities overview — factory pattern used by all capabilities

At a glance

• Asset issuers cryptographically sign price values, providing direct attestation of authenticity
• Deployed through the factory pattern — one feed instance per asset or subject, same model as Airdrop, Vault, XvP Settlement, and Token Sale
• Three history modes control how much historical data is retained on-chain
• Drift allowance protects against anomalous price reports by limiting value changes between updates
• All values must be positive and use fixed-point integer representation with configurable decimals

Configuration

Each issuer-signed scalar feed instance is configured at deployment. Parameters are immutable after creation.

History modes

Latest-only — Stores only the most recent signed value. Minimizes storage cost. Suitable when only current pricing matters.

Bounded — Retains a configured number of recent values. Enables recent history queries for verification or trend analysis. Older values are pruned automatically when the limit is reached.

Full — Maintains the complete history of all signed values. Provides maximum transparency and full audit trails. Use when historical verification is a regulatory or operational requirement.

Signing model

Each update requires a cryptographic attestation from the authorized issuer. The feed contract verifies the signature on-chain before accepting the value.

A signed update includes:

Verification: The feed contract recovers the signer from the signature and checks it matches the authorized issuer address. If the signature is invalid or from an unauthorized address, the update is rejected on-chain.

Non-repudiation: Because the issuer's private key produced the signature, the issuer cannot deny having attested to that value at that timestamp. Applications and auditors can independently verify any historical signed value.

Value format

Values use fixed-point integer representation to avoid floating-point ambiguity.

The decimal count is fixed per feed instance and determines how to interpret the stored integer:

stored_value ÷ 10^decimals = human-readable price

Example: A price of 150.00 EUR with decimals = 2 is stored as 15000 (since 15000 ÷ 10² = 150.00).

This ensures:

• Consistent precision across all values for a given feed
• No floating-point rounding errors
• Unambiguous interpretation by all consumers

Integration with FeedsDirectory

Issuer-signed scalar feeds register in the FeedsDirectory like any other feed type. The directory maps a (subject, topic) pair to the feed contract address.

Registration flow:

1. Factory contract deploys a new feed instance with the configured parameters
2. Feed is registered in the FeedsDirectory with subject, topic, feed address, kind (scalar), and schema hash
3. Consumers discover the feed by querying the directory with the same subject + topic

Consumer read path:

1. Consumer queries FeedsDirectory with (subject, topic)
2. Directory returns the feed contract address
3. Consumer calls the feed contract to retrieve the current signed value, signature, timestamp, and sequence number

The directory indirection means the underlying feed can be replaced (e.g. upgraded to a new implementation) without consumers changing their code.

See also

• Feeds system — central registry, Chainlink adapter, trust model
• Feeds update flow — step-by-step lifecycle including validation checkpoints
• Capabilities overview — factory deployment pattern shared by all capabilities