Fetch SCITT receipts and on-chain anchors for offline verification

Read the log's published accumulator from the univocity contract at your rpcUrl: eth_chainId, then eth_getBlockByNumber latest, then one eth_call logState(logId) at that block. The contract address and chain id come from a genesis you hold ({genesis, rpcUrl, logId}) or are given explicitly ({rpcUrl, univocity, logId, chainId?}); a chain id mismatch is reported as a problem before any call. Optionally pass forReceipt (the receipt bytes with the registered payload and its entryId, or the committed grant bytes with grant true; bytes base64): if later growth has buried that receipt's peak, so the latest state no longer holds it, the tool walks the contract's CheckpointPublished history backwards within the bounds you set in chain.history and returns the newest checkpoint that holds the peak, saying so in provenance.history; running out of range is a structured problem, history_scan_exhausted. Returns the snapshot CBOR the verifier's known-accumulator root consumes, base64-encoded, with size, block number and block hash. Provenance: chain-read. Supports: split-view under known-accumulator, against the chain rather than the operator; sealing and append-authority by inheritance from the contract's publish-time checks, not by a local signature check.

Read the log's published checkpoints from the univocity contract's CheckpointPublished events at your rpcUrl, newest first, in windows of history.chunkBlocks (default 10000) walking back from the latest block to history.fromBlock, or for at most history.maxBlocks (default 200000): one eth_getLogs per window, never an unbounded scan. The contract address and chain id come from a genesis you hold or are given explicitly, as for fetch_accumulator. Returns each checkpoint's size, accumulator, block number, block hash and transaction hash, plus the same checkpoint as a known-accumulator snapshot (base64) you can keep and later pass to verify_fetched_receipt as supplied bytes; and scannedFrom, scannedTo and the number of requests made. For capture: the contract keeps only its latest state, and a receipt whose peak later growth has buried verifies only against a checkpoint that still holds that peak, so keep the ones you need. Provenance: chain-read. Supports: as fetch_accumulator, split-view under known-accumulator against the chain rather than the operator; sealing and append-authority by inheritance from the contract's publish-time checks, not by a local signature check.

GET {baseUrl}/api/forest/{logId}/genesis: the forest's genesis document as CBOR, base64-encoded, with what it carries decoded: the chain binding (univocity contract address, chain id, forest log id) and, for an ES256 forest, the bootstrap public key as bootstrapKeyXy (x‖y hex). Both are read from these bytes, so they stand exactly where the copy stands. For capture: obtain it once, keep it, and pass it as bytes from then on. A copy obtained at check time is not the genesis trust root as intended, and its chain binding and bootstrap key are likewise the operator's claim today; keep the copy from registration, or cross-check them against a source you trust independently. Provenance: fetched. Supports: sealing, as known-log-key with the key this copy carries.

GET a receipt: either by receiptUrl (as returned by query_registration) or by {baseUrl, bootstrapLogId, logId, massifHeight, entryId}. Returns the receipt bytes base64-encoded, the verifier's decoding of them, and receiptLogId: the log the receipt's delegation certificate names, which is the operator's statement like the rest of the receipt. A 404 is the structured problem not_found carrying the operator's own title (for example 'Entry receipt not found (checkpoint missing)' for a wrong massif height); it is never reported as pending, because a receipt URL the operator holds nothing at does not fill in by waiting. Provenance: fetched. Supports: none on its own; a receipt is the operator's claim, so verify it under a trust root you hold (or use verify_fetched_receipt).

GET {baseUrl}/.well-known/scitt-configuration: the transparency service's self-description (service id, base URL, supported algorithms), returned as JSON. Provenance: fetched. Supports: none of the four questions; this is what the operator says about itself.

One GET of {baseUrl}/logs/{bootstrapLogId}/{logId}/entries/{contentHash}, where contentHash is the hex sha256 of the signed statement bytes. Returns pending (with retryAfterMs when the server said so) or the receipt's URL, which includes the massif height, and the entry id. pending is the operator's answer for any content hash its sequencing index does not hold yet, including one that was never registered: the operator does not distinguish the two, so a retry only helps for a statement you know was submitted. receipt-available is the index's answer, not proof the receipt is written: fetch_receipt is the check, and a 404 there is not_found, never pending. Never polls: call again yourself if you want to. Provenance: fetched. Supports: none of the four questions; this is registration status.

Fetch a receipt (as fetch_receipt) and verify it with @forestrie/mcp-verify's core under a trust root you supply as bytes (genesis, keyXy, accumulator, or checkpoints; each {b64} or {path}) or under an accumulator read from the chain in this call ({root: 'known-accumulator', chain: {genesis, rpcUrl, logId?} or {rpcUrl, univocity, logId?, chainId?}}). A genesis fetched in the same call is never the root. The result is the verifier's own: stages, the four questions (sealing, split-view, append-authority, attribution; not_answered_by_this_root is a real answer) and diagnostics, passed through unaltered, plus receipt_fetched_from_operator always and root_read_from_chain when the chain path was taken. If the latest chain state no longer holds the receipt's peak, the chain path walks CheckpointPublished history backwards within the bounds in chain.history (default 200000 blocks in windows of 10000, one eth_getLogs each) and verifies under the newest checkpoint that holds it, adding root_read_from_chain_history; running out of range is the structured problem history_scan_exhausted. The log read is the one you name, in chain.logId or in the receipt coordinates; if the receipt's delegation certificate names a different log, the result adds receipt_log_id_mismatch and the call still uses yours. If you name none, the call uses the certificate's log id and says so in provenance.logId, with source receipt-delegation-certificate. Supply payload bytes and the entry id to have attribution answered. The genesis root's offline walk resolves one delegation hop from the forest root: a receipt from a log further down the grant chain (the verifier's own publications log is a grandchild) fails under a supplied genesis with delegation_invalid, and the result adds genesis_root_reaches_direct_delegates_only to say that this is the walk's limit, not a finding about the receipt; verify such a receipt under known-log-key or known-accumulator.