# Create feeds Source: https://docs.settlemint.com/docs/developer-guides/feeds/create-feeds Deploy issuer-signed scalar feeds via the factory, create aggregator adapters for stable consumer addresses, and register external feeds in the directory. ## Create an issuer-signed scalar feed [#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 [#prerequisites] Verify the factory is installed: ```bash 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 [#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 [#deploy-the-feed] ```bash 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`: ```bash 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 [#parameters] | Parameter | Type | Required | Description | | -------------------- | ------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------- | | `subject` | address | Yes | The asset or entity this feed relates to | | `topicName` | string | At least one of `topicName` or `topicId` | Human-readable topic name (e.g., "PRICE/USD"). Must be registered in the TopicSchemeRegistry first. | | `topicId` | string | At least one of `topicName` or `topicId` | The keccak256 hash of the topic name, as a decimal string | | `decimals` | number | Yes | Decimal precision for feed values (0--18) | | `description` | string | Yes | Human-readable description of the feed | | `historyMode` | enum | Yes | `LATEST_ONLY`, `BOUNDED`, or `FULL` | | `historySize` | number | Yes | Ring buffer size when using `BOUNDED` mode (ignored for other modes) | | `requirePositive` | boolean | Yes | Reject updates with non-positive values | | `driftAllowance` | number | Yes | Maximum allowed drift in seconds between `observedAt` and block timestamp | | `walletVerification` | object | No (optional for API key auth) | Wallet verification for transaction signing: required for session-based auth only | Response (synchronous, default): ```json { "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: ```json { "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 [#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 [#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`. | Error | Cause | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | `UnauthorizedFeedCreation` | Caller lacks FEEDS\_MANAGER\_ROLE and does not hold GOVERNANCE\_ROLE on the subject token (or subject is address(0) and caller is not a feeds manager) | ## Create an aggregator adapter [#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 [#prerequisites-1] Verify the adapter factory is installed: ```bash curl "$DALP_API_URL/system/feeds/capabilities" \ -H "X-Api-Key: $API_KEY" ``` Check that `scalarFeedAggregatorAdapterFactory.installed` is `true`. ### Deploy the adapter [#deploy-the-adapter] ```bash 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" }' ``` | Parameter | Type | Required | Description | | -------------------- | ------- | ---------------------------------------- | --------------------------------------------------------------------------------- | | `subject` | address | Yes | The asset or entity | | `topicName` | string | At least one of `topicName` or `topicId` | Human-readable topic name | | `topicId` | string | At least one of `topicName` or `topicId` | The keccak256 hash of the topic name | | `walletVerification` | object | No (optional for API key auth) | Wallet verification for transaction signing: required for session-based auth only | Response (synchronous, default): ```json { "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 [#permissions-1] 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. | Error | Cause | | -------------------------- | ----------------------------------------------------------------------------------------- | | `UnauthorizedFeedCreation` | Caller lacks FEEDS\_MANAGER\_ROLE and does not hold GOVERNANCE\_ROLE on the subject token | ## Register an external feed [#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. ```bash 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. | Parameter | Type | Required | Description | | -------------------- | ------- | ---------------------------------------- | --------------------------------------------------------------------------------- | | `subject` | address | Yes | The asset or entity | | `topicName` | string | At least one of `topicName` or `topicId` | Human-readable topic name | | `topicId` | string | At least one of `topicName` or `topicId` | The keccak256 hash of the topic name | | `feedAddress` | address | Yes | The external feed contract address | | `kind` | enum | Yes | Feed kind (`SCALAR`) | | `description` | string | Yes | Human-readable feed description; empty values are rejected | | `walletVerification` | object | No (optional for API key auth) | Wallet verification for transaction signing: required for session-based auth only | Response (synchronous, default): ```json { "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 [#directory-operations] ### Resolve a feed [#resolve-a-feed] Look up the feed registered for a `(subject, topic)` pair. You can use either `topicName` or `topicId`: ```bash curl "$DALP_API_URL/system/feeds/resolve?subject=0xToken&topicName=PRICE/USD" \ -H "X-Api-Key: $API_KEY" ``` Or with `topicId`: ```bash 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 [#replace-a-feed] Swap the feed registered for a `(subject, topic)` pair with a different feed contract: ```bash 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" }' ``` | Parameter | Type | Required | Description | | -------------------- | ------- | ---------------------------------------- | --------------------------------------------------------------------------------- | | `subject` | address | Yes | The asset or entity | | `topicName` | string | At least one of `topicName` or `topicId` | Human-readable topic name | | `topicId` | string | At least one of `topicName` or `topicId` | The keccak256 hash of the topic name | | `newFeedAddress` | address | Yes | The new feed contract address | | `kind` | enum | Yes | Feed kind (`SCALAR`) | | `walletVerification` | object | No (optional for API key auth) | Wallet verification for transaction signing: required for session-based auth only | 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] 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: ```bash 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" }' ``` | Parameter | Type | Required | Description | | -------------------- | ------- | ---------------------------------------- | --------------------------------------------------------------------------------- | | `subject` | address | Yes | The asset or entity | | `topicName` | string | At least one of `topicName` or `topicId` | Human-readable topic name | | `topicId` | string | At least one of `topicName` or `topicId` | The keccak256 hash of the topic name | | `walletVerification` | object | No (optional for API key auth) | Wallet verification for transaction signing: required for session-based auth only | ## Related [#related] * [Data feeds overview](/docs/developer-guides/feeds/overview) * [Submit feed updates](/docs/developer-guides/feeds/submit-updates)