---
title: "GET /checkpoints/{checkpoint}"
method: GET
path: "/checkpoints/{checkpoint}"
tags: ["Checkpoint"]
---

# GET /checkpoints/{checkpoint}

`GET /checkpoints/{checkpoint}`

## Path parameters

- `checkpoint` integer, required

## Response `200`

- SignedCheckpointSummary
  - `checkpoint` CheckpointSummary, required
    - `checkpoint_commitments` CheckpointCommitment[] — Commitments to checkpoint-specific state (e.g. txns in checkpoint, objects read/written in checkpoint).
      - `digest` string, base58, required — A representation of a 32 byte digest
      - `type` 'ecmh_live_object_set', required
    - `content_digest` string, base58, required — A representation of a 32 byte digest
    - `end_of_epoch_data` EndOfEpochData
      - `epoch_commitments` CheckpointCommitment[], required — Commitments to epoch specific state (e.g. live object set)
        - `digest` string, base58, required — A representation of a 32 byte digest
        - `type` 'ecmh_live_object_set', required
      - `next_epoch_committee` ValidatorCommitteeMember[], required — next_epoch_committee is `Some` if and only if the current checkpoint is the last checkpoint of an epoch. Therefore next_epoch_committee can be used to pick the last checkpoint of an epoch, which is often useful to get epoch level summary stats like total gas cost of an epoch, or the total number of transactions from genesis to the end of an epoch. The committee is stored as a vector of validator pub key and stake pairs. The vector should be sorted based on the Committee data structure.
        - `public_key` string, base64, required — Base64 encoded data
        - `stake` string, u64, required — Radix-10 encoded 64-bit unsigned integer
      - `next_epoch_protocol_version` string, u64, required — The protocol version that is in effect during the epoch that starts immediately after this checkpoint.
    - `epoch` string, u64, required — Radix-10 encoded 64-bit unsigned integer
    - `epoch_rolling_gas_cost_summary` GasCostSummary, required — Summary of gas charges. Storage is charged independently of computation. There are 3 parts to the storage charges: `storage_cost`: it is the charge of storage at the time the transaction is executed. The cost of storage is the number of bytes of the objects being mutated multiplied by a variable storage cost per byte `storage_rebate`: this is the amount a user gets back when manipulating an object. The `storage_rebate` is the `storage_cost` for an object minus fees. `non_refundable_storage_fee`: not all the value of the object storage cost is given back to user and there is a small fraction that is kept by the system. This value tracks that charge. When looking at a gas cost summary the amount charged to the user is `computation_cost + storage_cost - storage_rebate` and that is the amount that is deducted from the gas coins. `non_refundable_storage_fee` is collected from the objects being mutated/deleted and it is tracked by the system in storage funds. Objects deleted, including the older versions of objects mutated, have the storage field on the objects added up to a pool of "potential rebate". This rebate then is reduced by the "nonrefundable rate" such that: `potential_rebate(storage cost of deleted/mutated objects) = storage_rebate + non_refundable_storage_fee`
      - `computation_cost` string, u64, required — Cost of computation/execution
      - `non_refundable_storage_fee` string, u64, required — The fee for the rebate. The portion of the storage rebate kept by the system.
      - `storage_cost` string, u64, required — Storage cost, it's the sum of all storage cost for all objects created or mutated.
      - `storage_rebate` string, u64, required — The amount of storage cost refunded to the user for all objects deleted or mutated in the transaction.
    - `network_total_transactions` string, u64, required — Total number of transactions committed since genesis, including those in this checkpoint.
    - `previous_digest` string, base58 — A representation of a 32 byte digest
    - `sequence_number` string, u64, required — Radix-10 encoded 64-bit unsigned integer
    - `timestamp_ms` string, u64, required — Timestamp of the checkpoint - number of milliseconds from the Unix epoch Checkpoint timestamps are monotonic, but not strongly monotonic - subsequent checkpoints can have same timestamp if they originate from the same underlining consensus commit
    - `version_specific_data` string, base64 — CheckpointSummary is not an evolvable structure - it must be readable by any version of the code. Therefore, in order to allow extensions to be added to CheckpointSummary, we allow opaque data to be added to checkpoints which can be deserialized based on the current protocol version.
  - `signature` ValidatorAggregatedSignature, required
    - `bitmap` string, base64, required — Base64 encoded data
    - `epoch` string, u64, required — Radix-10 encoded 64-bit unsigned integer
    - `signature` string, base64, required — Base64 encoded data

## Other responses

- `404`

## Changes

- **2024-07-17** `d132304a4602` — 1 breaking, 4 info
  - added the new path request parameter `checkpoint`
  - api operation id `GetCheckpoint` was added
  - api tag `Checkpoint` added
  - added the non-success response with the status `404`
  - …1 more

[Change history](https://skmtc.dev/verichains/apis/sui-node-api/changes/checkpoints/:checkpoint/get.md)

---

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