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.

For a receipt whose delegation certificate is signed by a contract KS256 root (a Safe, say): ask the contract whether it accepts that certificate, and return the answer as an attestation @forestrie/mcp-verify can consume offline. Reads the chain at your rpcUrl (this tool does; mcp-verify never does): eth_chainId, eth_getBlockByNumber for your block (default latest), then eth_getCode at the root and one eth_call isValidSignature(digest, signature), where digest and signature come from the receipt's certificate. Both state reads are pinned by the block's hash (EIP-1898, requireCanonical), so the hash in the attestation is the state that was read. Give the receipt, and the root as root (0x 20-byte address) or as a genesis you hold (genesis; it supplies the root when root is absent, which must then be a KS256 bootstrap root, and always supplies the chain the RPC must be on; a chain id mismatch is a problem before any further call). Returns the attestation as canonical CBOR, base64-encoded, with its fields (chain id, root address, digest, signature hash, block number, block hash, magic). Pass it to verify_receipt in mcp-verify as ks256Attestation: it then attests the certificate valid under the contract's signers at block N, which is narrower than an EOA root's offline ecrecover check; anyone with RPC can re-run the call at that block to confirm or disprove it. Refuses, with a structured problem and never an attestation, when there is no contract code at the root (an EOA root verifies by ecrecover and needs none), when the call reverts, or when the return is anything but exactly one 32-byte word, 0x1626ba7e followed by 28 zero bytes (a short return, dirty padding, extra words or an echo of the call's own data are all refused); a malformed chain id, block or hash from the RPC is an rpc_error problem. With root given beside a genesis, root is the contract asked and the genesis supplies only the expected chain (provenance.binding is explicit, chainFrom held-genesis); bindi…

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.