LogoLogo
  • INTRODUCTION
  • LEARN
    • Espresso in the Modular Stack
    • The Espresso Network
      • System Overview
      • Properties of HotShot
        • EspressoDA
          • How It Works
      • Interfaces
        • Espresso ↔ Rollup
        • Espresso ↔ L1
        • Rollup ↔ L1
      • Internal Functionality
        • Espresso Node
        • Light Client Contract
        • Fee Token Contract
        • Stake Table
          • How the Stake Table Contract Works
        • Smart Contract Upgradeability
    • Rollup Stacks
      • Integrating a ZK Rollup
        • ZK Rollup Architecture
        • Using Espresso
        • Summary of Changes
      • Integrating an Optimistic Rollup
        • Optimistic Rollup Architecture
        • Using Espresso
        • Summary of Changes
  • Guides
    • Using the Espresso Network
      • Integrating Arbitrum Orbit Chain
        • Quickstart with Arbitrum Nitro Rollups
        • Reading Confirmations from the Espresso Network
        • Arbitrum Nitro Integration Overview
          • Using TEE with Nitro
          • Arbitrum Nitro Trust & Liveness Dependencies
        • Migrating Arbitrum Orbit Chains to Espresso
          • Arbitrum Testnet
            • Nitro Testnet
            • Local Deployment (`docker compose`)
      • Using the Espresso Network as a Cartesi application
    • Running an Espresso Node
    • Running a Builder
    • Bridging with the Espresso Network
  • API Reference
    • Espresso API
      • Status API
      • Catchup API
      • Availability API
      • Node API
      • State API
      • Events API
      • Submit API
      • Earlier Versions
        • v0
          • Status API
          • Catchup API
          • Availability API
          • Node API
          • State API
          • Events API
          • Submit API
    • Builder API
  • Releases
    • Mainnet 1
      • Running a Mainnet 1 Node
      • Contracts
      • Rollup Migration Guide
    • Mainnet 0
      • Running a Mainnet 0 Node
      • Contracts
    • Testnets
      • Decaf Testnet Release
        • Running a Node
        • Contracts
      • Cappuccino Testnet Release
        • Running a Node
        • Deploying a Rollup on Cappuccino
        • Benchmarks
      • Gibraltar Testnet Release
        • Interacting with Gibraltar
        • Arbitrum Nitro integration
        • Deploying a Rollup on Gibraltar
      • Cortado Testnet Release
        • Interacting with Cortado
        • OP Stack Integration
          • Optimism Leader Election RFP
      • Doppio Testnet Release
        • Interacting with Doppio
        • Polygon zkEVM Stack Integration
        • Minimal Rollup Example
        • Benchmarks
      • Americano Testnet Release
  • Appendix
    • Interacting with L1
      • Trustless Sync
      • Fork Recovery
      • Bridging
    • Glossary of Key Terms
Powered by GitBook
On this page
  1. API Reference
  2. Espresso API
  3. Earlier Versions

v0

Reference for v0 REST APIs served by Espresso nodes and query services

PreviousEarlier VersionsNextStatus API

Last updated 1 month ago

API v0was the default API version from genesis until the proof-of-stake upgrade. Proof-of-stake is scheduled for April 15, 2025 on testnet and TBD on mainnet, after which v1 will be the default API version. v0will continue to be supported indefinitely, however certain endpoints will fail when querying for data originating after the proof-of-stake upgrade, and fields of certain types which were added in the proof-of-stake upgrade are not accessible via this API.

The differences between v0and the subsequent version v1are:

  • v0lacks new fields which were added to the Leaftype in v1 . For leaves created before the proof-of-stake upgrade, the leaf structure without these fields is equivalent to the new structure. However, for leaves created after the proof-of-stake upgrade, it will be impossible to compute accurate commitments or verify consensus artifacts using the v0API.

    • next_epoch_justify_qc

    • next_drb_result

    • with_epoch

  • v0lacks new fields which were added to the QC type in v1 . For QCs created before the proof-of-stake upgrade, the QC structure without these fields is equivalent to the new structure. However, for QCs created after the proof-of-stake upgrade, it will be impossible to compute accurate commitments or verify consensus artifacts using the v0API.

    • epoch

  • The types of VID artifacts (VID shares, , and ) are different in v0and v1. For blocks created before the proof-of-stake upgrade, the VID types are equivalent, and any proofs using these types can still be verified using the information returned by the v0API. However, the new version of the Rust SDK will not be able to deserialize the v0types, and for blocks created after the proof-of-stake upgrade, the v0endpoints will return errors.

  • v0lacks all APIs related to rewards state

  • v0lacks the availability/state-cert/:epochand catchup/:height/leafchainAPIs which are necessary for running a consensus client after proof of stake

  • v0lacks the convenience endpoint node/stake-tablefor fetching the latest stake table from a trusted server

VID common
namespace proofs