Stacks Mesh API

circle-info

For the complete OpenAPI spec, herearrow-up-right.

A Mesh API (formerly Rosetta API) implementation for the Stacks network. It provides a standardized set of endpoints for reading blockchain data, constructing transactions, and interacting with smart contracts, all through a single JSON-RPC interface that communicates directly with a Stacks node.

chevron-rightWho is this API for?hashtag

Mesh (formerly branded as Rosetta) is an open standard originally developed by Coinbasearrow-up-right to provide a unified interface for reading data from blockchains. It defines a common set of endpoints that blockchain nodes implement, allowing exchanges and other institutions to write a single parser that works across multiple chains.

Rosetta/Mesh is primarily designed for self-hosted infrastructure (such as exchange backends) rather than as a publicly hosted API for general consumption.

Relationship to the Hiro Stacks Blockchain API

The Mesh API is not a replacement for the Hiro Stacks Blockchain API, which remains the recommended API for wallets, dApps, and general developers. Previously, the Hiro Stacks Blockchain API included an embedded Rosetta implementation, but this was removed due to inefficiency. The standalone Mesh API implementation replaces that prior integration.

Features

  • Network status -- query blockchain identity, sync status, connected peers, and supported operation types

  • Block and transaction data -- retrieve full Nakamoto blocks with decoded operations (transfers, contract calls, PoX events, etc.)

  • Account balances -- look up STX balances, nonces, and stacking lock status (including historical queries)

  • Transaction construction -- offline-compatible flow for building, signing, and broadcasting STX transfers, contract calls, and contract deployments

  • Smart contract reads -- call read-only functions, inspect ABIs, read source code, and query data vars and map entries

  • Mesh specification v1.5.1 compliant

Limitations

  • Only Nakamoto blocks (Stacks 3.x+) are supported. This API targets the Nakamoto consensus rules and does not handle legacy pre-Nakamoto block formats. Running it against a node that has not activated Nakamoto will produce errors or incomplete data.

Requirements

Stacks node requirements

The Stacks node does not need any special configuration. A regular chain follower is sufficient. However, the node must have an auth_token configured under [connection_options] in its Stacks.toml config file:

This token must match the STACKS_CORE_RPC_AUTH_TOKEN environment variable passed to the Mesh API (see below).

Configuration

The API is configured via environment variables (a .env file is also supported):

Variable
Default
Description

API_HOST

0.0.0.0

Address the HTTP server binds to

API_PORT

3000

Port the HTTP server listens on

STACKS_CORE_RPC_HOST

(required)

Hostname of the Stacks node RPC

STACKS_CORE_RPC_PORT

20443

Port of the Stacks node RPC

STACKS_CORE_RPC_AUTH_TOKEN

(required)

Auth token for the Stacks node RPC

STACKS_CORE_RPC_TIMEOUT_MS

10000

RPC request timeout in milliseconds

TOKEN_METADATA_CACHE_SIZE

1000

Max entries in the token metadata LRU cache

TOKEN_METADATA_CACHE_TTL_MS

86400000

Token metadata cache TTL (default 24 h)

CONTRACT_ABI_CACHE_SIZE

100

Max entries in the contract ABI LRU cache

CONTRACT_ABI_CACHE_TTL_MS

86400000

Contract ABI cache TTL (default 24 h)

Running locally

Create a .env file in packages/api/ (see packages/api/.env.example):

Running with Docker

circle-info

You don't need to build the docker image yourself, you can run the ones we push to the Stacks-Mesh-API repo herearrow-up-right.

The API will be available at http://localhost:3000.

API endpoints

All endpoints accept POST requests with a JSON body. Every request must include a network_identifier:

Network

Endpoint
Description

/network/list

List supported networks

/network/status

Current block, sync status, and peers

/network/options

Mesh spec version, supported operations, and errors

Data

Endpoint
Description

/block

Get a block by hash or height

/block/transaction

Get a specific transaction within a block

/account/balance

Get STX balance, nonce, and lock info for an address

Construction

Endpoint
Description

/construction/derive

Derive an address from a public key

/construction/preprocess

Parse operations into construction options

/construction/metadata

Fetch nonce, balance, and suggested fee

/construction/payloads

Build unsigned transaction and signing payloads

/construction/combine

Attach signatures to an unsigned transaction

/construction/parse

Decode a signed or unsigned transaction into operations

/construction/hash

Compute the hash of a signed transaction

/construction/submit

Broadcast a signed transaction

Smart contract

Endpoint
Description

/call

Read-only contract calls and contract metadata queries

Transaction construction

Transaction construction follows the standard Mesh offline flow:

The API supports three transaction types: STX token transfers, contract calls, and contract deployments.

Example: STX token transfer

1. Preprocess

Declare the transfer intent as a pair of operations (sender debits, recipient credits):

Returns options (construction parameters) and required_public_keys.

2. Metadata

Fetch the sender's nonce, balance, and a suggested fee:

Returns metadata and suggested_fee.

3. Payloads

Build the unsigned transaction. Include a fee operation (negative amount from the sender) plus the original transfer operations:

Returns unsigned_transaction (hex) and payloads (the signing payload with ecdsa_recovery signature type).

4. Sign offline

Sign the payload hex bytes from the previous step using your private key (secp256k1, recoverable ECDSA). This step happens entirely offline.

5. Combine

Attach the signature to the unsigned transaction:

Returns signed_transaction (hex).

6. Submit

Broadcast the signed transaction to the network:

Returns transaction_identifier with the transaction hash.

Example: contract call

The preprocess step for a contract call uses a single operation:

Function arguments are hex-encoded Clarity values. The rest of the flow (metadata, payloads, sign, combine, submit) is identical to the token transfer example.

Read-only contract calls

The /call endpoint supports several methods for interacting with smart contracts without broadcasting a transaction.

Call a read-only function

Returns a decoded Clarity value:

Get a contract's ABI

Get a contract's source code

Read a data variable

Read a map entry

Supported /call methods

Method
Description

contract_call_read_only

Invoke a read-only contract function

contract_get_interface

Get the contract ABI (functions, variables, maps, tokens)

contract_get_source

Get the contract Clarity source code

contract_get_constant_val

Get the value of a defined constant

contract_get_data_var

Read a define-data-var variable

contract_get_map_entry

Look up a define-map entry by key

Operation types

The API recognizes the following operation types when serializing block data:

coinbase, fee, token_transfer, token_mint, token_burn, contract_call, contract_deploy, tenure_change, poison_microblock, stx_lock, contract_log, handle-unlock, stack-stx, stack-increase, stack-extend, delegate-stx, delegate-stack-stx, delegate-stack-increase, delegate-stack-extend, stack-aggregation-commit, stack-aggregation-commit-indexed, stack-aggregation-increase, revoke-delegate-stx

Testing

The construction tests spin up a Stacks node in Docker and run the full transaction lifecycle against it using the mesh-cliarrow-up-right (Rosetta CLI) validator.


Additional Resources

Last updated

Was this helpful?