bitcoin-stratigraphy

by app.replit.bitcoin-stratigraphy-dashboard--charlesstrogish

Get Proof or Receipt by Hash

proof.get_by_hash

Read-onlyIdempotent

Retrieve one retained proof payload, signed receipt, or lifecycle-only status using exactly one known hash (proof or receipt hash, CID, snapshot digest, or submission UUID) or jobId (submission UUID). Looks up bounded process-local records without re-running Groth16 proof verification; receipt provenance may be checked against the current dataset, and missing payloads cannot be reconstructed. Use proof.list to discover indexed proof hashes and proof.verify to cryptographically verify supplied proof inputs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`hash`	No	Required when jobId is absent: proof/receipt 64-hex hash (optional 0x), decimal snapshot digest, IPFS CID, or UUID submission job ID; unknown identifiers return 404. Constraints: pattern: ^(?:(?:0x)?[0-9a-fA-F]{64}\|Qm[1-9A-HJ-NP-Za-km-z]{44}\|b[a-z2-7]{20,}\|\d{1,77}\|[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$. Example: "0xabababababababababababababababababababababababababababababababab".
`jobId`	No	UUID returned by proof.submit (e.g. '123e4567-e89b-42d3-a456-426614174000'); use instead of hash, never together. Constraints: format: uuid. Example: "123e4567-e89b-42d3-a456-426614174000".

Output Schema

TableJSON Schema

Name	Required	Description
`hash`	Yes	Canonical proof or receipt hash. CID lookups return the matching receipt hash. Example: "0xabababababababababababababababababababababababababababababababab".
`kind`	Yes	Distinguishes ZK proofs, signed receipts, and lifecycle-only status. Constraints: allowed values: zk-proof, dataset-receipt, context-receipt, zk-proof-status. Example: "zk-proof".
`jobId`	No	Submission job identifier when an exact submitted proof payload is retained. Constraints: format: uuid. Example: "123e4567-e89b-42d3-a456-426614174000".
`status`	Yes	Current indexed lifecycle status. Constraints: allowed values: verified, cached, pending, invalid. Example: "verified".
`otsProof`	No	Base64 serialized .ots proof for the bound dataset root bytes when a calendar receipt is available. Constraints: format: byte. Example: "AQID".
`otsStatus`	No	Calendar-only or independently Bitcoin-verified status of the bound OTS receipt. Constraints: allowed values: pending_calendar, bitcoin_block_attested. Example: "pending_calendar".
`timestamp`	Yes	Original submission, verification, or receipt creation time. Constraints: format: date-time. Example: "2026-09-27T21:00:00.000Z".
`meshQuorum`	No	Whether current mesh quorum is met for lifecycle-only lookups. Example: false.
`proofPayload`	No	Exact retained proof input or signed receipt; do not infer missing snapshot data from a submitted proof.
`attestationCount`	No	NIP-78 attestation count for lifecycle-only lookups. Constraints: minimum: 0. Example: 0.
`provenanceVerified`	Yes	Whether this exact signed receipt binds the currently validated dataset strata chain; does not imply Bitcoin OTS confirmation. Example: false.
`provenanceMerkleRoot`	No	Merkle root bound in the signed receipt when the current dataset chain matches. Constraints: pattern: ^[0-9a-f]{64}$. Example: "abababababababababababababababababababababababababababababababab".

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 28, 2026

changedInput schema / description

Previous value: -"Look up a proof hash, signed receipt hash or CID, decimal snapshot digest, or proof submission job ID. Unknown identifiers return HTTP 404 before payment."New value: +"Supply exactly one of hash or jobId to retrieve an exact retained proof/receipt or lifecycle state. Unknown identifiers return HTTP 404 before payment."

changedInput schema / properties / hash / description

Previous value: -"Cryptographic hash, snapshot digest, IPFS CID, or submission job ID to query. Constraints: pattern: ^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,}|\\d{1,77}|[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$. Example: \"0xabababababababababababababababababababababababababababababababab\"."New value: +"Required when jobId is absent: proof/receipt 64-hex hash (optional 0x), decimal snapshot digest, IPFS CID, or UUID submission job ID; unknown identifiers return 404. Constraints: pattern: ^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,}|\\d{1,77}|[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$. Example: \"0xabababababababababababababababababababababababababababababababab\"."

changedInput schema / properties / jobId / description

Previous value: -"UUID returned by proof.submit; use instead of hash. Constraints: format: uuid. Example: \"123e4567-e89b-42d3-a456-426614174000\"."New value: +"UUID returned by proof.submit (e.g. '123e4567-e89b-42d3-a456-426614174000'); use instead of hash, never together. Constraints: format: uuid. Example: \"123e4567-e89b-42d3-a456-426614174000\"."

Changed6 schema fields changedSep 28, 2026

changedOutput schema / examples

Previous value: -[
-  {
-    "hash": "0xabababababababababababababababababababababababababababababababab",
-    "kind": "zk-proof",
-    "proofPayload": {
-      "proof": {
-        "pi_a": [
-          "1"
-        ]
-      },
-      "publicSignals": [
-        "1",
-        "2",
-        "3",
-        "4",
-        "5"
-      ]
-    },
-    "status": "verified",
-    "timestamp": "2026-09-27T21:00:00.000Z"
-  }
-]New value: +[
+  {
+    "hash": "0xabababababababababababababababababababababababababababababababab",
+    "kind": "zk-proof",
+    "proofPayload": {
+      "proof": {
+        "pi_a": [
+          "1"
+        ]
+      },
+      "publicSignals": [
+        "1",
+        "2",
+        "3",
+        "4",
+        "5"
+      ]
+    },
+    "provenanceVerified": false,
+    "status": "verified",
+    "timestamp": "2026-09-27T21:00:00.000Z"
+  }
+]

addedOutput schema / properties / otsProof

Added value: +{
+  "description": "Base64 serialized .ots proof for the bound dataset root bytes when a calendar receipt is available. Constraints: format: byte. Example: \"AQID\".",
+  "example": "AQID",
+  "examples": [
+    "AQID"
+  ],
+  "format": "byte",
+  "type": "string"
+}

addedOutput schema / properties / otsStatus

Added value: +{
+  "description": "Calendar-only or independently Bitcoin-verified status of the bound OTS receipt. Constraints: allowed values: pending_calendar, bitcoin_block_attested. Example: \"pending_calendar\".",
+  "enum": [
+    "pending_calendar",
+    "bitcoin_block_attested"
+  ],
+  "example": "pending_calendar",
+  "examples": [
+    "pending_calendar"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / provenanceMerkleRoot

Added value: +{
+  "description": "Merkle root bound in the signed receipt when the current dataset chain matches. Constraints: pattern: ^[0-9a-f]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".",
+  "example": "abababababababababababababababababababababababababababababababab",
+  "examples": [
+    "abababababababababababababababababababababababababababababababab"
+  ],
+  "pattern": "^[0-9a-f]{64}$",
+  "type": "string"
+}

addedOutput schema / properties / provenanceVerified

Added value: +{
+  "description": "Whether this exact signed receipt binds the currently validated dataset strata chain; does not imply Bitcoin OTS confirmation. Example: false.",
+  "example": false,
+  "examples": [
+    false
+  ],
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "kind",
-  "hash",
-  "status",
-  "timestamp"
-]New value: +[
+  "kind",
+  "hash",
+  "status",
+  "timestamp",
+  "provenanceVerified"
+]

Changed13 schema fields changedSep 27, 2026

changedInput schema / description

Previous value: -"Look up a retained proof by SHA-256 proof hash, or a signed dataset anchor by receipt hash or exact CID. Unknown or evicted payloads return HTTP 404 before payment."New value: +"Look up a proof hash, signed receipt hash or CID, decimal snapshot digest, or proof submission job ID. Unknown identifiers return HTTP 404 before payment."

addedInput schema / oneOf

Added value: +[
+  {
+    "required": [
+      "hash"
+    ]
+  },
+  {
+    "required": [
+      "jobId"
+    ]
+  }
+]

changedInput schema / properties / hash / description

Previous value: -"Cryptographic hash or IPFS CID of the target proof or receipt. Constraints: pattern: ^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,})$. Example: \"0xabababababababababababababababababababababababababababababababab\"."New value: +"Cryptographic hash, snapshot digest, IPFS CID, or submission job ID to query. Constraints: pattern: ^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,}|\\d{1,77}|[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$. Example: \"0xabababababababababababababababababababababababababababababababab\"."

changedInput schema / properties / hash / pattern

Previous value: -"^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,})$"New value: +"^(?:(?:0x)?[0-9a-fA-F]{64}|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,}|\\d{1,77}|[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"

addedInput schema / properties / jobId

Added value: +{
+  "description": "UUID returned by proof.submit; use instead of hash. Constraints: format: uuid. Example: \"123e4567-e89b-42d3-a456-426614174000\".",
+  "example": "123e4567-e89b-42d3-a456-426614174000",
+  "examples": [
+    "123e4567-e89b-42d3-a456-426614174000"
+  ],
+  "format": "uuid",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "hash"
-]
```

changedOutput schema / description

Previous value: -"A payload retained in bounded process memory. Submitted proof coordinates and signals do not imply the original signed snapshot is archived; verification lookups include their original data. Signed dataset anchors are receipts, not ZK proofs."New value: +"Exact retained proof or signed receipt, or lifecycle-only status when the original payload is unavailable. No payload is reconstructed from a digest."

addedOutput schema / properties / attestationCount

Added value: +{
+  "description": "NIP-78 attestation count for lifecycle-only lookups. Constraints: minimum: 0. Example: 0.",
+  "example": 0,
+  "examples": [
+    0
+  ],
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / jobId

Added value: +{
+  "description": "Submission job identifier when an exact submitted proof payload is retained. Constraints: format: uuid. Example: \"123e4567-e89b-42d3-a456-426614174000\".",
+  "example": "123e4567-e89b-42d3-a456-426614174000",
+  "examples": [
+    "123e4567-e89b-42d3-a456-426614174000"
+  ],
+  "format": "uuid",
+  "type": "string"
+}

changedOutput schema / properties / kind / description

Previous value: -"Distinguishes a ZK proof from a signed Bitcoin-tip dataset receipt. Constraints: allowed values: zk-proof, dataset-receipt. Example: \"zk-proof\"."New value: +"Distinguishes ZK proofs, signed receipts, and lifecycle-only status. Constraints: allowed values: zk-proof, dataset-receipt, context-receipt, zk-proof-status. Example: \"zk-proof\"."

changedOutput schema / properties / kind / enum

Previous value: -[
-  "zk-proof",
-  "dataset-receipt"
-]New value: +[
+  "zk-proof",
+  "dataset-receipt",
+  "context-receipt",
+  "zk-proof-status"
+]

addedOutput schema / properties / meshQuorum

Added value: +{
+  "description": "Whether current mesh quorum is met for lifecycle-only lookups. Example: false.",
+  "example": false,
+  "examples": [
+    false
+  ],
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "kind",
-  "hash",
-  "status",
-  "timestamp",
-  "proofPayload"
-]New value: +[
+  "kind",
+  "hash",
+  "status",
+  "timestamp"
+]

AddedSep 27, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive behavior on top: records are bounded and process-local, Groth16 verification is NOT re-run, receipt provenance may be re-checked against the current dataset, and missing payloads cannot be reconstructed. These constraints materially change how an agent should interpret a hit or a miss.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the retrieval semantics and ending with the alternative-tool routing, with no filler. Sentences are densely packed with clauses, which costs a little readability but each clause carries real information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return structure need not be explained; the description covers lookup scope, error behavior (404 before payment), verification boundary, and sibling alternatives. Nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already enumerates the accepted identifier forms, the mutual exclusivity ('never together'), and the 404-on-unknown behavior. The description restates that the two identifiers are alternatives but adds no format, precedence, or edge-case detail the schema lacks, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (retrieve) and the exact resource set (retained proof payload, signed receipt, lifecycle-only status), keyed by one of two named identifier types. It also names the two siblings an agent might confuse it with (proof.list, proof.verify), so the tool is distinguishable without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use proof.list to discover indexed hashes, use proof.verify to cryptographically verify supplied proof inputs, and use this tool only for lookup by a known identifier. The 'exactly one of hash or jobId' condition is stated up front, so when-to-use and when-not-to-use are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All bitcoin-stratigraphy tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?