Explore the chain

With REST enabled (ting api enable, see Start a node), a node serves three views from one address, by default http://127.0.0.1:18441.

All three are bundled into the node and work offline, and each has its own navigation.

The explorer#

• Overview shows the height, accumulated work, pending transactions, the active capacity for each counter, recent blocks, the ChainId and the current state root.
• Blocks lists the canonical chain, with each block's use of every counter and its share of the capacity the block had. A block page shows its header, its use against its capacity, its transactions with their receipts and resource use, and their events.
• Pending transactions lists what the node holds in its mempool.
• A transaction page shows every canonical occurrence of that ID (the same transaction can be included more than once), with a summary of its envelope. While the transaction is queued, the page shows the pending envelope instead.
• A contract page shows the immutable manifest (the code hash, size and price) and looks up any 32-byte storage key.

Search accepts a block height, block hash, transaction ID or contract ID. The explorer's pages are /, /blocks, /blocks/{id}, /transactions/{id}, /contracts/{id} and /mempool.

The REST API#

The same data is available as JSON under /v1/. Identifiers are 64-character lower-case hex, binary fields are lower-case hex, and resource vectors are in C, S, D, G order.

A height selects a canonical block; a hash selects any block the node stores, on a side branch too. A block's status says what the node knows of it (what a node holds of a block): valid when the node executed it and found it valid, as every canonical block is; stored when its body matches its header but the node has not executed it; invalid when its execution failed. The receipts and events of a block that is not valid are what its producer claims, checked by no one.

Manifests and storage records come with the state root they were read from. Records that belong together, such as the parts of one identity, are best read with one POST /v1/storage: separate reads may fall on either side of a new block.

A submission answers with the transaction id and known, true when the node already held it; a deferred one also with deferred, not_before and expires. Admission says only that the transaction is well formed: see the mempool and deferred transactions.

The schema is served at /openapi.json for SDKs and integrations, and /docs renders it with "Try it out" requests against your node. Mining has no REST surface; it runs over the control channel.

Pages and errors#

• limit is at most 100 and defaults to 20. Block and event pages start at height from, default 1; occurrence pages start at offset from, default 0, and say with has_more whether another page follows. These pages and /raw refuse any other query parameter with 400; the other endpoints ignore query parameters.
• Pages report the canonical tip they were read at, and block and event pages also the canonical height. An event page with contract holds up to limit blocks that have such events, and its next is the height to continue from: past height once nothing more is there. A topic needs its contract.
• A JSON page stops before 16 MiB, so it may hold fewer entries than limit; follow next to continue. An entry too large for any page is refused with an error that points to the raw block.
• /raw returns a block whole only when it fits one response, about 8 MiB. Any block can be read in slices with offset and length, at most 1 MiB each; every answer carries its offset and the block's total length.
• A transaction lookup gives each envelope's hex up to 1 MiB; a larger one has hex null and its size in the summary's encoded_bytes, and a canonical one is read from its block's slices.
• A storage read is answered whole or not at all: one whose answer would pass 16 MiB is refused. With proofs, an answer also lists, once each, the values of the records its absence proofs end at (proofs), and such a value can be a whole program's code. So a large batch with proofs that is refused is read again in smaller parts.

Errors are JSON with an error string:

What the API can and cannot tell you#

The API reports what this node has validated; it does not replace validation.

A storage response includes the state root it was read from and, when asked, the record's Merkle proof. A client that checks the proof against the state root of a header it trusts no longer has to trust the node for the value. Without a proof, it does.

Reorganizations can change recent history, and each view tells you which canonical tip it reflects.

The wiki#

The wiki is built into the executable, works offline and uses no external assets. It leads from why Ting exists, through a tour and hands-on guides, to concept pages with sub-pages and the design decisions; the API reference is one view beside it, not its purpose. Pages are served at /wiki and /wiki/{path}, such as /wiki/consensus/difficulty, and a path with a trailing slash redirects to the page.

Public by design. Reads and transaction submission need no token: programs decide who may do what. Mining, peers, shutdown and API toggling are only available through the authenticated CLI. See Access and exposure.