footer div:last-child a{
  display: none;
}

th, td {
  border: 1px solid #ccc;          /* 每个单元格的边框颜色为浅灰色 */
  padding: 8px 12px !important;
}

th p, td p {
  margin: 0px !important;
}


This endpoint allows you to get the transactions in a block
and the corresponding block information.

Transactions are limited by max default transactions size.  If not all transactions
are present, the user will need to query for the rest of the transactions via the
get transactions API.

If the block is pruned, it will return a 410

Get blocks by height

Account signature scheme

The account signature scheme allows you to have two types of accounts:

1. A single Ed25519 key account, one private key
2. A k-of-n multi-Ed25519 key account, multiple private keys, such that k-of-n must sign a transaction.

A hex encoded 32 byte Aptos account address.

This is represented in a string as a 64 character hex string, sometimes
shortened by stripping leading 0s, and adding a 0x.

For example, address 0x0000000000000000000000000000000000000000000000000000000000000001 is represented as 0x1.


These codes provide more granular error information beyond just the HTTP
status code of the response.

A block metadata transaction

This signifies the beginning of a block, and contains information
about the specific block

Final state of resources changed by the transaction

The indices of the proposers who failed to propose

The VM status of the transaction, can tell useful information in a failure

Entry function id is string representation of a entry function defined on-chain.

Format: `{address}::{module name}::{function name}`

Both `module name` and `function name` are case-sensitive.


Payload which runs a single entry function

The writeset payload of the Genesis transaction

The genesis transaction

This only occurs at the genesis transaction (version 0)

All bytes (Vec<u8>) data is represented as hex-encoded string prefixed with `0x` and fulfilled with
two hex digits per byte.

Unlike the `Address` type, HexEncodedBytes will not trim any zeros.


Generic type params associated with the Move function

Whether the function can be called as an entry function directly in a transaction

Parameters associated with the move function

Move abilities tied to the generic type param and associated with the function that uses it

Move module id is a string representation of Move module.

Format: `{address}::{module name}`

`address` should be hex-encoded 32 byte account address that is prefixed with `0x`.

Module name is case-sensitive.


Whether the struct is a native struct of Move

Move abilities tied to the generic type param and associated with the type that uses it

String representation of a MoveStructTag (on-chain Move struct type). This exists so you
can specify MoveStructTags as path / query parameters, e.g. for get_events_by_event_handle.

It is a combination of:
  1. `move_module_address`, `module_name` and `struct_name`, all joined by `::`
  2. `struct generic type parameters` joined by `, `

Examples:
  * `0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin>`
  * `0x1::account::Account`

Note:
  1. Empty chars should be ignored when comparing 2 struct tag ids.
  2. When used in an URL path, should be encoded by url-encoding (AKA percent-encoding).

See [doc](https://aptos.dev/concepts/accounts) for more details.


This is a JSON representation of some data within an account resource. More specifically,
it is a map of strings to arbitrary JSON values / objects, where the keys are top level
fields within the given resource.

To clarify, you might query for 0x1::account::Account and see the example data.

Move `bool` type value is serialized into `boolean`.

Move `u8`, `u16` and `u32` type value is serialized into `integer`.

Move `u64`, `u128` and `u256` type value is serialized into `string`.

Move `address` type value (32 byte Aptos account address) is serialized into a HexEncodedBytes string.
For example:
  - `0x1`
  - `0x1668f6be25668c1a17cd8caf6b8d2f25`

Move `vector` type value is serialized into `array`, except `vector<u8>` which is serialized into a
HexEncodedBytes string with `0x` prefix.
For example:
  - `vector<u64>{255, 255}` => `["255", "255"]`
  - `vector<u8>{255, 255}` => `0xffff`

Move `struct` type value is serialized into `object` that looks like this (except some Move stdlib types, see the following section):
  ```json
  {
    field1_name: field1_value,
    field2_name: field2_value,
    ......
  }
  ```

For example:
  `{ "created": "0xa550c18", "role_id": "0" }`

**Special serialization for Move stdlib types**:
  - [0x1::string::String](https://github.com/aptos-labs/aptos-core/blob/main/language/move-stdlib/docs/ascii.md)
    is serialized into `string`. For example, struct value `0x1::string::String{bytes: b"Hello World!"}`
    is serialized as `"Hello World!"` in JSON.


String representation of an on-chain Move type tag that is exposed in transaction payload.
    Values:
      - bool
      - u8
      - u16
      - u32
      - u64
      - u128
      - u256
      - address
      - signer
      - vector: `vector<{non-reference MoveTypeId}>`
      - struct: `{address}::{module_name}::{struct_name}::<{generic types}>`

    Vector type value examples:
      - `vector<u8>`
      - `vector<vector<u64>>`
      - `vector<0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin>>`

    Struct type value examples:
      - `0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin>
      - `0x1::account::Account`

    Note:
      1. Empty chars should be ignored when comparing 2 struct tag ids.
      2. When used in an URL path, should be encoded by url-encoding (AKA percent-encoding).


Multi agent signature for multi agent transactions

This allows you to have transactions across multiple accounts

The associated signatures, in the same order as the secondary addresses

A Ed25519 multi-sig signature

This allows k-of-n signing for a transaction

The public keys for the Ed25519 signature

Signature associated with the public keys in the same order

The number of signatures required for a successful transaction

A multisig transaction that allows an owner of a multisig account to execute a pre-approved
transaction as the multisig account.

Payload which runs a script that can run multiple functions

Enum of the different types of transactions in Aptos

An enum of the possible transaction payloads

An enum representing the different transaction signatures available

A string containing a 64-bit unsigned integer.

We represent u64 values as a string to ensure compatibility with languages such
as JavaScript that do not parse u64s in JSON natively.


A transaction submitted by a user to change the state of the blockchain

Write a new module or update an existing one

Write a resource or update an existing one

A final state change of a transaction on a resource or module

A writeset payload, used only for genesis

A Block with or without transactions

This contains the information about a transactions along with
associated transactions if requested

This is the generic struct we use for all API errors, it contains a string
message and an Aptos API specific error code.

Chainbase Docs

What Is Chainbase?

Introducing Chainbase

Tokenomics

Litepaper

FAQs

Dual-Chain

Dual-Staking

Data Processing Based on AVS

Chainbase Network AVS Design

Glossary

Co-processor Layer Testnet

Open APIs

Roadmap

Chainbase Roadmap

CIPs

Chainbase Improvement Proposals (CIPs)

Introduction

Run a Chainbase AVS Operator

Run a Validator

Configuration

Join Testnet

Overview

Beam

Berachain Artio

Bitlayer Mainnet

Immutable zkEVM

Mantle

Mint Mainnet

Moonbeam

Scroll

Taiko Hekla L2

opBNB Mainnet

Supported Networks

Pricing

Support

Welcome

Theia

Features

Task Models

How to Create Task Models

Thesis

API Status Code

Json Web Token(JWT)

Learn and build

Run a node

Data Catalog

Data Platform

Crypto World Model

API Reference

Developers

Operators

Validators

Delegators

Manuscript Zone

Execution Layer

Consensus Layer

API Reference

Web3 API

SQL API

Get blocks by height

Path Parameters

Query Parameters

Response