Showing details for spent_coins_age_band_2y_to_3y

The name of the metric that is used in the public API.
For example, if the metric is `price_usd` it is provided as the `metric` argument.

Example:

  {
    getMetric(metric: "price_usd"){
      timeseriesData(asset: "ethereum" from: "utc_now-90d" to: "utc_now" interval: "1d"){
        datetime
        value
      }
    }
  }

The name of the metric that is used in the database tables.
The database tables are accessed through Santiment Queries when the
user interacts with the data via SQL.

How to use Santiment Queries, check this link

The minimum interval at which the metric is updated.

For more details check this link

The Stabilization Period is the time interval after which
the metric data is considered stable and unlikely to change.

Due to the specifics of our metrics calculation algorithms (especially for on-chain data),
metric values may be recalculated several times after they are first provided via the API.
This can happen, for example, while waiting for a required number of blockchain confirmations
or as new data becomes available.

The stabilization period defines how long after the initial calculation the data may still change.
Once this period has passed, the data is generally considered immutable and safe for
use in critical applications.

Example: If the stabilization period is 24 hours, the metric value for a given day
may be updated several times within those 24 hours, but after that, it is considered final.

The Can Mutate field indicates whether the metric data can change even after the
stabilization period has passed.

In most cases, once the stabilization period is over, the metric data is considered final.
However, for some metrics, it is possible for the data to be recalculated or updated later
due to changes in the underlying calculation parameters (for example, if the set of addresses
included in the calculation is updated).

If Can Mutate is true, you should be aware that the metric value may change even
after it was previously considered stable. If false, the data is guaranteed to remain
unchanged after the stabilization period.

The link to the documentation page for the metric.

A boolean that indicates whether the metric has incomplete data.
Only daily metrics (metrics with Frequency of 1d or bigger) can have incomplete data.

In some cases, if the day is not yet complete, the current value can be misleading.
For instance, fetching daily active addresses at 12pm UTC would
include only half a day's data, potentially making the metric value for that day appear too low.

By default the incomplete data is not returned by the API.
To obtain this last incomplete data point, provide the `includeIncompleteData` flag
Example:
  {
    getMetric(metric: "daily_active_addresses"){
      timeseriesData(
        slug: "bitcoin"
        from: "utc_now-3d"
        to: "utc_now"
        includeIncompleteData: true){
          datetime
          value
        }
    }
  }

The default aggregation for the metric.

The default aggregation is hand picked so it makes most sense for the given metric.

For example, the default aggregation for `price_usd` is `LAST`, as other aggregations like
`SUM` do not make sense for that metric.

To override the default aggregation, provide the `aggregation` parameter.

Example:
  {
    getMetric(metric: "price_usd"){
      timeseriesData(
      slug: "bitcoin"
      from: "utc_now-90d"
      to: "utc_now"
      aggregation: MAX){
        datetime
        value
      }
    }
  }

FREE - The metrics labeled FREE have their entire historical data and realtime data
available without any restrictions. These metrics are available to all users, regardless of their
subscription level.

RESTRICTED - The metrics labeled RESTRICTED have their historical and realtime data
restricted based on the subscription plan of the user.

To see how much of the historical and realtime data is restricted, check the restrictions
at the pricing page.
The documentation about the restriction is avaialble at this Academy page.

A boolean that indicates whether the metric is timebound.

The available aggregations for the metric.

The aggregation controls how multiple data points are combined into one.

For example, if the metric is `price_usd`, the aggregation is `LAST`, and the
interval is `1d`, then each data point will be represented by the last price in the
given day.


All aggregations except `OHLC` are queried the same way:

Example:
  {
    getMetric(metric: "price_usd"){
      timeseriesData(
      slug: "bitcoin"
      from: "utc_now-90d"
      to: "utc_now"
      aggregation: MAX){
        datetime
        value
      }
    }
  }

When `OHLC` aggregation is used, the result is fetched in a different way -
use `valueOhlc` instead of `value`:

Example:
  {
    getMetric(metric: "price_usd"){
      timeseriesData(
      slug: "bitcoin"
      from: "utc_now-90d"
      to: "utc_now"
      aggregation: OHLC){
        datetime
        valueOhlc {
          open high close low
        }
      }
    }
  }

The available selectors for the metric.

The selectors control what entity the data is fetched for.
For example, if the metric is `price_usd`, the selector is `asset`, and the
value is `ethereum`, then the data will be fetched for.

To provide any selector other than `slug`, use the `selector` input parameter.

Example:
  {
    getMetric(metric: "active_withdrawals_per_exchange"){
      timeseriesData(
      selector: { slug: "bitcoin" owner: "binance" }
      from: "utc_now-90d"
      to: "utc_now"){
        datetime
        value
      }
    }
  }

The data type of the metric.
The data type is used to determine how the data is stored and fetched.

All metrics with `timeseries` data type are fetched in a generic way using `timeseriesData` field.

Example:
  {
    getMetric(metric: "price_usd"){
      timeseriesData(
        slug: "bitcoin"
        from: "utc_now-90d"
        to: "utc_now"){
          datetime
          value
        &rbra
    &rbra
  }

The metrics with `histogram` data type are fetched in different ways as their result format
could differ. Check the documentation of each such metric to see an example.

The assets for which the metric is available.
The metric can be fetched for any of the listed assets.

Each asset is uniquely identified by its `slug`:

Example:
  {
    getMetric(metric: "daily_active_addresses"){
      timeseriesData(
        slug: "bitcoin"
        from: "utc_now-90d"
        to: "utc_now"){
          datetime
          value
        }
    }
  }