# Submit updates

Source: https://docs.settlemint.com/docs/developers/feeds/submit-updates
Submit issuer-signed feed updates through DALP. Resolve issuer identity,
check nonces, send values, and verify freshness before consuming a feed.




A feed update publishes a new issuer-signed scalar value for a registered feed. Submit the value, and the platform resolves the issuer identity for the feed topic. Check the latest round before your consumers depend on it.

## How signed updates work [#how-signed-updates-work]

DALP signs and submits a feed update for the identity authorised for the feed topic. The feed contract validates the issuer identity, signer key purpose, and nonce. It then checks the timestamp and deadline against feed value rules before storing a new round.

Authority resolution depends on the feed topic. The following table shows who can submit and which signing identity the platform uses.

| Feed topic   | Who can submit                                                                         | Issuer identity used for signing    |
| ------------ | -------------------------------------------------------------------------------------- | ----------------------------------- |
| Price topic  | A caller with the `feedsManager` system role                                           | The organisation OnchainID identity |
| Other topics | A user whose OnchainID identity is registered as a trusted issuer for the feed's topic | The user's OnchainID identity       |

`issuerIdentity` is the OnchainID contract address for the issuer, not the EOA wallet address. The field appears in nonce requests and submit responses.

## Prerequisites [#prerequisites]

Before submitting feed updates:

1. Confirm the feed is registered and indexed.
2. Confirm the caller is authorised for the feed topic.
3. Know the feed's decimal precision so you can encode the value at the correct magnitude.
4. Read the current nonce for the issuer identity that DALP will use for the topic.

## Get the current nonce [#get-the-current-nonce]

Read the nonce for the signing identity on the target feed. For price-topic feeds, use the organisation OnchainID address. For other topics, use the trusted issuer user's OnchainID address.

```bash
curl "$DALP_API_URL/system/feeds/0xFeed/nonce/0xIdentityContract" \
  -H "X-Api-Key: $API_KEY"
```

Response:

```json
{
  "feedAddress": "0x...",
  "issuerIdentity": "0x...",
  "currentNonce": "5",
  "nextNonce": "6"
}
```

Use `nextNonce` to find the next strict sequential value the feed contract expects for that issuer. The nonce endpoint reads the feed contract directly and returns the on-chain count plus the next expected number. DALP derives the nonce during submission, so the request body omits the `nonce` field.

## Submit an update [#submit-an-update]

Submit the encoded value and observation timestamp to the feed. When the transaction completes synchronously, the API returns the submitted value, nonce, transaction metadata, and response link:

```bash
curl -X POST "$DALP_API_URL/system/feeds/0xFeed/submit" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "value": "150000000",
    "observedAt": 1700000000,
    "deadline": 0
  }'
```

Specify the feed address in the URL path. DALP resolves the signing identity from the feed topic and the authenticated context. For price-topic feeds, DALP uses the organisation identity when the caller has the `feedsManager` system role. For non-price topics, DALP uses the authenticated user's OnchainID identity when it is a trusted issuer for the topic.

If you are updating a token price, prefer the token price endpoint. It applies the token-level `setPrice` permission, resolves or creates the feed, and sends the update with the organisation issuer identity.

### Parameters [#parameters]

| Parameter            | Type   | Description                                                                                                                                                                             |
| -------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `value`              | string | New value as an integer string, expressed in the feed's `decimals` units. A feed with `requirePositive: true` rejects zero and negative values.                                         |
| `observedAt`         | number | Unix timestamp when the value was observed. It must be non-zero and not older than the latest accepted observation. The feed also rejects observations that exceed its drift allowance. |
| `deadline`           | number | Optional Unix timestamp after which the update is rejected. `0` means no deadline.                                                                                                      |
| `walletVerification` | object | Optional for API key auth. Wallet verification for transaction signing when session-based authentication requires it.                                                                   |

Response:

```json
{
  "data": {
    "transactionHash": "0x...",
    "feedAddress": "0x...",
    "value": "150000000",
    "nonce": "6"
  },
  "meta": {
    "txHashes": ["0x..."]
  },
  "links": {
    "self": "/v2/system/feeds/0xFeed/submit"
  }
}
```

<Callout type="info" title="Value encoding">
  Values are encoded as integer strings using the feed's decimal precision. For a feed with `decimals: 8`, a value of `1.50`
  is submitted as `"150000000"`.
</Callout>

<Callout type="info" title="Token prices use the token price route">
  To update a token price, use the dedicated endpoint unless you specifically need the generic feed submission route. That
  route applies the token-level `setPrice` permission, resolves or creates the price feed, and sends the update with the
  organisation issuer identity.
</Callout>

## Submit flow [#submit-flow]

<Mermaid
  chart="`
sequenceDiagram
  participant Client
  participant API as DALP API
  participant Chain as On-chain feed

  Client->>API: GET /system/feeds/{feedAddress}/nonce/{issuerIdentity}
  API-->>Client: currentNonce and nextNonce

  Client->>API: POST /system/feeds/{feedAddress}/submit
  API->>API: Resolve feed topic, signer, and issuer identity
  API->>Chain: Submit signed update
  Chain->>Chain: Verify issuer, signer, nonce, timestamp, deadline, and value rules
  Chain-->>API: transactionHash, value, and nonce
  API-->>Client: Submission result

`"
/>

A successful submit stores one new round for the feed. Contract rejection on any field (issuer, signer, nonce, timestamp, deadline, or value) causes the Platform API to return an error. No new round is recorded.

## Read feed configuration [#read-feed-configuration]

Before submitting, query the feed configuration to confirm the `decimals` precision, the `requirePositive` constraint, and the `driftAllowance`. These values are fixed at registration and determine whether the platform accepts your update.

```bash
curl "$DALP_API_URL/system/feeds/0xFeed/config" \
  -H "X-Api-Key: $API_KEY"
```

Response:

```json
{
  "feedAddress": "0x...",
  "subject": "0x...",
  "topicId": "0x...",
  "expectedSchemaHash": "0x...",
  "decimals": 8,
  "description": "USD price feed",
  "historyMode": "BOUNDED",
  "historySize": 100,
  "requirePositive": true,
  "driftAllowance": 300,
  "domainSeparator": "0x...",
  "trustedIssuersRegistry": "0x...",
  "topicSchemeRegistry": "0x..."
}
```

Key fields:

| Field             | Description                                                             |
| ----------------- | ----------------------------------------------------------------------- |
| `decimals`        | Decimal precision for encoding values.                                  |
| `description`     | Human-readable feed description.                                        |
| `historyMode`     | How historical rounds are stored.                                       |
| `historySize`     | Ring buffer size for `BOUNDED` mode.                                    |
| `requirePositive` | Whether zero and negative values are rejected.                          |
| `driftAllowance`  | Feed validation setting used when the contract checks submitted values. |

## Check staleness [#check-staleness]

Consumers that use the feed to value collateral, price settlement, or run reserve checks must verify the value is recent before acting on it. Call the staleness endpoint with your acceptable age threshold, and reject any feed whose `isStale` field returns `true`.

```bash
curl "$DALP_API_URL/system/feeds/0xFeed/staleness?maxAgeSeconds=3600" \
  -H "X-Api-Key: $API_KEY"
```

Response:

```json
{
  "feedAddress": "0x...",
  "latestUpdatedAt": "2023-11-14T22:13:20.000Z",
  "currentTimestamp": "2023-11-14T23:11:40.000Z",
  "ageSeconds": 3500,
  "maxAgeSeconds": 3600,
  "isStale": false,
  "roundId": "6",
  "answer": "150000000"
}
```

| Field              | Description                                                 |
| ------------------ | ----------------------------------------------------------- |
| `latestUpdatedAt`  | Timestamp reported by the latest accepted feed round        |
| `currentTimestamp` | Current chain head block timestamp used for the comparison  |
| `ageSeconds`       | Difference between `currentTimestamp` and `latestUpdatedAt` |
| `maxAgeSeconds`    | Freshness threshold supplied by the caller                  |
| `isStale`          | `true` when `ageSeconds` is greater than `maxAgeSeconds`    |
| `roundId`          | Latest round used for the freshness check                   |
| `answer`           | Raw latest answer from that round                           |

The staleness endpoint reads the latest round from the feed contract. It compares the round's update timestamp with the current chain head timestamp. A fresh result does not approve the value by itself. Your workflow still decides whether to accept the feed value for the operation.

## CLI equivalents [#cli-equivalents]

The DALP CLI exposes the same three operations. Use the CLI for local testing or scripted automation when you prefer not to construct HTTP requests directly.

```bash
dalp system feeds nonce --address 0xFeed --issuer-identity 0xIdentityContract
dalp system feeds submit --address 0xFeed --value 150000000 --observed-at 1700000000
dalp system feeds staleness --address 0xFeed --max-age-seconds 3600
```

## Related [#related]

* [Data feeds overview](/docs/developers/feeds/overview)
* [Read data feeds](/docs/developers/feeds/read-data)
* [Feeds update flow](/docs/architects/flows/feeds-update-flow)