---
title: "Get the Protocol Rewards Processing Health"
method: GET
path: "/v2/solana/{network}/health"
tags: ["Solana Staking Reporting"]
---

# Get the Protocol Rewards Processing Health

`GET /v2/solana/{network}/health`

The status of reward processing, if optimal then all rewards data up to the indicated metadata fields are available the processing status is degraded if any of the following are true:

  * `chainEpoch` - `lastProcessedInflationEpoch` > 1
  * `chainEpoch` - `lastProcessedStatusesEpoch` > 1
  * if the `lastProcessedSlot` is over 20 minutes behind the chainSlot - note we run 10 minutes behind by design to alleviate any reorgs so this is a 10 minuate buffer on top of that
  * `chainEpoch` - `lastProcessedMevEpoch` > 1
  * if the `lastProcessedMevTxTimestamp` is older than 3.2 days, this is mainly as a check to see if the jito mev bot has paid out expectedly or not, not that our system is degraded
  
**Please note** that mev rewards are allocated to the epoch they are paid out in *not* the epoch they are earned in.

## Path parameters

- `network` string, required

## Response `200`

OK

- HealthResponse1 — The health response object
  - `status` 'UNKNOWN' | 'OPTIMAL' | 'DEGRADED' — the health status
  - `timestamp` number — the timestamp when the status was last updated in epoch seconds
  - `metadata` HealthMetadata1 — A map of string keys to string values, new fields could also be added at any time.
    - `chainEpoch` string, number — The current active epoch on the chain
    - `chainSlot` string, number — The current chain slot - note there could be up to a minute delay for an update on this
    - `lastProcessedInflationEpoch` string, number — The last processed inflationary reward epoch - whatever this number is at the inflation rewards are available up to this epoch
    - `lastProcessedMevEpoch` string, number — The last processed mev reward epoch - whatever this number is at the mev rewards are available up to this epoch, there can be up to a 120 minute delay after the epoch ends before these are available
    - `lastProcessedMevTxTimestamp` string, number — The timestamp of the last processed mev transaction
    - `lastProcessedSlot` string, number — The slot that was last processed by the system, fee/rent rewards should be available up to this slot
    - `lastProcessedStatusesEpoch` string, number — The last processed statuses epoch, statuses are up to date to the start of this epoch
    - `reason` 'INFLATION_EPOCH' | 'WEBSOCKET_EPOCH' | 'STATUSES_EPOCH' | 'LAST_PROCESSED_SLOT' | 'MEV_EPOCH' | 'MEV_TX_TIMESTAMP' | 'OPTIMAL' — An enum reason for the overall status. - INFLATION_EPOCH: This means that the processing of the inflationary rewards is behind - WEBSOCKET_EPOCH: This means that real time slot processing is behind - STATUSES_EPOCH: This means that status data is behind - LAST_PROCESSED_SLOT: This means that real time slot processing is behind - MEV_EPOCH: This means mev reward data is delayed - MEV_TX_TIMESTAMP: This likely means that the jito mev bot is delayed paying out rewards - OPTIMAL: All good

## Other responses

- `400` — Bad Request
- `422` — Validation Error

---

[API](https://skmtc.dev/blockdaemon/apis/staking-api.md) · [All operations](https://skmtc.dev/blockdaemon/apis/staking-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/blockdaemon/staking-api/revisions/f94e296a08a3/schema)