--- title: "Get metrics for EVM chains" method: GET path: "/v2/chains/{chainId}/metrics/{metric}" tags: ["Chain Metrics"] --- # Get metrics for EVM chains `GET /v2/chains/{chainId}/metrics/{metric}` EVM chain metrics are available for all Avalanche L1s on _Mainnet_ and _Fuji_ (testnet). You can request metrics by EVM chain ID. See the `/chains` endpoint for all supported chains. All metrics are updated several times every hour. Each metric data point has a `value` and `timestamp` (Unix timestamp in seconds). All metric values include data within the duration of the associated timestamp plus the requested `timeInterval`. All timestamps are fixed to the hour. When requesting a timeInterval of **day**, **week**, or **month**, the timestamp will be 0:00 UTC of the day, Monday of the week, or first day of the month, respectively. The latest data point in any response may change on each update. ### Metrics activeAddresses: The number of distinct addresses seen within the selected `timeInterval` starting at the timestamp. Addresses counted are those that appear in the “from” and “to” fields of a transaction or ERC20/ERC721/ERC1155 transfer log event. activeSenders: This metric follows the same structure as activeAddresses, but instead only counts addresses that appear in the “from” field of the respective transaction or transfer log event. cumulativeTxCount: The cumulative transaction count from genesis up until 24 hours after the timestamp. This aggregation can be considered a “rolling sum” of the transaction count metric (txCount). Only `timeInterval=day` supported. cumulativeAddresses: The cumulative count of unique addresses from genesis up until 24 hours after the timestamp. Addresses counted are those that appear in the “from” and “to” fields of a transaction or ERC20/ERC721/ERC1155 transfer log event. Only `timeInterval=day` supported. cumulativeContracts: The cumulative count of contracts created from genesis up until the timestamp. Contracts are counted by looking for the CREATE, CREATE2, and CREATE3 call types in all transaction traces (aka internal transactions). Only `timeInterval=day` supported. cumulativeDeployers: The cumulative count of unique contract deployers from genesis up until 24 hours after the timestamp. Deployers counted are those that appear in the “from” field of transaction traces with the CREATE, CREATE2, and CREATE3 call types. Only `timeInterval=day` supported. contracts: The count of contracts created within the requested timeInterval starting at the timestamp. Contracts are counted by looking for the CREATE, CREATE2, and CREATE3 call types in all transaction traces (aka internal transactions). Only `timeInterval=day` supported. deployers: The count of unique deployers within the requested timeInterval starting at the timestamp. Deployers counted are those that appear in the “from” field of transaction traces with the CREATE, CREATE2, and CREATE3 call types. Only `timeInterval=day` supported. gasUsed: The amount of gas used by transactions within the requested timeInterval starting at the timestamp. txCount: The amount of transactions within the requested timeInterval starting at the timestamp. avgGps: The average Gas used Per Second (GPS) within the day beginning at the timestamp. The average is calculated by taking the sum of gas used by all blocks within the day and dividing it by the time interval between the last block of the previous day and the last block of the day that begins at the timestamp. Only `timeInterval=day` supported. maxGps: The max Gas used Per Second (GPS) measured within the day beginning at the timestamp. Each GPS data point is calculated using the gas used in a single block divided by the time since the last block. Only `timeInterval=day` supported. avgTps: The average Transactions Per Second (TPS) within the day beginning at the timestamp. The average is calculated by taking the sum of transactions within the day and dividing it by the time interval between the last block of the previous day and the last block of the day that begins at the timestamp. Only `timeInterval=day` supported. maxTps: The max Transactions Per Second (TPS) measured within the day beginning at the timestamp. Each TPS data point is calculated by taking the number of transactions in a single block and dividing it by the time since the last block. Only `timeInterval=day` supported. avgGasPrice: The average gas price within the day beginning at the timestamp. The gas price used is the price reported in transaction receipts. Only `timeInterval=day` supported. maxGasPrice: The max gas price seen within the day beginning at the timestamp. The gas price used is the price reported in transaction receipts. Only `timeInterval=day` supported. feesPaid: The sum of transaction fees paid within the day beginning at the timestamp. The fee is calculated as the gas used multiplied by the gas price as reported in all transaction receipts. Only `timeInterval=day` supported. ## Path parameters - `metric` 'activeAddresses' | 'activeSenders' | 'cumulativeTxCount' | 'cumulativeAddresses' | 'cumulativeContracts' | 'cumulativeDeployers' | 'contracts' | 'deployers' | 'gasUsed' | 'txCount' | 'avgGps' | 'maxGps' | 'avgTps' | 'maxTps' | 'avgGasPrice' | 'maxGasPrice' | 'feesPaid', required - `chainId` string, required ## Query parameters - `startTimestamp` integer - `endTimestamp` integer - `timeInterval` 'hour' | 'day' | 'week' | 'month' - `pageToken` string - `pageSize` integer ## Response `200` Successful response - MetricsApiResponse - `nextPageToken` string — A token, which can be sent as `pageToken` to retrieve the next page. If this field is omitted or empty, there are no subsequent pages. - `results` MetricsValue[], required — Array of current metrics values at different timestamps. - `value` number, required — Aggregated value for the current metrics. - `timestamp` number, required — Unix Epoch timestamp for which metrics are aggregated. Depending on the interval of the metric this can be at the start of the relevant hour, day, month, year, etc. ## Other responses - `400` — Bad requests generally mean the client has passed invalid or malformed parameters. Error messages in the response could help in evaluating the error. - `401` — When a client attempts to access resources that require authorization credentials but the client lacks proper authentication in the request, the server responds with 401. - `403` — When a client attempts to access resources with valid credentials but doesn't have the privilege to perform that action, the server responds with 403. - `404` — The error is mostly returned when the client requests with either mistyped URL, or the passed resource is moved or deleted, or the resource doesn't exist. - `429` — This error is returned when the client has sent too many, and has hit the rate limit. - `500` — The error is a generic server side error that is returned for any uncaught and unexpected issues on the server side. This should be very rare, and you may reach out to us if the problem persists for a longer duration. - `502` — This is an internal error indicating invalid response received by the client-facing proxy or gateway from the upstream server. - `503` — The error is returned for certain routes on a particular Subnet. This indicates an internal problem with our Subnet node, and may not necessarily mean the Subnet is down or affected. --- [API](https://skmtc.net/avax/apis/metrics-api.md) · [All operations](https://skmtc.net/avax/apis/metrics-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/avax/metrics-api/versions/e699a9ddcb70/schema)