Create feeds

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 either a human-readable topicName string, a topicId hash, or both. When topicName is provided, the on-chain topicId is computed internally. When both are provided, the API verifies they match.

Deploy the feed

curl -X POST "$DALP_API_URL/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/system/feeds/issuer-signed/create" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "0xTokenAddress",
    "topicId": "109530253152918849413157129862927938307097811649912148858507112538040816216783",
    "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": "0x...",
    "decimals": 8,
    "historyMode": "BOUNDED",
    "transactionHash": "0x..."
  },
  "meta": { "txHashes": ["0x..."] },
  "links": { "self": "/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/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": "0x...",
    "transactionHash": "0x..."
  },
  "meta": { "txHashes": ["0x..."] },
  "links": { "self": "/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/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 two things: the contract exposes the feed shape your consumer expects, and the selected topic describes the value the feed returns.

Response (synchronous, default):

{
  "data": {
    "subject": "0xTokenAddress",
    "topicId": "109530253152918849413157129862927938307097811649912148858507112538040816216783",
    "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=109530253..." \
  -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"
  }'

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. The replacement feed must use the same kind, schema hash, and decimals as the previous feed.

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"
  }'

Related

• Data feeds overview
• Submit feed updates