Create feeds

Create a feed when an asset, identity, or global subject needs a registered scalar value source. DALP can deploy an issuer-signed feed, deploy an adapter for an existing feed, or register an external feed address against a subject and topic. This how-to covers the write operations and their request fields. Use Read feed data for listing, resolving, and reading feed state. Use Submit feed updates to publish issuer-signed values after creation.

Choose the creation path

All three paths identify a feed by subject plus either topicName, topicId, or both. When both topic values are present, DALP verifies that they match before submitting the transaction.

Create an issuer-signed scalar feed

Issuer-signed feeds are deployed via the IssuerSignedScalarFeedFactory addon. Updates are authorized through EIP-712 typed data signatures from trusted issuers.

Prerequisites

Verify the factory is installed:

curl "$DALP_API_URL/system/feeds/capabilities" \
  -H "X-Api-Key: $API_KEY"

Check that issuerSignedScalarFeedFactory.installed is true in the response. DALP prepares the shared price topic and issuer-signed scalar feed factory during system and organization deployment. If the capability is not installed yet, finish the platform setup or deployment flow first, then rerun the capabilities check before creating issuer-signed feeds.

The deployment flow is safe to rerun. When the price topic or feed factory already exists, DALP reuses the existing registration instead of creating a duplicate. On a fresh deployment, DALP resolves the new factory from the registry confirmation first. If that receipt-based resolution does not return the factory address, DALP waits for the platform's indexed contract view and resolves the factory there as a fallback. Deterministic configuration or authorization failures fail the setup step; transient network, RPC, or indexing delays are retried by the deployment workflow.

Register a topic

Before creating a feed, register the topic name in the TopicSchemeRegistry. The API accepts a human-readable topicName string, a numeric-string topicId, or both. The platform resolves the topic internally when topicName is provided. The API verifies the pair when both are provided.

Deploy the feed

curl -X POST "$DALP_API_URL/api/v2/system/feeds/issuer-signed/create" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "0xTokenAddress",
    "topicName": "PRICE/USD",
    "decimals": 8,
    "description": "USD price feed for token",
    "historyMode": "BOUNDED",
    "historySize": 100,
    "requirePositive": true,
    "driftAllowance": 0
  }'

You can also use topicId instead of topicName:

curl -X POST "$DALP_API_URL/api/v2/system/feeds/issuer-signed/create" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "0xTokenAddress",
    "topicId": "34863197551733743334059487215836987194269220601176631527793553872548695494516",
    "decimals": 8,
    "description": "USD price feed for token",
    "historyMode": "BOUNDED",
    "historySize": 100,
    "requirePositive": true,
    "driftAllowance": 0
  }'

Parameters

Response (synchronous, default):

{
  "data": {
    "feedAddress": "0x...",
    "subject": "0x...",
    "topicId": "34863197551733743334059487215836987194269220601176631527793553872548695494516",
    "decimals": 8,
    "historyMode": "BOUNDED",
    "transactionHash": "0x..."
  },
  "meta": { "txHashes": ["0x..."] },
  "links": { "self": "/v2/system/feeds/issuer-signed/create" }
}

To request asynchronous processing, add Prefer: respond-async to the request headers. The server returns HTTP 202 with a status URL for polling:

{
  "transactionId": "01965a1b-...",
  "status": "pending",
  "statusUrl": "/transactions/01965a1b-..."
}

Poll the statusUrl until status changes to "completed" or "failed".

The feed is automatically registered in the FeedsDirectory upon creation. DALP indexes the factory creation event and directory registration event together, so the indexed feed includes the subject, topic, decimals, description, history mode, signing domain, issuer registries, and active directory mapping after indexing catches up.

Create several feeds in one factory transaction

Direct contract integrations can call batchCreate on IssuerSignedScalarFeedFactory. Use it when all feeds should be created together or none should be created.

batchCreate accepts an array of BatchEntry values. Each entry uses the same feed fields as the single-feed create call. Encode the contract struct in this order:

1. subject
2. historySize
3. decimals
4. requirePositive
5. topicId
6. driftAllowance
7. historyMode
8. description

Important behavior:

• The entries array must contain at least one item. An empty array reverts with EmptyBatch.
• Entries are processed in input order.
• The call is atomic: if authorization, deployment, or directory registration fails for one entry, the whole transaction reverts.
• The factory emits one FeedCreated event per created feed, in the same order as the input entries.
• Authorization is checked for each entry with the same rules as single-feed creation.

The public API create route remains the single-feed interface. Use the contract-level batch call only when your integration is submitting a factory transaction directly.

Permissions

Feed creation supports two authorization paths:

1. Feeds Manager role (system-level): can create feeds for any subject including global (address(0)).
2. Governance role on subject token: holders of the GOVERNANCE role on a specific DALP token can create feeds for that token, provided the token supports the ISMART and ISMARTTokenAccessManaged interfaces. Does not apply to global feeds.

If neither condition is met, the factory reverts with UnauthorizedFeedCreation.

Create an aggregator adapter

Adapters are stable-address proxies that resolve to the current underlying feed for a (subject, topic) pair. Consumers point at the adapter address instead of the feed directly. When you replace the underlying feed, the adapter automatically resolves to the new feed without consumers changing their configuration.

Prerequisites

Verify the adapter factory is installed:

curl "$DALP_API_URL/system/feeds/capabilities" \
  -H "X-Api-Key: $API_KEY"

Check that scalarFeedAggregatorAdapterFactory.installed is true.

Deploy the adapter

curl -X POST "$DALP_API_URL/api/v2/system/feeds/adapters/create" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "0xTokenAddress",
    "topicName": "PRICE/USD"
  }'

Response (synchronous, default):

{
  "data": {
    "adapterAddress": "0x...",
    "subject": "0x...",
    "topicId": "34863197551733743334059487215836987194269220601176631527793553872548695494516",
    "transactionHash": "0x..."
  },
  "meta": { "txHashes": ["0x..."] },
  "links": { "self": "/v2/system/feeds/adapters/create" }
}

Add Prefer: respond-async for asynchronous processing (HTTP 202 with statusUrl for polling).

Permissions

Adapter creation follows the same two-path authorization as feed creation:

1. Feeds Manager role (system-level): can create adapters for any subject including global (address(0)).
2. Governance role on subject token: can create adapters for their specific token. Does not apply to global subjects.

Register an external feed

Register an existing feed contract, such as a Chainlink-compatible price feed, in the directory. The registered feed becomes discoverable through the same (subject, topic) lookup as platform-managed feeds. DALP stores the directory mapping and read metadata for external feeds. The external provider still owns update permissions, source controls, monitoring, and service levels.

curl -X POST "$DALP_API_URL/api/v2/system/feeds/register-external" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "0xTokenAddress",
    "topicName": "PRICE/USD",
    "feedAddress": "0xExternalFeedContract",
    "kind": "SCALAR",
    "description": "Chainlink-compatible USD price feed for this token"
  }'

External feed registration writes a directory mapping. It does not deploy the feed, update the external contract, or monitor the external provider. Before registering the address, verify the contract exposes the feed shape your consumer expects. Also verify the selected topic describes the value the feed returns.

Response (synchronous, default):

{
  "data": {
    "subject": "0xTokenAddress",
    "topicId": "34863197551733743334059487215836987194269220601176631527793553872548695494516",
    "feedAddress": "0xExternalFeedContract",
    "kind": "SCALAR",
    "transactionHash": "0x..."
  },
  "meta": { "txHashes": ["0x..."] },
  "links": { "self": "/v2/system/feeds/register-external" }
}

Add Prefer: respond-async for asynchronous processing. The server queues the registerFeed transaction and returns a status URL for polling.

Directory operations

Resolve a feed

Look up the feed registered for a (subject, topic) pair. You can use either topicName or topicId:

curl "$DALP_API_URL/system/feeds/resolve?subject=0xToken&topicName=PRICE/USD" \
  -H "X-Api-Key: $API_KEY"

Or with topicId:

curl "$DALP_API_URL/system/feeds/resolve?subject=0xToken&topicId=34863197551733743334059487215836987194269220601176631527793553872548695494516" \
  -H "X-Api-Key: $API_KEY"

Returns the feed address, kind, schema hash, adapter address (if one exists), and indexed data from DIDX.

Replace a feed

Swap the feed registered for a (subject, topic) pair with a different feed contract:

curl -X PUT "$DALP_API_URL/system/feeds/replace" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "0xTokenAddress",
    "topicName": "PRICE/USD",
    "newFeedAddress": "0xNewFeedContract",
    "kind": "SCALAR",
    "description": "Chainlink-compatible USD price feed for this token"
  }'

If an aggregator adapter exists for this (subject, topic), the adapter resolves to the new feed. Replacement keeps the subject, topic, and adapter address stable. DALP clears the indexed latest answer until the new feed emits its next update. Use replacement when only the registered feed address changes. The replacement feed must use the same kind, schema hash, and decimals as the previous feed. DALP rejects mismatches with KindMismatch, SchemaHashMismatch, or DecimalMismatch. Keep the value semantics and description aligned with the previous mapping so consumers do not reinterpret the adapter output.

Remove a feed

Remove a feed registration from the directory. Removal deactivates the mapping for this subject and topic. Consumers that resolve through the directory no longer get an active feed for the pair. DALP clears cached token price data when the removed mapping was used as a price feed.

curl -X DELETE "$DALP_API_URL/system/feeds/remove" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "0xTokenAddress",
    "topicName": "PRICE/USD"
  }'

Operational notes

• External registration and replacement require a non-empty description. Use the description to preserve feed semantics for auditors and downstream readers.
• kind currently accepts SCALAR. Do not pass other feed kinds unless your route schema exposes them.
• Mutation responses include transactionHash. Store it with the system actor and request ID. Operations teams can use those records to reconcile the API write with chain activity.
• Feed creation and directory writes do not prove that a value is fresh. Read the feed after creation or replacement and inspect the indexed latestValue fields before relying on the feed in a production workflow.

Related

• Data feeds overview
• Read feed data
• Submit feed updates