System value and transaction statistics

A bank reporting on a tokenization programme needs two headline numbers at the system level: how much value the programme holds and how much it moves. The system value and transaction statistics endpoints answer both from the indexed ledger, so a dashboard or a board report reads the figure directly instead of summing balances and events by hand.

These endpoints sit alongside the participant-scoped portfolio statistics. Portfolio statistics answer "what does this participant hold." The endpoints on this page answer "what does the whole system hold and how active is it," with the value reads spanning the active system and the transaction reads scoped to the caller.

Two scopes on one surface

The endpoints fall into two groups, and the difference in scope matters for what each number means.

• System value reads the active system's total. value, system-value-histories, and the preset variant report the combined value of every indexed asset in the active system, regardless of who holds it.
• Transaction activity reads transfer counts and history. By default these are scoped to the caller's own wallet set. A caller with organization update permission reads the org-wide set instead.

Reach for the value group when you report on programme size. Reach for the transaction group to report on activity, and account for the caller scope when you compare numbers across users.

Endpoints

Each endpoint returns a JSON:API single-resource envelope with data and links.self. Reads run against the active system from the request context, so a caller with assets in more than one DALP system reads one system per request.

Prerequisites

Use an authenticated organization context with an active system. Server integrations authenticate with the X-Api-Key header shown in the examples. Browser or RPC integrations use an authenticated user session through the standard cookie or authorization flow.

The value figures are denominated in the organization's base currency. DALP converts each asset from its denomination currency using indexed feed rates and rounds the result for the response, so you display the returned value without applying another conversion.

Read the current system value

The value endpoint returns the current total for the active system. It takes no query parameters.

curl --request GET \
  "$DALP_API_URL/api/v2/system/stats/value" \
  --header "X-Api-Key: $DALP_API_TOKEN"

{
  "data": {
    "totalValue": "5000000.00",
    "conversionReliable": true
  },
  "links": {
    "self": "/v2/system/stats/value"
  }
}

Treat conversionReliable as a quality signal on the figure. When it is false, at least one asset's currency conversion used a fallback rate rather than a live feed rate, so the total is an estimate rather than a fully feed-backed number. When the system holds no indexed value yet, totalValue is 0.00.

Read the system value history

The history endpoints return total system value over time so a dashboard can chart the programme's growth rather than read a single instant. Use the range endpoint when your dashboard supplies the window, and the preset endpoint when DALP should resolve the window from the current time.

interval accepts hour or day. from and to are timestamps, and from must be before or equal to to.

curl --request GET \
  "$DALP_API_URL/api/v2/system/stats/system-value-histories?interval=day&from=2026-06-01T00:00:00.000Z&to=2026-06-08T00:00:00.000Z" \
  --header "X-Api-Key: $DALP_API_TOKEN"

Supported presets resolve their own interval:

curl --request GET \
  "$DALP_API_URL/api/v2/system/stats/system-value-histories/presets/trailing7Days" \
  --header "X-Api-Key: $DALP_API_TOKEN"

Both variants return the same shape: the resolved range, a value series, and the conversion reliability flag.

{
  "data": {
    "range": {
      "interval": "day",
      "from": "2026-06-01T00:00:00.000Z",
      "to": "2026-06-08T00:00:00.000Z",
      "isPreset": false
    },
    "data": [
      {
        "timestamp": "2026-06-01T00:00:00.000Z",
        "totalValueInBaseCurrency": 4200000
      },
      {
        "timestamp": "2026-06-02T00:00:00.000Z",
        "totalValueInBaseCurrency": 4350000
      }
    ],
    "conversionReliable": true
  },
  "links": {
    "self": "/v2/system/stats/system-value-histories"
  }
}

range reports the window DALP actually used. isPreset is true for a preset request and false for a custom range. DALP clamps a to that is in the future to the current time, so the resolved range can differ from a window you sent. data is the time series, with one totalValueInBaseCurrency point per bucket. As with the current value, conversionReliable is false when a feed rate fell back to unity.

Read transaction counts

This endpoint returns the total and recent transfer counts in scope. timeRange sets the recent window in days, accepts 1 to 365, and defaults to 7.

curl --request GET \
  "$DALP_API_URL/api/v2/system/stats/transaction-count?timeRange=30" \
  --header "X-Api-Key: $DALP_API_TOKEN"

{
  "data": {
    "totalTransactions": 1840,
    "recentTransactions": 120,
    "timeRangeDays": 30
  },
  "links": {
    "self": "/v2/system/stats/transaction-count"
  }
}

Both counts measure completed transfer events. They count a transfer when one of the addresses involved belongs to the caller's wallet set.

Read transaction history

The history endpoint returns the same totals plus a daily series for charting trends.

curl --request GET \
  "$DALP_API_URL/api/v2/system/stats/transaction-history?timeRange=30" \
  --header "X-Api-Key: $DALP_API_TOKEN"

{
  "data": {
    "totalTransactions": 1840,
    "recentTransactions": 120,
    "transactionHistory": [
      {
        "timestamp": "2026-06-19T00:00:00.000Z",
        "transactions": 38
      },
      {
        "timestamp": "2026-06-20T00:00:00.000Z",
        "transactions": 45
      }
    ],
    "timeRangeDays": 30
  },
  "links": {
    "self": "/v2/system/stats/transaction-history"
  }
}

transactionHistory buckets completed transfers by UTC day across the timeRange window. Each entry pairs a day timestamp with the transactions count for that day. Days with no activity in scope do not appear, so chart code should treat a missing day as zero rather than expecting a dense series.

Transaction scope and admin reads

The transaction count and history endpoints are scoped to the caller, not to the whole organization by default. DALP resolves the wallet set the caller may read transfers for and counts only transfers involving those wallets.

A caller who holds the organization update permission, the same gate the admin operations enforce, reads the org-wide wallet set and therefore the system-wide transfer numbers. A standard caller reads only their own activity. When the caller resolves to no wallets, for example an API-key session without a default wallet, both endpoints return zero counts and an empty history rather than an error.

This scope applies only to the transaction endpoints. The value endpoints always report the active system's total regardless of caller, so a system value figure and a transaction count from the same standard caller describe different populations. Compare them with that in mind.

Related

• System asset statistics for asset counts, value breakdown, and creation and activity trends.
• Portfolio statistics for the authenticated participant's portfolio value and asset-type breakdown.
• Token volume statistics for per-token transfer volume.
• Token holders and transfers for per-token transfer history.
• Getting started with API integration