Mempool API
Transactions, balances, supply, and mempool metadata: the write and query path for clients.
- POST
fetch_balance - POST
create_transactions - POST
total_supply - POST
create_item_asset
Everything you need to point a client at Lineage, in one place: the base URLs by node class, the current network status, and how to stand up your own stack.
https://mempool.lineage.toTransactions, balances, supply, and mempool metadata.https://storage.lineage.toFull blockchain history and block reads.https://miner.lineage.toOperator-facing status where a release exposes it.Pick an HTTP client, point it at the public base URL for your node class, and call the documented routes. Subsystems are exposed on separate hosts: mempool calls use the mempool host, storage reads use the storage host, and so on. A minimal connectivity check is a read-only call such as fetch_balance.
# Read-only connectivity check against the mempool host
curl -sS -X POST "https://mempool.lineage.to/fetch_balance" \
-H "Content-Type: application/json" \
-H "x-cache-id: 0123456789abcdef0123456789abcdef" \
-d '["<address-1>"]'
# Example success envelope
{
"id": "45v340cd2f8c4782a5b058832565afb1",
"status": "Success",
"reason": "Balance successfully fetched",
"route": "fetch_balance",
"content": {
"total": { "tokens": 5463669, "items": {} },
"address_list": {
"<address>": [
{ "out_point": { "t_hash": "g9182e1e2a55b0ef36f1183602d74e63", "n": 0 },
"value": { "Token": 5463669 } }
]
}
}
}The public HTTP API is organised by node class. Each subsystem is documented route by route, with full request and response JSON, including the standard error envelope.
Transactions, balances, supply, and mempool metadata: the write and query path for clients.
fetch_balancecreate_transactionstotal_supplycreate_item_assetFull blockchain history. After blocks are mined and validated, they are persisted for long-term read access.
latest_blockblock_by_numblockchain_entryOperator-facing HTTP where a release exposes it, a small surface compared to mempool and storage.
infoThree official clients wrap the same API: wallet creation, key management, asset issuance, two-way payments, and chain reads. Configure each with a mempool base URL, a storage base URL, and a passphrase for local key encryption.
The client for browser and Node apps and wallets: create a wallet, issue items and assets, run two-way payments, send and receive. Drop-in for web front-ends and Valence servers.
The client for backends, data tooling, and automation: key management, balance and supply reads, transaction construction, and two-way flows, the same surface as sdk-js, idiomatic for Python services and notebooks.
The client for server-side web stacks: wallet creation, asset issuance, payments, and chain reads from within PHP applications and CMS integrations.
Read Lineage: The Living Economy, the full technical and economic specification archived on Zenodo, alongside the concepts in the docs to understand how bounded policy search and cryptographic verification fit together.
Every repository is open for review, issues, and contributions. The code that ships with the project lives on the Lineage Foundation GitHub organisation.
Start with small, read-only calls from the storage or mempool sections of the reference to confirm connectivity, then move on to transactions. Each endpoint page documents the exact request and response contract.
Specification and research questions live in the Fremen Forum (hosted on Discourse). Implementation questions belong in the repo issue trackers on GitHub.
Specification and research discussion for the protocol and its mechanisms.
Implementation questions, bugs, and contributions on the open repositories.
The protocol, the reference deployment, and the documentation are all open. Pick up the docs or jump straight into the source.