Skip to main content
Glama

Bitcoin Stratigraphy Enterprise Data Engine & Agent Notary Hub

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

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. Live L402 Satoshi settlement: a configured NWC wallet issues the exact-priced Lightning invoice; paid execution requires confirmed incoming settlement and an invoice-bound payment proof. Handle HTTP 402, pay explicitly, then retry the identical request with Authorization: L402 :. Invoice creation alone is not payment; unavailable verification does not authorize execution.

Input Schema

NameRequiredDescriptionDefault
hashNoRequired 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".
jobIdNoUUID 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

NameRequiredDescriptionDefault
hashYesCanonical proof or receipt hash. CID lookups return the matching receipt hash. Example: "0xabababababababababababababababababababababababababababababababab".
kindYesDistinguishes ZK proofs, signed receipts, and lifecycle-only status. Constraints: allowed values: zk-proof, dataset-receipt, context-receipt, zk-proof-status. Example: "zk-proof".
jobIdNoSubmission job identifier when an exact submitted proof payload is retained. Constraints: format: uuid. Example: "123e4567-e89b-42d3-a456-426614174000".
statusYesCurrent indexed lifecycle status. Constraints: allowed values: verified, cached, pending, invalid. Example: "verified".
otsProofNoBase64 serialized .ots proof for the bound dataset root bytes when a calendar receipt is available. Constraints: format: byte. Example: "AQID".
otsStatusNoCalendar-only or independently Bitcoin-verified status of the bound OTS receipt. Constraints: allowed values: pending_calendar, bitcoin_block_attested. Example: "pending_calendar".
timestampYesOriginal submission, verification, or receipt creation time. Constraints: format: date-time. Example: "2026-09-27T21:00:00.000Z".
meshQuorumNoWhether current mesh quorum is met for lifecycle-only lookups. Example: false.
proofPayloadNoExact retained proof input or signed receipt; do not infer missing snapshot data from a submitted proof.
attestationCountNoNIP-78 attestation count for lifecycle-only lookups. Constraints: minimum: 0. Example: 0.
provenanceVerifiedYesWhether this exact signed receipt binds the currently validated dataset strata chain; does not imply Bitcoin OTS confirmation. Example: false.
provenanceMerkleRootNoMerkle 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.

  1. Changed3 schema fields changed
    • 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\"."
  2. Changed6 schema fields changed
    • 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"
+]
  3. Changed13 schema fields changed
    • 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"
+]
  4. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds real behavioral context: bounded process-local lookup, no re-run of Groth16 verification, provenance checked against the current dataset, missing payloads are unreconstructable, and unknown identifiers 404 before payment. The large L402 settlement block adds payment-flow detail, but it is unclear whether that flow actually gates this read tool, which introduces some ambiguity rather than clarity.

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

Conciseness3/5

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

The opening sentence is front-loaded and dense in a useful way, but the trailing L402/invoice/payment-proof block runs to several sentences and may be boilerplate that does not help an agent decide whether to call this read-only lookup. Signal-to-noise is only moderate.

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

Completeness4/5

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

With an output schema present, return values need no explanation, and the description covers error behavior (404 on unknown identifiers), the hash/jobId exclusivity rule, and sibling alternatives. The only gap is the ambiguous applicability of the payment flow to this particular retrieval tool.

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%, so both parameters are fully documented in the schema. The description's enumeration of accepted identifier forms (proof/receipt hash, CID, snapshot digest, submission UUID) largely restates what the schema pattern already encodes, so the 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 and resource ('Retrieve one retained proof payload, signed receipt, or lifecycle-only status') and pins the lookup key down to exactly one of hash or jobId. An agent can distinguish it from proof.list, proof.verify, and proof.submit without reading the schema.

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

Usage Guidelines4/5

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

Explicitly routes to alternatives with conditions: 'Use proof.list to discover indexed proof hashes and proof.verify to cryptographically verify supplied proof inputs.' It also states the mutual exclusivity of hash/jobId. It stops short of stating when-not to use the tool or prerequisites for the retrieval itself.

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

All Bitcoin Stratigraphy Enterprise Data Engine & Agent Notary Hub toolsInspect
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