A
licenseNot graded
qualityD
maintenanceProvides a trust layer for AI agents with identity, reputation, payments, and discovery via 92 API endpoints as MCP tools, leveraging Nostr-native infrastructure.
MIT
Bitcoin Stratigraphy Enterprise Data Engine & Agent Notary Hub
Server Details
Enterprise-grade L402 data engine and cryptographic notary hub for autonomous AI swarms.
This engine provides the required "State-Anchored AI" data layer for EU AI Act Article 12 compliance, delivering a mathematically un-cheat-able, cryptographically verifiable chain-of-custody for agent decisions to eliminate hallucinations.
Key Enterprise & Swarm Capabilities:
Zero-Trust Client Verification: Air-gapped, browser-based verifier allows corporate risk teams to mathematically validate Ed25519 signatures and RFC 6962 Merkle inclusion proofs offline, eliminating the need to trust our server backend.
Enterprise Security & NIP-98 Kill Switch: Eliminates indirect prompt injection via strict NIP-98 identity binding. Includes a live Revocation Registry (CRL) allowing Swarm Commanders to instantly sever compromised agent keys from the network.
Corporate Observability (SEP-414): Native W3C Trace Context integration seamlessly pipes agent cryptographic W3C receipts directly into existing enterprise dashboards like Splunk and Datadog.
High-Velocity Bulk L402 Scaling: Supports pre-authorized Macaroon blocks (e.g., 25,000-sat bulk purchases) for frictionless, zero-latency execution, allowing agent swarms to scale to 500,000+ satoshis daily without network bottlenecking.
EU AI Act Compliance Notary:
Intercepts high-frequency agent ReAct loops and anchors cryptographic execution traces to the thermodynamic truth of the Bitcoin base layer via OpenTimestamps.
Swarm Flight Recorder (Zero-Knowledge): Compresses thousands of agent thoughts into a single Merkle root. Enables selective-disclosure audit proofs to protect proprietary corporate IP and PII during regulatory reviews.
Licensing & Exemption:
Publicly dual-licensed under AGPLv3. To protect proprietary multi-agent logic and closed-source model weights from forced open-source disclosure, enterprises must secure the $250,000/annual Commercial Enterprise Exemption.
Architected by Charles R. Strogish.
Protocol Endpoints:
GET /api/v1/cost — Pre-flight L402 pricing, dynamic tier discovery, and bulk macaroon settlement asset options.
GET /api/v1/stratigraphy — Nostr-signed thermodynamic Bitcoin dataset.
GET /api/v1/stratigraphy/stream — Real-time telemetry event stream.
Ownership verified
- Status
- Healthy
- Uptime
- 98.6% over 41 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4/5.0
Scored across 16 tools
Disambiguation4/5
Tool namespaces (mesh, payment, proof, stratigraphy, workflow) cleanly separate domains, and most tools within each have a distinct action. However, proof.notarize, proof.submit, and proof.ground all produce/create attestations of varying kinds and could be confused without careful reading of the descriptions.
Naming Consistency4/5
A predictable namespace.verb pattern (mesh.broadcast, proof.submit, stratigraphy.list) is used throughout. The only deviation is that stratigraphy tools use a 'get' prefix (stratigraphy.get, get_range) while mesh/payment use terse verbs, a minor cosmetic inconsistency.
Tool Count4/5
16 tools is reasonable for a combined data-retrieval, proof-notarization, and mesh server, with each tool earning its place. It sits just above the comfortable 3-15 range but is not bloated.
Completeness4/5
Broad lifecycle coverage exists: proof discovery (list), creation (notarize/submit), retrieval (get_by_hash), and verification (verify), plus full stratigraphy retrieval variations and a composite audit workflow. Missing proof revocation/deletion is a minor gap agents can work around.
Available Tools
16 toolsmesh.broadcastBroadcast Telemetry Snapshot to MeshAInspect
Broadcast local telemetry snapshots and stratigraphy receipts to peer nodes across the Stratigraphy mesh network. Use this tool to propagate sovereign node state, sync multi-agent clusters, or announce new block validation events. Use mesh.get_status to inspect local peer connectivity before broadcasting. Requires network authorization or L402 settlement token. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | UTC date selector for an existing telemetry record submitted for peer attestation, not a caller-supplied record object; for example, {"date":"2026-09-09"}. | |
| agentEvent | No | Optional NIP-01 kind 20079 signature over JSON.stringify({networkId,date}) for this exact date selector. The signer must have a trusted mesh attestation. Example: a complete signed event with a matching date. | |
| signalType | Yes | Enforces the broadcast event schema; must be telemetry_snapshot to trigger peer validation, not an arbitrary signal. Constraints: allowed values: telemetry_snapshot. Example: "telemetry_snapshot". |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | Yes | UTC date of the distributed telemetry record. Constraints: format: date. Example: "2026-09-09". |
| networkId | Yes | Mesh network identifier committed in peer attestations. Example: "bitcoin-stratigraphy-mainnet-v1". |
| merkleRoot | Yes | Merkle root of local and peer attestation event identifiers. Constraints: pattern: ^[0-9a-f]{64}$. Example: "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd". |
| signalType | Yes | Signal distributed to configured peers. Constraints: allowed values: telemetry_snapshot. Example: "telemetry_snapshot". |
| agentPubkey | No | Present only when an agent-signed session was verified and accepted by the peer mesh. Constraints: pattern: ^[0-9a-f]{64}$. Example: "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd". |
| snapshotDigest | Yes | SHA-256 digest of the canonical mesh-encoded signed snapshot. Constraints: pattern: ^[0-9a-f]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
| quorumThreshold | Yes | Required total attestation count, including this node. Constraints: minimum: 1. Example: 2. |
| peerAttestations | Yes | Number of remote pinned peers whose signatures were verified; excludes this node. Constraints: minimum: 1. Example: 1. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a write, open-world, non-idempotent operation, and the description goes well beyond that: it requires network authorization or an L402 settlement token, spells out the HTTP 402 -> pay -> retry-with-Authorization flow, and warns that invoice creation alone is not payment and unverified settlement does not authorize execution. This is exactly the kind of behavioral detail annotations cannot convey.
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?
Purpose and routing are front-loaded, and every sentence is functional. The L402 passage is dense and somewhat run-on, but each clause carries a necessary constraint rather than filler.
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?
With an output schema present and full schema coverage, the description only needs to cover context the structured fields cannot: authorization, payment settlement semantics, and failure/retry behavior, all of which it does thoroughly.
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 documents payload.date, agentEvent, and the signalType enum in depth. The description does not add syntax or format meaning beyond what the schema provides, so the baseline of 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?
The first sentence states a specific verb and resource: broadcast telemetry snapshots and stratigraphy receipts to peer nodes across the mesh. It is clearly distinguishable from sibling read tools like mesh.get_status and the stratigraphy.get* family.
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?
It enumerates concrete use cases (propagate sovereign node state, sync multi-agent clusters, announce block validation events) and explicitly names mesh.get_status as the prerequisite inspection step before broadcasting. No alternative is left ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mesh.get_statusGet Mesh StatusARead-onlyIdempotentInspect
Inspect local mesh network topology, active peer connections, and relay synchronization state. Returns connected peer counts, latency figures, and gossip protocol health. Use this tool to check node network connectivity prior to broadcasting or querying distributed telemetry. Read-only and idempotent. 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| nodePubkey | Yes | Lowercase hexadecimal Nostr public key identifying this mesh node. Example: "f72cc555ec2948fdc4b5b2c2778821499ea8ce2b8569b68675899e296d3ff253". |
| topologyHealth | Yes | Current consensus topology health classification. Constraints: allowed values: healthy, degraded, isolated. Example: "healthy". |
| activePeerCount | Yes | Number of recently validated nodes, including the local node. Constraints: minimum: 1. Example: 3. |
| quorumThreshold | Yes | Minimum unique node attestations required for consensus. Constraints: minimum: 1. Example: 2. |
| configuredPeerCount | Yes | Number of remotely configured trusted peers. Constraints: minimum: 0. Example: 2. |
| crossValidationSuccessRate | Yes | Lifetime ratio of successful peer cross-validation attempts. Constraints: minimum: 0; maximum: 1. Example: 0.98. |
| averagePropagationLatencyMs | Yes | Mean round-trip propagation latency for successful attestations. Constraints: minimum: 0. Example: 42.7. |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds return-value context (peer counts, latency, gossip health) and an L402 payment flow, but much of the latter is boilerplate about payment rather than behavior specific to this inspection tool. It does not disclose rate limits or auth beyond payment.
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 first three sentences are concise and front-loaded. However, the L402 settlement block spans four dense sentences and is largely generic payment boilerplate that buries the core purpose, reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 values needn't be explained, yet the description still lists them. The L402 flow is described, but without indicating whether it applies to this specific read-only tool or is a general requirement; an agent may be confused about when payment is actually needed for a status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. The schema description already notes 'Pass {}' and rejects extra args, which the tool description does not conflict with; no additional parameter semantics needed.
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?
The description uses a specific verb ('Inspect') with a clearly scoped resource (local mesh network topology, peer connections, relay sync state). It is distinguishable from siblings like mesh.broadcast, which is a write operation, and from payment/proof tools.
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 states when to use: 'to check node network connectivity prior to broadcasting or querying distributed telemetry,' and 'Read-only and idempotent.' No exclusions or named alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payment.get_infoQuery MCP Prices or Verify Payment SettlementAInspect
Query MCP pricing parameters (action='query', the default) or verify authenticated settlement (action='settle' with a payment hash and either an L402 preimage or Base transaction hash). Use query for price discovery before calling paid tools; use settle to check payment status, not to issue an invoice. Macaroons and Lightning invoices are issued dynamically via HTTP 402 challenges with bounded expiration; operator-only admin operations are intentionally omitted. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | query (default) discovers prices; settle verifies authenticated payment. Constraints: allowed values: query, settle. Example: "query". | query |
| txHash | No | Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: "0xabababababababababababababababababababababababababababababababab". | |
| preimage | No | Optional L402 preimage, NWC_LOOKUP, or UUID hint; the issued macaroon and exact merchant settlement remain required. Constraints: pattern: ^([0-9a-fA-F]{64}|[0-9a-fA-F]{8}(-[0-9a-fA-F]{4}){3}-[0-9a-fA-F]{12}|NWC_LOOKUP|nwc_lookup)$. Example: "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd". | |
| toolName | No | Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.get_digest' or 'proof.verify'); supported legacy aliases are also accepted and resolve to canonical names. When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name or supported legacy alias. Constraints: minLength: 1. Example: "stratigraphy.get_digest". | |
| paymentHash | No | L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: "abababababababababababababababababababababababababababababababab". | |
| paymentMacaroon | No | Original invoice macaroon, separate from this tool's paid access credential. Constraints: minLength: 1; maxLength: 8192. Example: "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ". |
Output Schema
| Name | Required | Description |
|---|---|---|
| x402 | No | Base mainnet USDC x402 exact terms; present only when authenticated CDP settlement is configured. |
| verified | No | Whether the signed, server-bound payment was verified or settled. Example: true. |
| challenge | No | HTTP payment challenge and response fields. |
| perToolSats | No | Current advertised canonical tool prices in sats; optional toolName narrows this map. |
| settlementToken | No | Verified payment claims, not a bearer token or a grant of tool access. |
| activeAuthSchemes | No | Authentication schemes for paid MCP calls. Only stratigraphy.list and proof.list execute free. Example: ["L402"]. |
| standardInvoiceSats | No | Standard paid MCP execution price. Catalog and status lookups may cost less; free tools cost zero. Example: 250. |
| invoiceExpirySeconds | No | Default expiry for both the issued Lightning invoice and its path-bound macaroon. Constraints: minimum: 1. Example: 3600. |
| macaroonRequirements | No | A valid payment proof must match the bound invoice, provider, amount, path, expiry and request quota. proof.attenuate requires payment and a valid parent token. |
| acceptedPaymentMethods | No | Supported MCP payment method. Example: ["Lightning L402"]. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, but the description adds substantial context the annotations cannot: dynamic HTTP 402 macaroon/invoice issuance with bounded expiration, an NWC wallet issuing the exact-priced invoice, settlement requiring confirmed incoming payment, and the warning that 'invoice creation alone is not payment.' Minor ambiguity remains about whether 'settle' is pure verification or can trigger paid execution, since it says settle 'check[s] payment status' while the schema says 'verify or execute.'
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?
Well front-loaded: the query/settle split lands in sentence one, and each following sentence adds a distinct fact (expiration, admin omission, settlement mechanics, 402 retry). It is dense rather than padded, though the HTTP 402 'pay explicitly, then retry with Authorization' passage describes consuming paid tools generally rather than this tool's own behavior, which dilutes focus slightly.
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?
Given a complex, security-sensitive payment tool with a oneOf schema, an output schema (so return values need not be restated), and rich annotations, the description covers purpose, routing, the 402 handshake, and the proof requirements. Nothing an agent needs to invoke either action correctly appears to be 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%, so the parameters, patterns, and the query/settle oneOf are fully documented structurally. The description synthesizes the settle input requirement ('a payment hash and either an L402 preimage or Base transaction hash'), which is marginally clearer than the schema, but it adds little that the schema does not already state, so the baseline of 3 is right.
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?
The first sentence names two specific verbs and their resources: query MCP pricing parameters (default) versus verify authenticated settlement, and immediately qualifies the settle form with its required inputs. It clearly separates this payment utility from the proof./stratigraphy./mesh. siblings, which handle artifacts rather than pricing/payment.
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?
Explicit when-to-use for each action: 'query' is for price discovery before calling paid tools, 'settle' is for checking payment status, plus an explicit exclusion ('not to issue an invoice'). It also states the operator-only admin surface is intentionally omitted, which tells the agent what it cannot get here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.attenuateAttenuate a MacaroonARead-onlyIdempotentInspect
Attenuate an authentic, unexpired L402 parent macaroon by appending strictly formatted first-party caveats. expiresAt (UTC instant) or ttlSeconds adds time < YYYY-MM-DDTHH:MM:SS.sssZ: redemption at or after that instant is rejected with HTTP 401. tools adds rpc = tool[,tool...]: any tool not listed exactly is rejected with HTTP 403, and every listed tool must already be authorized by the parent. caveats accepts those forms plus max_target, max_requests, allowed_path, and legacy time_before or allowed_tools restrictions. At least one restriction is required. Requires its own L402 authorization; the parent's payment proof remains required for child redemption. Delegation cannot widen authority or reset an inherited quota. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | No | Optional exact MCP tool targets (1-16 unique names). Appends one `rpc = tool[,tool...]` caveat; the child is refused for every other tool. Matching is exact, so a legacy alias is a different name. Each tool must already be authorized by the parent: an MCP L402 credential authorizes the single tool named in its allowed_path. Constraints: minItems: 1; maxItems: 16. Example: ["stratigraphy.get_diff"]. | |
| caveats | No | Optional restriction caveats to append, normalized to canonical form: 'time < 2026-12-31T23:59:59Z', 'rpc = stratigraphy.get_diff', 'max_target = 870000', 'max_requests = 1', 'allowed_path = /mcp/tools/stratigraphy.get_diff', and legacy 'time_before = 2026-12-31' or 'allowed_tools = stratigraphy.get,stratigraphy.get_digest'. Constraints: maxItems: 16. Example: ["max_target = 870000"]. | |
| macaroon | Yes | Required authentic, unexpired parent L402 macaroon (1-8192 characters); added restrictions can only narrow its scope. Constraints: minLength: 1; maxLength: 8192. Example: "base64url-parent-macaroon". | |
| expiresAt | No | Optional absolute expiration boundary as a future UTC instant (YYYY-MM-DDTHH:MM:SSZ, optionally with .sss milliseconds). Appends `time < YYYY-MM-DDTHH:MM:SS.sssZ`; it cannot extend the parent's expiry. Mutually exclusive with ttlSeconds. Constraints: format: date-time; pattern: ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d{3})?Z$. Example: "2026-12-31T23:59:59Z". | |
| ttlSeconds | No | Optional positive integer TTL of 1-2592000 seconds (e.g. 3600). Appends `time <` at the current time plus ttlSeconds; it cannot extend the parent's expiry. Mutually exclusive with expiresAt. Constraints: minimum: 1; maximum: 2592000. Example: 3600. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | Successful attenuation status. Example: "attenuated". |
| issuedAt | Yes | UTC issuance timestamp. Constraints: format: date-time. Example: "2026-09-27T21:00:00.000Z". |
| appliedCaveats | Yes | New canonical caveats appended to the parent; inherited caveats are preserved inside the token. Example: ["max_target=870000","time < 2026-12-31T23:59:59.000Z","rpc = stratigraphy.get_diff"]. |
| attenuatedMacaroon | Yes | Encoded child subscription macaroon. Treat as a bearer credential. Example: "base64url-child-macaroon". |
TDQS
A3.9/5.0
Behavior4/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 substantial context on top: HTTP 401 on expiry, HTTP 403 on unlisted tools, the rule that child authority cannot widen or reset inherited quota, and the auth-retry protocol. However, the 'Live L402 Satoshi settlement... issues the exact-priced Lightning invoice' passage is generic payment boilerplate that sits awkwardly next to the schema's statement that no invoice is issued, muddying rather than clarifying behavior.
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 purpose and caveat-formats material is well front-loaded, but the single trailing block runs long and folds in server-wide Lightning settlement boilerplate ('paid execution requires confirmed incoming settlement', 'Invoice creation alone is not payment') that is tangential to an attenuation call and partly conflicts with the schema. Trimming that boilerplate would sharpen an otherwise dense description.
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?
An output schema exists, so return values need no explanation, and the description covers authorization, every caveat form, error codes, and the narrowing guarantee. One residual gap: it states the call 'requires its own L402 authorization' while the schema says no invoice is issued, leaving an agent unsure whether this specific call triggers payment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: it explains that expiresAt/ttlSeconds compile to a `time <` caveat, that `tools` compiles to `rpc = tool[,tool...]` with exact matching (so a legacy alias is a different name), that caveats accept additional forms plus legacy aliases, and that at least one restriction is mandatory. That cross-parameter constraint is not derivable from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource and defines the mechanism precisely: 'Attenuate an authentic, unexpired L402 parent macaroon by appending strictly formatted first-party caveats.' An agent immediately knows this derives a narrowed child credential rather than verifying or notarizing one. It does not explicitly contrast itself against siblings like proof.verify or proof.ground, so sibling differentiation is implicit rather than stated.
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?
Clear operational context is given: at least one restriction (expiresAt/ttlSeconds, tools, or caveats) is required, expiresAt and ttlSeconds are mutually exclusive, and the call requires its own L402 authorization. The HTTP 402 pay-then-retry flow is spelled out. It stops short of saying when-not to use it (e.g., when to prefer proof.ground or proof.notarize), so no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.get_by_hashGet Proof or Receipt by HashARead-onlyIdempotentInspect
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.
| 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
| 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". |
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.
proof.groundGround Agent Context in Bitcoin StateAInspect
Ground an AI agent context window directly in immutable Bitcoin consensus state to eliminate temporal and factual hallucinations. Binds input claims to real-time proof-of-work difficulty, block height, and thermodynamic entropy. Use this tool during critical reasoning steps or pre-execution checks when agent outputs require deterministic verification against physical reality. Use proof.notarize to timestamp arbitrary digests or stratigraphy.get for raw metrics. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | No | Target IPFS CID or 32-byte hex dataset hash anchored directly to the live Bitcoin block height. Example: a 64-character lowercase hex digest. | |
| agentId | No | Unique agent instance identifier named in the signed attestation receipt; trimmed to 1-256 characters. Constraints: minLength: 1; maxLength: 256. Example: "research-agent-7". | |
| context | No | Optional JSON metadata object bound into the signed receipt tuple for additional execution context. Example: {"source":"dataset"}. | |
| metadata | No | Optional non-secret JSON key-value metadata bound to the signed receipt; serialized size must not exceed 16 KiB. Example: {"topic":"difficulty-adjustment"}. | |
| contextHash | No | 64-character hexadecimal SHA-256 digest binding the agent's prompt or execution state to the current block tip; normalized to lowercase. Constraints: minLength: 64; maxLength: 64; pattern: ^[0-9a-fA-F]{64}$. Example: "4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f". | |
| nostrEventId | No | Optional Nostr event ID linked into the signed receipt payload to bind off-chain publications to the block tip. Example: a 64-character lowercase hex event ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
| receipt | Yes | Full signed context receipt or signed dataset receipt wrapper. Example: a signed Bitcoin-tip anchor. |
| otsProof | No | Base64 serialized .ots proof of the 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 OTS receipt. Constraints: allowed values: pending_calendar, bitcoin_block_attested. Example: "pending_calendar". |
| provenanceVerified | Yes | Whether this signed receipt binds the current verified dataset chain, not whether Bitcoin has attested its OTS proof. Example: true. |
| provenanceMerkleRoot | No | Dataset chain root signed in the receipt, when the referenced dataset still matches. Constraints: pattern: ^[0-9a-f]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
TDQS
A4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only declaring readOnly=false, openWorld=true and non-idempotent, the description carries real added weight: a configured NWC wallet issues an exact-priced Lightning invoice, paid execution requires confirmed incoming settlement plus an invoice-bound payment proof, and the agent is told to handle HTTP 402, pay, then retry the identical request with an Authorization header. It also warns that invoice creation alone is not payment and that unavailable verification does not authorize execution — concrete auth, cost, and retry behavior beyond the annotations.
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?
Purpose and routing are front-loaded, and the L402 paragraph earns its place by specifying a non-obvious payment protocol. However, promotional phrasing ('eliminate temporal and factual hallucinations', 'thermodynamic entropy', 'physical reality') is filler that does not help an agent select or invoke the tool.
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, the description needn't explain return values, and it covers purpose, alternatives, and the payment/auth flow that an agent must understand to call it successfully. Only minor gaps remain around failure modes other than 402 or the exact shape of the signed receipt, which the output schema likely covers.
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 itself documents the mutual-exclusion modes (contextHash+agentId vs cid) and each field's constraints, so the schema does the heavy lifting. The description adds little parameter-level detail beyond that, consistent with the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (ground) and resource (an AI agent context window bound to Bitcoin consensus state), and explicitly distinguishes its scope from siblings by naming proof.notarize (timestamp digests) and stratigraphy.get (raw metrics). The framing is abstract ('eliminate temporal and factual hallucinations', 'thermodynamic entropy'), which slightly muddies what the tool concretely returns, but the core purpose is discernible.
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?
Gives clear when-to-use context ('during critical reasoning steps or pre-execution checks when agent outputs require deterministic verification') and routes to two named alternatives with their distinct roles. It also walks through the L402 payment flow step by step. It stops short of an explicit when-not, so it falls just under full marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.listList Proof AttestationsARead-onlyIdempotentInspect
List available cryptographic proof attestations, including OpenTimestamps receipts and Groth16 zero-knowledge state proofs. Returns paginated index summaries of archived proofs without downloading the full byte payloads. Use this tool to discover existing proofs for specific block heights or dataset digests before verifying them. Use proof.get_by_hash to retrieve a specific full proof, proof.verify to validate one, or proof.submit to attest a new record. Read-only and idempotent. Free metadata discovery: no Live L402 Satoshi settlement is required for this sandbox tool; no paid payload is released.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Pagination window size: maximum number of attestation records to return (integer, 1-100); increase offset by limit for the next page. Constraints: minimum: 1; maximum: 100. Example: 20. | |
| offset | No | Zero-based pagination skip offset (0-1000); increase by limit to page through historical attestations, but multiples of limit are not required. Constraints: minimum: 0; maximum: 1000. Example: 0. | |
| status | No | Filter the attestation index to one lifecycle stage: verified, cached, pending, or invalid. Constraints: allowed values: verified, cached, pending, invalid. Example: "verified". |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total number of indexed attestation records matching the optional status filter before the limit is applied. Constraints: minimum: 0. Example: 1. |
| attestations | Yes | Recent indexed proof attestations ordered from newest to oldest. Example: [{"proofHash":"0x1a2b3c4d5e6f789001234567890abcdef1234567890abcdef1234567890abcd","snapshotDigest":"1534979302823651498736582947365829473658294","status":"verified","submittedAt":"2026-09-19T06:20:00.000Z","attestationCount":1,"meshQuorum":true}]. |
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 goes further: it discloses that only index summaries are returned, that no full payload is downloaded, and that this sandbox path requires no Live L402 Satoshi settlement and releases no paid payload. That payment and payload-release behavior is not derivable from any structured field.
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?
Front-loaded with purpose, then usage, then alternatives, then cost/safety. The final L402 sentence is long but carries non-obvious payment semantics, so it earns its place; the tooling is otherwise tight with no filler.
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-shape detail is unnecessary, and rich annotations cover the safety profile. The description supplies the discovery-vs-verify mental model, payload-vs-index distinction, and cost behavior, leaving nothing an agent needs to invoke this correctly.
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 limit, offset, and status are already fully documented in the schema, establishing the baseline of 3. The description adds no parameter-level detail (the mention of 'block heights or dataset digests' does not map to any schema field), so it neither compensates nor adds value here.
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 (list) and resource (cryptographic proof attestations), names the concrete content types (OpenTimestamps receipts, Groth16 state proofs), and scopes the return to paginated index summaries rather than full byte payloads. An agent can distinguish this from proof.get_by_hash and proof.verify without opening a 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 says when to use it ('discover existing proofs for specific block heights or dataset digests before verifying them') and routes to the three alternatives with their distinct purposes: proof.get_by_hash for retrieval, proof.verify for validation, proof.submit for attestation. When-to-use and alternatives are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.notarizeNotarize a SHA256 Digest with OpenTimestampsAInspect
PURPOSE & BOUNDARIES: Create a detached OpenTimestamps .ots receipt for an agent-supplied SHA256 digest using public calendars. Do NOT use this as evidence of immediate Bitcoin confirmation or as a replacement for proof.verify. USAGE GUIDELINES: Submit exactly one 64-character hexadecimal hash; decode otsProofHex into binary to save the .ots file. BEHAVIOR & CONSEQUENCES: Submits a randomized commitment to public calendars, returns pending_calendar, and fails explicitly if calendars are unavailable. Costs 250 sats via L402; X-L402-Batch-Size: 100 purchases 100 tool-scoped calls for 25000 sats. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Exactly 64 hexadecimal characters representing the agent state or data SHA256 digest; no 0x prefix. Constraints: minLength: 64; maxLength: 64; pattern: ^[0-9a-fA-F]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
Output Schema
| Name | Required | Description |
|---|---|---|
| hash | Yes | The original SHA256 digest, normalized to lowercase. Constraints: pattern: ^[0-9a-f]{64}$. Example: "abababababababababababababababababababababababababababababababab". |
| otsStatus | Yes | Calendar receipt only; Bitcoin inclusion must be independently upgraded and verified later. Example: "pending_calendar". |
| otsProofHex | Yes | Hex-encoded detached .ots file. Decode as binary and upgrade or verify later with official OpenTimestamps tools. Constraints: minLength: 2; maxLength: 1048576; pattern: ^(?:[0-9a-f]{2})+$. Example: "004f70656e54696d657374616d70730000". |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint=false and openWorldHint=true. The description goes far beyond by disclosing the cost model (250 sats via L402), batching behavior (100 calls for 25000 sats), the HTTP 402 payment flow with retry instructions, randomized commitment submission, pending_calendar return, and failure behavior when calendars are unavailable. This is rich behavioral context not derivable from annotations.
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 description is structured with clear headers (PURPOSE & BOUNDARIES, USAGE GUIDELINES, BEHAVIOR & CONSEQUENCES), which aids navigation. However, the L402 payment details are verbose and some information (e.g., 'Live L402 Satoshi settlement: a configured NWC wallet issues the exact-priced Lightning invoice') is highly detailed and could be more concise for a tool description. The length is justified by complex payment flow, but the density of payment-specific jargon reduces readability.
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?
Given the tool is a write operation with payment flow, no output schema needed for return values (though one exists), and the description covers purpose, usage, payment mechanics, failure modes, and boundaries. It is thorough for a notarization tool with L402 integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, so the baseline is 3. The description adds value by specifying 'exactly one 64-character hexadecimal hash' and clarifying the otsProofHex decoding requirement, which supplements the schema's parameter documentation. The addition is marginal but meaningful.
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?
The description states a specific verb (Create) and resource (detached OpenTimestamps .ots receipt) and explicitly draws boundaries against sibling tool proof.verify ('not a replacement for proof.verify'), enabling precise sibling discrimination.
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?
It provides explicit when-to-use guidance ('Submit exactly one 64-character hexadecimal hash'), when-not-to-use ('Do NOT use this as evidence of immediate Bitcoin confirmation or as a replacement for proof.verify'), and names the alternative tool. The usage conditions are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.submitSubmit ZK ProofAInspect
Submit a generated Groth16 zero-knowledge proof or transaction attestation to the Bitcoin Stratigraphy validation pipeline. Ingests verification keys, public inputs, and proof bytes for engine attestation. Use this tool when external agent systems need their cryptographic state verified and anchored into the stratigraphy index. Requires L402 settlement: on HTTP 402, pay the Lightning invoice and retry with Authorization: L402 :. 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. Supports zero-polling asynchronous execution: provide a webhook_url parameter to receive a 202 Accepted response immediately, followed by a server-initiated POST callback containing the final results when processing completes.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | Yes | Groth16/Poseidon BN254 proof coordinates for non-interactive validation: piA and piC are three decimal-string projective coordinates each, and piB is three pairs of decimal-string extension-field coordinates; for example, piA ['1','2','1']. | |
| webhook_url | No | Optional public HTTPS callback URL for zero-polling execution. On a paid call the server answers HTTP 202 Accepted with a JSON-RPC result containing task_id and status pending, runs the tool in the background, then POSTs one JSON body with task_id, status (completed or failed), tool, request_id and the final MCP result or JSON-RPC error. Omit it to receive the result synchronously. Loopback, private, link-local and other reserved addresses are rejected before any invoice is issued. Constraints: maxLength: 2048; format: uri; pattern: ^https://. Example: "https://agent.example.com/mcp/callbacks". | |
| publicSignals | Yes | Five ordered public inputs—blockHeight, thermodynamicHash, timestamp, valuationSat, and snapshotDigest—that must align with the submitted proof coordinates. Constraints: minItems: 5; maxItems: 5. Example: ["920000","1","1789776000000","12583","1"]. | |
| snapshotDigest | No | Decimal field digest or IPFS CID that must equal publicSignals[4] when supplied. Constraints: pattern: ^(?:\d+|Qm[1-9A-HJ-NP-Za-km-z]{44}|b[a-z2-7]{20,})$. Example: "1". |
Output Schema
| Name | Required | Description |
|---|---|---|
| jobId | Yes | Server-generated proof submission job ID for status lookup. Constraints: format: uuid. Example: "123e4567-e89b-42d3-a456-426614174000". |
| status | Yes | Immediate Groth16 verification result for the submitted proof and public signals. Constraints: allowed values: verified, invalid. Example: "verified". |
| proofHash | Yes | 0x-prefixed lowercase hexadecimal SHA-256 digest of the canonical proof. Example: "0x1a2b3c4d5e6f789001234567890abcdef1234567890abcdef1234567890abcd". |
| submittedAt | Yes | ISO 8601 UTC date string format. Constraints: format: date-time. Example: "2026-09-19T06:20:00.000Z". |
| attestationStatus | Yes | Nostr NIP-78 publication result: broadcast_confirmed, broadcast_failed, not_configured, or not_broadcast_invalid_proof. Example: "broadcast_confirmed". |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the annotation set: it discloses the L402 payment gate (402 handling, Lightning invoice, macaroon:preimage retry), the exact-priced NWC settlement rule, the warning that invoice creation alone is not payment, and the 202 + server-initiated POST callback async contract. Together these tell an agent how the call will behave operationally, which readOnlyHint/openWorldHint/idempotentHint do not.
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?
Purpose and payment gating are front-loaded and the async contract is clearly stated, but the L402 retry instruction appears twice ("on HTTP 402, pay the Lightning invoice and retry with Authorization: L402 <macaroon>:<preimage>" is restated verbatim in intent later), so it is longer than it needs to be.
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?
With an output schema present, return values need no prose, and the description still covers the two things an agent cannot infer elsewhere: the payment/settlement handshake and the asynchronous callback mode. Nothing needed to invoke this tool 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%, so proof, publicSignals, snapshotDigest and webhook_url are already fully documented in the schema. The description only restates that webhook_url enables zero-polling async execution and otherwise adds no syntax or format detail, matching the baseline 3.
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 (submit) and resource (generated Groth16 ZK proof / transaction attestation) and names the destination pipeline, which cleanly separates it from verification-oriented siblings like proof.verify and attestation-only siblings like proof.notarize.
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?
"Use this tool when external agent systems need their cryptographic state verified and anchored into the stratigraphy index" gives a concrete triggering condition, and the async/webhook guidance adds a mode-selection rule. It stops short of naming alternative siblings (proof.verify, proof.notarize) or stating exclusions, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof.verifyVerify Groth16 or OpenTimestamps ProofAInspect
Execute cryptographic verification for supplied Groth16 telemetry or drift zk-SNARK proofs, or OpenTimestamps receipts. Returns proof validity; verification can update a bounded in-memory lifecycle index, and drift checks require a Bitcoin block provider. Use this tool to verify supplied proofs; use proof.submit to register new Groth16 proofs and proof.get_by_hash to retrieve retained proofs or signed receipts by a known identifier. 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True only for a digest-matching, Bitcoin-attested OTS record with a valid chain-header lookup. Example: true. |
| status | No | Whether the OTS record is Bitcoin-attested; calendar-only receipts are unverified. Constraints: allowed values: bitcoin_block_attested, unverified. Example: "bitcoin_block_attested". |
| verifiedAt | No | ISO 8601 UTC time when this verification finished. Constraints: format: date-time. Example: "2026-09-19T01:41:36.458Z". |
| blockHeight | No | Bitcoin attestation height, or null if not verified. Example: 920000. |
| bitcoinHeaderHash | No | Canonical Bitcoin block header hash at the attested height, or null if not verified. Example: "abababababababababababababababababababababababababababababababab". |
| computationTimeMs | No | Server-side proof verification duration in milliseconds. Constraints: minimum: 0. Example: 3.284. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, and the description explains why: verification can mutate a bounded in-memory lifecycle index, drift checks depend on an external Bitcoin block provider, and paid execution requires a confirmed Lightning settlement. It additionally discloses the auth flow (handle 402, pay, retry identical request with Authorization: L402 <macaroon>:<preimage>) and warns that invoice creation alone is not payment — substantial context beyond the structured hints.
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?
Purpose, side effects, sibling routing and payment handling are front-loaded and each sentence carries operational information. It runs long and the closing defensive clauses ('Invoice creation alone is not payment; unavailable verification does not authorize execution') are slightly redundant, keeping it short of a 5.
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?
An output schema exists, so return values need not be explained. The description covers side effects, external dependencies, auth/payment flow and sibling routing, leaving only minor ambiguity about when to choose the legacy telemetry-bound Groth16 branch versus the native zk.drift.v1 branch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the oneOf branches are exhaustively documented, so the schema carries most of the burden. The description still adds branch-selection meaning by framing the three modes (telemetry Groth16, drift zk.drift.v1, OTS) and noting groth16 is the default, which is more than a bare baseline.
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?
The first sentence names a specific verb (verify) and enumerates the exact resource families covered (Groth16 telemetry proofs, drift zk-SNARK proofs, OpenTimestamps receipts), which maps cleanly onto the three oneOf branches. It also distinguishes itself from siblings by naming proof.submit and proof.get_by_hash explicitly.
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?
The description states when to use this tool ('verify supplied proofs') and when to use alternatives, naming proof.submit for registration and proof.get_by_hash for retrieval by identifier. It also covers the conditional path where a 402 is returned and what to do next, so no routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.getGet Bitcoin StratigraphyARead-onlyIdempotentInspect
Paid, full fresh pipeline telemetry and exact selected historical Object Storage JSON/.ots receipts; records contain live or archived pipeline snapshots, never video-index data. Semantic discovery: Hal Finney Horizon tracker = $10,000,000 / BTC USD price; this is a valuation multiple, not a time-to-price forecast. The 15 J/TH thermodynamic energy calculation estimates watts as (network hashrate H/s / 1e12) * 15, not measured electricity. Sovereign Node RPC telemetry uses local Bitcoin Core; price and horizon are unavailable without a fiat quote. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Select one indexed UTC day (YYYY-MM-DD, e.g. '2026-09-19'); cannot combine with days, blockHeight, or range bounds. Constraints: minLength: 1; format: date; pattern: ^\d{4}-\d{2}-\d{2}$. Example: "2026-09-19". | |
| days | No | Fetch the most recent 1-365 indexed daily records (e.g. 7), capped by limit; cannot combine with date, blockHeight, or range bounds. Constraints: minimum: 1; maximum: 365. Example: 7. | |
| limit | No | Cap records returned by the chosen selector at 1-100 (default 10); does not expand days or range bounds. Constraints: minimum: 1; maximum: 100. Example: 10. | |
| endDate | No | Inclusive upper UTC date bound (YYYY-MM-DD); pair with startDate for a bounded range or use alone for an open range, never with days, date, or blockHeight; must be >= startDate when paired. Constraints: minLength: 1; format: date; pattern: ^\d{4}-\d{2}-\d{2}$. Example: "2026-09-18". | |
| metrics | No | Deprecated legacy projection hint retained for compatibility; the live source returns complete pipeline records regardless of this hint. Inspect live_metrics for the real pipeline field names. Constraints: minItems: 1. Example: ["target_multiplier"]. | |
| endBlock | No | Inclusive upper indexed block-height bound (non-negative); pair with startBlock for a bounded range or use alone for an open range, never with days, date, or blockHeight; must be >= startBlock when paired. Constraints: minimum: 0. Example: 920000. | |
| startDate | No | Inclusive lower UTC date bound (YYYY-MM-DD); pair with endDate for a bounded range or use alone for an open range, never with days, date, or blockHeight. Constraints: minLength: 1; format: date; pattern: ^\d{4}-\d{2}-\d{2}$. Example: "2026-09-01". | |
| startBlock | No | Inclusive lower indexed block-height bound (non-negative); pair with endBlock for a bounded range or use alone for an open range, never with days, date, or blockHeight. Constraints: minimum: 0. Example: 910000. | |
| blockHeight | No | Select one actual captured non-negative Bitcoin height or the current live height; never a synthetic date-to-height index. Cannot combine with days, date, or range bounds. Constraints: minimum: 0. Example: 850000. |
Output Schema
| Name | Required | Description |
|---|---|---|
| records | Yes | Selected actual live or UTC-archived complete pipeline snapshots. |
| live_metrics | Yes | Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null. |
| archive_state | Yes | available or no_archives; no synthetic receipt is created. |
| proofAvailable | Yes | True only if an archived JSON/OTS pair was returned. |
| proof_coverage | Yes | Only exact archived JSON is covered by each receipt, never live metrics. |
| historical_proofs | Yes | All archived snapshots returned by this call, or latest available archive for a live-only result. |
TDQS
A3.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the read/idempotent/safe profile; the description adds the operational reality the annotations cannot: the tool is paid, execution requires confirmed settlement plus an invoice-bound proof, invoice creation alone is not payment, and unavailable verification does not authorize execution. It also discloses that price and horizon are unavailable without a fiat quote and that the energy figure is an estimate rather than measured electricity.
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?
Sentences are dense but not padded; each carries some payload. The problem is structure: five distinct topics (record contents, valuation semantics, energy math, node mode, L402 payment) are run together in one unbroken block with no headings or ordering, making it hard for an agent to locate the payment instructions that matter most for successful invocation.
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?
Given 9 optional parameters, full schema coverage, and an output schema that carries return values, the description covers the remaining gaps well: payment/auth flow, data provenance, and the caveats around derived metrics. Only the relationship to sibling getters is missing, which is a minor completeness gap for a 9-parameter tool with an output schema.
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 the selector semantics (date, days, blockHeight, range bounds, mutual exclusivity, limit capping) are already fully documented in the schema and the schema-level description. The prose adds interpretive meaning for derived metrics (the $10M/BTC valuation multiple, the 15 J/TH watts formula), but does not clarify any individual parameter beyond what the schema states, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the payload as full fresh pipeline telemetry plus selected historical Object Storage JSON/.ots receipts, which tells the agent what comes back, but it is phrased as a noun stack rather than a verb+resource statement. It also does not differentiate itself from close siblings such as stratigraphy.get_range, stratigraphy.list, or stratigraphy.get_digest, so the agent must guess how this selector-free getter differs from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies real preconditions (paid access, configured NWC wallet, local Bitcoin Core for sovereign-node mode, a fiat quote for price/horizon) and step-by-step handling of HTTP 402, which goes beyond 'no guidance'. However it never states when to choose this tool over the sibling range/list/diff getters, leaving the routing decision implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.get_diffCompare Stratigraphy StrataARead-onlyIdempotentInspect
Calculate signed arithmetic and thermodynamic deltas between fromTarget (baseline height or UTC date) and toTarget (comparison height, UTC date, or 'latest' indexed entry). Use this tool when measuring block-to-block divergence or net change between two points without fetching intermediate records. Use stratigraphy.get_range for full interval series, stratigraphy.get for a single snapshot, stratigraphy.get_digest for compact hashes, or stratigraphy.list for catalog discovery. Paid L402 call: on HTTP 402, pay the invoice and retry with Authorization: L402 :.
| Name | Required | Description | Default |
|---|---|---|---|
| toTarget | No | Optional comparison indexed height (e.g. '919856'), UTC ISO date (e.g. '2026-09-01'), or 'latest' (default); deltas are toTarget minus fromTarget. 'latest' is the latest dataset entry, not the live Bitcoin tip. Constraints: pattern: ^(?:latest|(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "latest". | latest |
| fromTarget | Yes | Required baseline indexed height (e.g. '850000') or UTC ISO date (e.g. '2026-01-01'); compared with toTarget to calculate signed deltas. Either chronological order is allowed; only indexed entries resolve. Constraints: pattern: ^(?:(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "919856". |
Output Schema
| Name | Required | Description |
|---|---|---|
| to | Yes | Real captured to-target values. |
| from | Yes | Real captured from-target values. |
| delta | Yes | Signed arithmetic deltas; watts derive from the assumed 15 J/TH baseline. |
| live_metrics | Yes | Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null. |
| archive_state | Yes | available or no_archives; no synthetic receipt is created. |
| proofAvailable | Yes | True only if an archived JSON/OTS pair was returned. |
| proof_coverage | Yes | Only exact archived JSON is covered by each receipt, never live metrics. |
| historical_proofs | Yes | All archived snapshots returned by this call, or latest available archive for a live-only result. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds behavior the annotations cannot express: it is a paid L402 call and gives the exact 402 remediation (pay the invoice, retry with Authorization: L402 <macaroon>:<preimage>). It also warns that 'latest' means the latest indexed dataset entry, not the live Bitcoin tip, preventing a likely agent misconception.
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?
Front-loaded with the operation, then usage, then alternatives, then payment mechanics — a sensible ordering. It is slightly repetitive, restating the 'latest' caveat and the either-order rule already present in the schema, which costs it the top mark.
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?
For a two-parameter read tool with an output schema and full annotations, the description covers everything an agent needs: purpose, selection criteria, sibling routing, and the non-obvious payment/auth flow. Return format is delegated appropriately to the output schema.
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, including the pattern, examples, and the 'deltas are toTarget minus fromTarget' ordering rule. The description largely restates these facts (signed deltas, either order valid, latest semantics) rather than adding new parameter meaning, so the baseline of 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 precise verb+resource: 'Calculate signed arithmetic and thermodynamic deltas between fromTarget ... and toTarget'. It bounds the operation to two-point comparison and explicitly contrasts itself with four sibling tools, so an agent can select it without opening a 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?
Gives an explicit use condition ('measuring block-to-block divergence or net change between two points without fetching intermediate records') and then routes to alternatives by name and purpose: get_range for full interval series, get for a single snapshot, get_digest for compact hashes, list for catalog discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.get_digestGet Compressed Stratigraphy DigestARead-onlyIdempotentInspect
Retrieve compact SHA-256 fingerprints and minimal telemetry tuples for a target height, UTC date, or 'start..end' date range using the chosen format ('compact', 'minimal', or 'kv'). Use this tool to verify state integrity or minimize token consumption when full payloads are unnecessary. Use stratigraphy.get for full single-record telemetry, stratigraphy.get_range for full multi-record series, stratigraphy.get_diff for two-point deltas, or stratigraphy.list for free catalog browsing. Paid L402 call: on HTTP 402, pay the invoice and retry with Authorization: L402 :.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Compression format: minimal returns [height,date,target_multiplier,record_hash]; kv returns {h,ts,tm,hash}; compact returns HEIGHT:...|DATE:...|TM:...|HASH:.... Record hashes are SHA-256 of stored entry fields, not Bitcoin block hashes; no per-record proof is available. Constraints: allowed values: compact, minimal, kv. Example: "compact". | compact |
| target | No | Indexed Bitcoin height (e.g. '920000'), ISO date, or inclusive ISO date range joined with '..'. Defaults to the latest available dataset entry, not the live Bitcoin tip. Constraints: pattern: ^(?:latest|(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2}(?:\.\.\d{4}-\d{2}-\d{2})?)$. Example: "latest". | latest |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | compact text, minimal tuple, kv object, or arrays for bounded date ranges; hash is SHA-256 of exact archived JSON when available. |
| live_metrics | Yes | Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null. |
| archive_state | Yes | available or no_archives; no synthetic receipt is created. |
| proofAvailable | Yes | True only if an archived JSON/OTS pair was returned. |
| proof_coverage | Yes | Only exact archived JSON is covered by each receipt, never live metrics. |
| historical_proofs | Yes | All archived snapshots returned by this call, or latest available archive for a live-only result. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only/idempotent/non-destructive profile, and the description adds the operationally critical detail they cannot: this is a paid L402 call and on HTTP 402 the agent must pay the invoice and retry with 'Authorization: L402 <macaroon>:<preimage>'. It also clarifies that hashes are SHA-256 of stored entry fields rather than Bitcoin block hashes, which prevents a plausible misreading.
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?
Front-loaded with what the tool returns, then routing guidance, then the payment caveat – a sensible priority order. The prose is dense but every sentence carries a distinct load; only the enumerating of sibling tools runs slightly long.
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 values need not be explained, annotations carry the safety profile, and the description supplies the remaining gaps: format semantics, the hash-provenance caveat, the 'latest' pitfall, sibling routing, and the L402 payment flow. An agent has everything needed to call it correctly.
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 the enum values, the '..' range syntax, the pattern, and the 'latest means latest dataset entry, not the live tip' caveat are already documented in the schema. The description restates the three formats and the target kinds without adding new syntax or defaults beyond that baseline.
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 compact SHA-256 fingerprints and minimal telemetry tuples') plus the full accepted targeting scope (height, UTC date, or 'start..end' range). An agent can immediately distinguish this from stratigraphy.get, get_range, get_diff, and list 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?
Gives both a positive trigger ('verify state integrity or minimize token consumption when full payloads are unnecessary') and explicit alternatives with the condition that selects each: stratigraphy.get for full single records, get_range for full series, get_diff for deltas, stratigraphy.list for catalog browsing. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.get_rangeGet Stratigraphy RangeARead-onlyIdempotentInspect
Fetch a contiguous sequence of Bitcoin stratigraphy records between startTarget and endTarget (block heights or YYYY-MM-DD UTC dates, in ascending order, capped by the limit parameter). Use this tool when analyzing multi-block trends or time-series intervals. Use stratigraphy.list to browse available catalog bounds, stratigraphy.get for a single snapshot, stratigraphy.get_diff to compare two endpoints without intermediate records, or stratigraphy.get_digest for compact hashes. Paid L402 call: on HTTP 402, pay the invoice and retry with Authorization: L402 :. Supports zero-polling asynchronous execution: provide a webhook_url parameter to receive a 202 Accepted response immediately, followed by a server-initiated POST callback containing the final results when processing completes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum compressed records returned from startTarget toward endTarget, 1-100 (default 50); smaller limits truncate the batch. Constraints: minimum: 1; maximum: 100. Example: 50. | |
| format | No | Compression of every returned record: compact (default), minimal, or kv; does not change selected bounds. Constraints: allowed values: compact, minimal, kv. Example: "compact". | compact |
| endTarget | No | Optional inclusive ending indexed height, UTC ISO date, or 'latest' (default: latest indexed entry, not live tip); must resolve no earlier than startTarget. Constraints: pattern: ^(?:latest|(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "latest". | latest |
| startTarget | Yes | Required inclusive starting indexed height (e.g. '850000') or UTC ISO date (e.g. '2026-01-01'); must resolve no later than endTarget. Constraints: pattern: ^(?:(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "919712". | |
| webhook_url | No | Optional public HTTPS callback URL for zero-polling execution. On a paid call the server answers HTTP 202 Accepted with a JSON-RPC result containing task_id and status pending, runs the tool in the background, then POSTs one JSON body with task_id, status (completed or failed), tool, request_id and the final MCP result or JSON-RPC error. Omit it to receive the result synchronously. Loopback, private, link-local and other reserved addresses are rejected before any invoice is issued. Constraints: maxLength: 2048; format: uri; pattern: ^https://. Example: "https://agent.example.com/mcp/callbacks". |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of actual records returned. |
| range | Yes | Requested inclusive real height/date bounds. |
| format | Yes | compact, minimal, or kv response format. |
| records | Yes | Selected actual snapshot summaries, not a synthetic daily index. |
| live_metrics | Yes | Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null. |
| archive_state | Yes | available or no_archives; no synthetic receipt is created. |
| proofAvailable | Yes | True only if an archived JSON/OTS pair was returned. |
| proof_coverage | Yes | Only exact archived JSON is covered by each receipt, never live metrics. |
| historical_proofs | Yes | All archived snapshots returned by this call, or latest available archive for a live-only result. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-derived behavior: the L402 paid-call flow with the exact retry header format, and the zero-polling async path (202 Accepted, task_id, server-initiated POST callback). These are operational traits an agent cannot infer from annotations or schema.
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?
Front-loaded with purpose and scope, then alternatives, then payment/async mechanics — an effective ordering. It is dense but nearly every clause carries distinct routing or operational information; the L402 and webhook sentences are long yet load-bearing.
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?
With an output schema present, return values need no explanation here; annotations cover safety, schema covers all five parameters, and the description covers the two things structured data cannot express (paid-call retry and async callback). Nothing an agent needs to invoke 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%, so the schema already carries per-parameter semantics (limit range, format enum, target patterns, webhook contract). The description only restates that output is capped by limit and that bounds are ascending/contiguous, adding little beyond structured data. Baseline 3 is appropriate.
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 ('Fetch a contiguous sequence of Bitcoin stratigraphy records') plus the exact bounds (startTarget/endTarget) and truncation rule (capped by limit). It also names the sibling tools it is distinct from, so an agent can route 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 gives the selecting condition ('when analyzing multi-block trends or time-series intervals') and then enumerates alternatives with their distinct roles: stratigraphy.list for catalog bounds, stratigraphy.get for a single snapshot, stratigraphy.get_diff for two endpoints without intermediates, stratigraphy.get_digest for compact hashes. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stratigraphy.listList Stratigraphy CatalogARead-onlyIdempotentInspect
List the Bitcoin stratigraphy catalog, returning paginated index summaries of available block heights and UTC dates without heavy telemetry payloads. Use this free discovery tool first to inspect available start/end boundaries and verify which heights or dates are indexed before calling paid retrieval tools. Use stratigraphy.get for a single full record, stratigraphy.get_range for a contiguous sequence, stratigraphy.get_diff for two-point deltas, or stratigraphy.get_digest for compact SHA-256 hashes. Use limit and offset parameters to paginate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | Authoritative pipeline and Object Storage origins. |
| dateBounds | Yes | Actual captured archive UTC date bounds. |
| attribution | Yes | Verbatim historical attribution of the Hal Finney Horizon. |
| newestBlock | Yes | Real block height of the newest archive, or null. |
| oldestBlock | Yes | Real block height of the oldest archive, or null. |
| totalSnapshots | Yes | Number of JSON snapshots captured in Object Storage. |
| liveBlockHeight | Yes | Current live tip from the pipeline, not an indexed archive height. |
| availableMetrics | Yes | Actual fields in the live pipeline model. |
| proofArchiveCount | Yes | Number of complete JSON/OTS archive pairs. |
| efficiency_baseline_j_th | Yes | Assumed fixed hardware efficiency used by live power estimate. |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the description earns credit for adding what they don't: that this call is free, that it returns lightweight index summaries rather than telemetry payloads, and that it is the discovery step ahead of paid retrieval. It loses a point for the pagination instruction, which misstates how the tool actually behaves.
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?
Purpose is front-loaded, followed by usage and sibling routing; every sentence except the erroneous closing one carries routing value. The four-way sibling enumeration is long but high-signal, so it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 further explanation, and the discovery-vs-paid workflow is complete. However, the description closes with an operational claim about limit/offset that contradicts the schema and would cause a failed call, leaving the invocation story incorrect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The rule sets a baseline of 4 for zero-parameter tools, but the description claims 'Use limit and offset parameters to paginate' while the schema declares no properties and states 'any parameter is rejected' with additionalProperties=false. This invents parameters that will cause a rejection, actively misleading the agent rather than adding meaning.
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+resource ('List the Bitcoin stratigraphy catalog') plus the return shape ('paginated index summaries of available block heights and UTC dates without heavy telemetry payloads'). It is immediately distinguishable from stratigraphy.get/get_range/get_diff/get_digest, which it names explicitly.
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?
Gives an explicit sequencing rule: 'Use this free discovery tool first ... before calling paid retrieval tools,' and names the selecting condition for each alternative (single record, contiguous sequence, two-point deltas, compact hashes). This is textbook when-to-use/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
workflow.audit_trajectoryAudit Thermodynamic TrajectoryARead-onlyIdempotentInspect
A deterministic composite workflow that executes a complete end-to-end thermodynamic audit between fromTarget and toTarget. It automatically calculates signed difficulty deltas, fetches compressed SHA-256 proof receipts, and returns a unified cryptographic report. Use this composite workflow to save LLM context tokens and eliminate multi-step agent orchestration when auditing historical divergence. Use individual stratigraphy or proof tools for single-purpose queries. Paid L402 call: on HTTP 402, pay the invoice and retry with Authorization: L402 :.
| Name | Required | Description | Default |
|---|---|---|---|
| toTarget | Yes | Required comparison real Bitcoin height, valid YYYY-MM-DD UTC date, or latest. Constraints: pattern: ^(?:latest|(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "latest". | |
| fromTarget | Yes | Baseline real Bitcoin height or valid YYYY-MM-DD UTC date; latest is not a baseline. Constraints: pattern: ^(?:(?:0|[1-9]\d*)|\d{4}-\d{2}-\d{2})$. Example: "2026-10-12". |
Output Schema
| Name | Required | Description |
|---|---|---|
| trajectory_deltas | Yes | The same signed arithmetic returned by stratigraphy.get_diff, evaluated against one fixed live snapshot and cached archive bytes. |
| cryptographic_proofs | Yes | Minimal proof references and SHA-256 fingerprints for the exact two selected boundary records. Live fingerprints are not archived OTS proofs. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds context they cannot: the tool is a deterministic composite that fans out internally, it returns compressed cryptographic receipts and a unified report, and it is a paid L402 endpoint with a concrete auth-and-retry protocol. That payment/auth disclosure is exactly the kind of behavior an agent must know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then routing guidance, then the payment protocol — four sentences with no filler. The alternative-tool sentence and the L402 sentence each carry distinct, actionable 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 values need no prose explanation, and the description still summarizes the report shape. Combined with the routing guidance and payment protocol, an agent has everything needed to select and successfully call this composite 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 coverage is 100% and the schema itself documents the baseline-vs-comparison roles, the accepted height/date patterns, and the 'latest is not a baseline' constraint. The description only restates the two boundaries and their ordering ('between fromTarget and toTarget'), adding no format, default, or edge-case meaning beyond the schema. Baseline 3 is appropriate.
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: a composite workflow that executes an end-to-end thermodynamic audit between two named boundaries, plus what it internally produces (signed difficulty deltas, SHA-256 proof receipts, unified cryptographic report). It explicitly contrasts itself with 'individual stratigraphy or proof tools', so an agent can distinguish it from the 15 siblings without opening a 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?
Gives an explicit when-to-use ('save LLM context tokens and eliminate multi-step agent orchestration when auditing historical divergence') and an explicit when-not-to-use, routing single-purpose queries to stratigraphy/proof tools. The paid-call condition (HTTP 402 -> pay invoice -> retry with Authorization: L402) is also spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
proof.submit1 field changed- added
Input schema / properties / webhook_urlAdded value: +{ + "description": "Optional public HTTPS callback URL for zero-polling execution. On a paid call the server answers HTTP 202 Accepted with a JSON-RPC result containing task_id and status pending, runs the tool in the background, then POSTs one JSON body with task_id, status (completed or failed), tool, request_id and the final MCP result or JSON-RPC error. Omit it to receive the result synchronously. Loopback, private, link-local and other reserved addresses are rejected before any invoice is issued. Constraints: maxLength: 2048; format: uri; pattern: ^https://. Example: \"https://agent.example.com/mcp/callbacks\".", + "example": "https://agent.example.com/mcp/callbacks", + "examples": [ + "https://agent.example.com/mcp/callbacks" + ], + "format": "uri", + "maxLength": 2048, + "pattern": "^https://", + "type": "string" +}
- Changed
stratigraphy.get_range1 field changed- added
Input schema / properties / webhook_urlAdded value: +{ + "description": "Optional public HTTPS callback URL for zero-polling execution. On a paid call the server answers HTTP 202 Accepted with a JSON-RPC result containing task_id and status pending, runs the tool in the background, then POSTs one JSON body with task_id, status (completed or failed), tool, request_id and the final MCP result or JSON-RPC error. Omit it to receive the result synchronously. Loopback, private, link-local and other reserved addresses are rejected before any invoice is issued. Constraints: maxLength: 2048; format: uri; pattern: ^https://. Example: \"https://agent.example.com/mcp/callbacks\".", + "example": "https://agent.example.com/mcp/callbacks", + "examples": [ + "https://agent.example.com/mcp/callbacks" + ], + "format": "uri", + "maxLength": 2048, + "pattern": "^https://", + "type": "string" +}
1 tool update
- Changed
proof.attenuate21 fields changed- changed
Input schema / descriptionPrevious value: -"Provide an authentic parent macaroon, an array of restrictions, and optional TTL; child caveats intersect with inherited constraints and no payment invoice is issued."New value: +"Provide an authentic parent macaroon and at least one restriction: expiresAt or ttlSeconds, exact tools, or caveats. New caveats intersect with inherited constraints and no payment invoice is issued." - changed
Input schema / examplesPrevious value: -[ - { - "caveats": [ - "allowed_tools = stratigraphy.get,stratigraphy.get_digest", - "max_target = 870000" - ], - "macaroon": "base64url-parent-macaroon", - "ttlSeconds": 3600 - } -]New value: +[ + { + "caveats": [ + "max_target = 870000" + ], + "expiresAt": "2026-12-31T23:59:59Z", + "macaroon": "base64url-parent-macaroon", + "tools": [ + "stratigraphy.get_diff" + ] + } +] - added
Input schema / properties / caveats / defaultAdded value: +[] - changed
Input schema / properties / caveats / descriptionPrevious value: -"List of restriction caveats to append (e.g. ['time_before = 2026-12-31', 'max_target = 870000', 'allowed_tools = stratigraphy.get,stratigraphy.get_digest']). Existing allowed_path and max_requests restrictions are also supported. Constraints: maxItems: 16. Example: [\"time_before = 2026-12-31\",\"max_target = 870000\",\"allowed_tools = stratigraphy.get,stratigraphy.get_digest\"]."New value: +"Optional restriction caveats to append, normalized to canonical form: 'time < 2026-12-31T23:59:59Z', 'rpc = stratigraphy.get_diff', 'max_target = 870000', 'max_requests = 1', 'allowed_path = /mcp/tools/stratigraphy.get_diff', and legacy 'time_before = 2026-12-31' or 'allowed_tools = stratigraphy.get,stratigraphy.get_digest'. Constraints: maxItems: 16. Example: [\"max_target = 870000\"]." - changed
Input schema / properties / caveats / examplePrevious value: -[ - "time_before = 2026-12-31", - "max_target = 870000", - "allowed_tools = stratigraphy.get,stratigraphy.get_digest" -]New value: +[ + "max_target = 870000" +] - changed
Input schema / properties / caveats / examplesPrevious value: -[ - [ - "time_before = 2026-12-31", - "max_target = 870000", - "allowed_tools = stratigraphy.get,stratigraphy.get_digest" - ] -]New value: +[ + [ + "max_target = 870000" + ] +] - changed
Input schema / properties / caveats / items / descriptionPrevious value: -"One supported restriction caveat. Constraints: minLength: 1; maxLength: 256. Example: \"max_target = 870000\"."New value: +"One supported restriction caveat. Constraints: minLength: 1; maxLength: 256. Example: \"time < 2026-12-31T23:59:59Z\"." - changed
Input schema / properties / caveats / items / examplePrevious value: -"max_target = 870000"New value: +"time < 2026-12-31T23:59:59Z" - changed
Input schema / properties / caveats / items / examplesPrevious value: -[ - "max_target = 870000" -]New value: +[ + "time < 2026-12-31T23:59:59Z" +] - added
Input schema / properties / expiresAtAdded value: +{ + "description": "Optional absolute expiration boundary as a future UTC instant (YYYY-MM-DDTHH:MM:SSZ, optionally with .sss milliseconds). Appends `time < YYYY-MM-DDTHH:MM:SS.sssZ`; it cannot extend the parent's expiry. Mutually exclusive with ttlSeconds. Constraints: format: date-time; pattern: ^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d{3})?Z$. Example: \"2026-12-31T23:59:59Z\".", + "example": "2026-12-31T23:59:59Z", + "examples": [ + "2026-12-31T23:59:59Z" + ], + "format": "date-time", + "pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d{3})?Z$", + "type": "string" +} - changed
Input schema / properties / macaroon / descriptionPrevious value: -"Required authentic, unexpired parent L402 macaroon (1-8192 characters); caveats and ttlSeconds can only narrow its scope. Constraints: minLength: 1; maxLength: 8192. Example: \"base64url-parent-macaroon\"."New value: +"Required authentic, unexpired parent L402 macaroon (1-8192 characters); added restrictions can only narrow its scope. Constraints: minLength: 1; maxLength: 8192. Example: \"base64url-parent-macaroon\"." - added
Input schema / properties / toolsAdded value: +{ + "description": "Optional exact MCP tool targets (1-16 unique names). Appends one `rpc = tool[,tool...]` caveat; the child is refused for every other tool. Matching is exact, so a legacy alias is a different name. Each tool must already be authorized by the parent: an MCP L402 credential authorizes the single tool named in its allowed_path. Constraints: minItems: 1; maxItems: 16. Example: [\"stratigraphy.get_diff\"].", + "example": [ + "stratigraphy.get_diff" + ], + "examples": [ + [ + "stratigraphy.get_diff" + ] + ], + "items": { + "description": "Registered MCP tool name or supported legacy alias. Constraints: pattern: ^[a-z][a-z0-9]*\\.[a-z][a-z0-9_]*$. Example: \"stratigraphy.get_diff\".", + "example": "stratigraphy.get_diff", + "examples": [ + "stratigraphy.get_diff" + ], + "pattern": "^[a-z][a-z0-9]*\\.[a-z][a-z0-9_]*$", + "type": "string" + }, + "maxItems": 16, + "minItems": 1, + "type": "array", + "uniqueItems": true +} - changed
Input schema / properties / ttlSeconds / descriptionPrevious value: -"Optional positive integer TTL of 1-2592000 seconds (e.g. 3600); appends an expiration caveat without extending the parent's expiry. Constraints: minimum: 1; maximum: 2592000. Example: 3600."New value: +"Optional positive integer TTL of 1-2592000 seconds (e.g. 3600). Appends `time <` at the current time plus ttlSeconds; it cannot extend the parent's expiry. Mutually exclusive with expiresAt. Constraints: minimum: 1; maximum: 2592000. Example: 3600." - changed
Input schema / requiredPrevious value: -[ - "macaroon", - "caveats" -]New value: +[ + "macaroon" +] - changed
Output schema / examplesPrevious value: -[ - { - "appliedCaveats": [ - "max_target=870000" - ], - "attenuatedMacaroon": "base64url-child-macaroon", - "issuedAt": "2026-09-27T21:00:00.000Z", - "status": "attenuated" - } -]New value: +[ + { + "appliedCaveats": [ + "max_target=870000", + "time < 2026-12-31T23:59:59.000Z", + "rpc = stratigraphy.get_diff" + ], + "attenuatedMacaroon": "base64url-child-macaroon", + "issuedAt": "2026-09-27T21:00:00.000Z", + "status": "attenuated" + } +] - changed
Output schema / properties / appliedCaveats / descriptionPrevious value: -"New canonical caveats appended to the parent; inherited caveats are preserved inside the token. Example: [\"max_target=870000\"]."New value: +"New canonical caveats appended to the parent; inherited caveats are preserved inside the token. Example: [\"max_target=870000\",\"time < 2026-12-31T23:59:59.000Z\",\"rpc = stratigraphy.get_diff\"]." - changed
Output schema / properties / appliedCaveats / examplePrevious value: -[ - "max_target=870000" -]New value: +[ + "max_target=870000", + "time < 2026-12-31T23:59:59.000Z", + "rpc = stratigraphy.get_diff" +] - changed
Output schema / properties / appliedCaveats / examplesPrevious value: -[ - [ - "max_target=870000" - ] -]New value: +[ + [ + "max_target=870000", + "time < 2026-12-31T23:59:59.000Z", + "rpc = stratigraphy.get_diff" + ] +] - changed
Output schema / properties / appliedCaveats / items / descriptionPrevious value: -"One appended canonical caveat. Example: \"max_target=870000\"."New value: +"One appended canonical caveat. Example: \"rpc = stratigraphy.get_diff\"." - changed
Output schema / properties / appliedCaveats / items / examplePrevious value: -"max_target=870000"New value: +"rpc = stratigraphy.get_diff" - changed
Output schema / properties / appliedCaveats / items / examplesPrevious value: -[ - "max_target=870000" -]New value: +[ + "rpc = stratigraphy.get_diff" +]
1 tool update
- Added
workflow.audit_trajectory
1 tool update
- Changed
payment.get_info3 fields changed- changed
Input schema / oneOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "query", - "default": "query", - "description": "Pricing query (default). Example: \"query\".", - "example": "query", - "examples": [ - "query" - ], - "type": "string" - }, - "toolName": { - "description": "Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.get_digest' or 'proof.verify'); supported legacy aliases are also accepted and resolve to canonical names. When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name or supported legacy alias. Constraints: minLength: 1. Example: \"stratigraphy.get_digest\".", - "example": "stratigraphy.get_digest", - "examples": [ - "stratigraphy.get_digest" - ], - "minLength": 1, - "type": "string" - } - }, - "type": "object" - }, - { - "additionalProperties": false, - "description": "Payment identifier and one payment proof; the matching signed L402 or x402 credential must be supplied in HTTP headers.", - "examples": [ - { - "paymentHash": "abababababababababababababababababababababababababababababababab", - "preimage": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" - }, - { - "paymentHash": "0xabababababababababababababababababababababababababababababababab", - "txHash": "0xabababababababababababababababababababababababababababababababab" - } - ], - "oneOf": [ - { - "required": [ - "preimage" - ] - }, - { - "required": [ - "txHash" - ] - } - ], - "properties": { - "action": { - "const": "settle", - "description": "Verify or execute payment settlement. Example: \"settle\".", - "example": "settle", - "examples": [ - "settle" - ], - "type": "string" - }, - "paymentHash": { - "description": "L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", - "example": "abababababababababababababababababababababababababababababababab", - "examples": [ - "abababababababababababababababababababababababababababababababab" - ], - "pattern": "^(0x)?[0-9a-fA-F]{64}$", - "type": "string" - }, - "paymentMacaroon": { - "description": "Original invoice macaroon, separate from this tool's paid access credential. Constraints: minLength: 1; maxLength: 8192. Example: \"eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ\".", - "example": "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ", - "examples": [ - "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ" - ], - "maxLength": 8192, - "minLength": 1, - "type": "string" - }, - "preimage": { - "description": "L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\".", - "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", - "examples": [ - "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" - ], - "pattern": "^[0-9a-fA-F]{64}$", - "type": "string" - }, - "txHash": { - "description": "Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: \"0xabababababababababababababababababababababababababababababababab\".", - "example": "0xabababababababababababababababababababababababababababababababab", - "examples": [ - "0xabababababababababababababababababababababababababababababababab" - ], - "pattern": "^0x[0-9a-fA-F]{64}$", - "type": "string" - } - }, - "required": [ - "action", - "paymentHash" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "action": { + "const": "query", + "default": "query", + "description": "Pricing query (default). Example: \"query\".", + "example": "query", + "examples": [ + "query" + ], + "type": "string" + }, + "toolName": { + "description": "Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.get_digest' or 'proof.verify'); supported legacy aliases are also accepted and resolve to canonical names. When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name or supported legacy alias. Constraints: minLength: 1. Example: \"stratigraphy.get_digest\".", + "example": "stratigraphy.get_digest", + "examples": [ + "stratigraphy.get_digest" + ], + "minLength": 1, + "type": "string" + } + }, + "type": "object" + }, + { + "additionalProperties": false, + "description": "Payment identifier and optional Lightning proof; retain the issued L402 macaroon for merchant verification. Base settlement requires a transaction hash and matching x402 credential.", + "examples": [ + { + "paymentHash": "abababababababababababababababababababababababababababababababab", + "preimage": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + }, + { + "paymentHash": "0xabababababababababababababababababababababababababababababababab", + "txHash": "0xabababababababababababababababababababababababababababababababab" + } + ], + "not": { + "required": [ + "preimage", + "txHash" + ] + }, + "properties": { + "action": { + "const": "settle", + "description": "Verify or execute payment settlement. Example: \"settle\".", + "example": "settle", + "examples": [ + "settle" + ], + "type": "string" + }, + "paymentHash": { + "description": "L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "pattern": "^(0x)?[0-9a-fA-F]{64}$", + "type": "string" + }, + "paymentMacaroon": { + "description": "Original invoice macaroon, separate from this tool's paid access credential. Constraints: minLength: 1; maxLength: 8192. Example: \"eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ\".", + "example": "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ", + "examples": [ + "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ" + ], + "maxLength": 8192, + "minLength": 1, + "type": "string" + }, + "preimage": { + "description": "Optional L402 preimage, NWC_LOOKUP, or UUID hint; the issued macaroon and exact merchant settlement remain required. Constraints: pattern: ^([0-9a-fA-F]{64}|[0-9a-fA-F]{8}(-[0-9a-fA-F]{4}){3}-[0-9a-fA-F]{12}|NWC_LOOKUP|nwc_lookup)$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\".", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "pattern": "^([0-9a-fA-F]{64}|[0-9a-fA-F]{8}(-[0-9a-fA-F]{4}){3}-[0-9a-fA-F]{12}|NWC_LOOKUP|nwc_lookup)$", + "type": "string" + }, + "txHash": { + "description": "Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: \"0xabababababababababababababababababababababababababababababababab\".", + "example": "0xabababababababababababababababababababababababababababababababab", + "examples": [ + "0xabababababababababababababababababababababababababababababababab" + ], + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + } + }, + "required": [ + "action", + "paymentHash" + ], + "type": "object" + } +] - changed
Input schema / properties / preimage / descriptionPrevious value: -"L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\"."New value: +"Optional L402 preimage, NWC_LOOKUP, or UUID hint; the issued macaroon and exact merchant settlement remain required. Constraints: pattern: ^([0-9a-fA-F]{64}|[0-9a-fA-F]{8}(-[0-9a-fA-F]{4}){3}-[0-9a-fA-F]{12}|NWC_LOOKUP|nwc_lookup)$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\"." - changed
Input schema / properties / preimage / patternPrevious value: -"^[0-9a-fA-F]{64}$"New value: +"^([0-9a-fA-F]{64}|[0-9a-fA-F]{8}(-[0-9a-fA-F]{4}){3}-[0-9a-fA-F]{12}|NWC_LOOKUP|nwc_lookup)$"
5 tool updates
- Changed
stratigraphy.get34 fields changed- changed
Input schema / properties / blockHeight / descriptionPrevious value: -"Select one indexed non-negative dataset height (e.g. 850000), not an arbitrary live chain lookup; cannot combine with days, date, or range bounds. Constraints: minimum: 0. Example: 850000."New value: +"Select one actual captured non-negative Bitcoin height or the current live height; never a synthetic date-to-height index. Cannot combine with days, date, or range bounds. Constraints: minimum: 0. Example: 850000." - changed
Input schema / properties / metrics / descriptionPrevious value: -"Unique telemetry metric keys to project into each selected record's quantitative_alpha; omit for all metrics, or choose one or more allowed names. Constraints: minItems: 1. Example: [\"target_multiplier\"]."New value: +"Deprecated legacy projection hint retained for compatibility; the live source returns complete pipeline records regardless of this hint. Inspect live_metrics for the real pipeline field names. Constraints: minItems: 1. Example: [\"target_multiplier\"]." - changed
Input schema / properties / metrics / items / descriptionPrevious value: -"Allowed thermodynamic metric name to include in each returned quantitative_alpha object. Constraints: allowed values: target_multiplier, difficulty_epoch_progress, thermodynamic_signal. Example: \"target_multiplier\"."New value: +"Deprecated hint such as target_multiplier; does not project the current pipeline snapshot. Constraints: allowed values: target_multiplier, difficulty_epoch_progress, thermodynamic_signal. Example: \"target_multiplier\"." - changed
Output schema / descriptionPrevious value: -"Bitcoin Stratigraphy telemetry query result."New value: +"Paid, full fresh pipeline telemetry and exact selected historical Object Storage JSON/.ots receipts; records contain live or archived pipeline snapshots, never video-index data. Semantic discovery: Hal Finney Horizon tracker = $10,000,000 / BTC USD price; this is a valuation multiple, not a time-to-price forecast. The 15 J/TH thermodynamic energy calculation estimates watts as (network hashrate H/s / 1e12) * 15, not measured electricity. Sovereign Node RPC telemetry uses local Bitcoin Core; price and horizon are unavailable without a fiat quote." - changed
Output schema / examplesPrevious value: -[ - { - "records": [ - { - "day": 422, - "quantitative_alpha": { - "difficulty_epoch_progress": "73.42%", - "target_multiplier": 125.83, - "thermodynamic_signal": "accumulation" - }, - "title": "Bitcoin Stratigraphy Day 422", - "transcript_summary": "Mining economics and thermodynamic support strengthened.", - "video_id": "dQw4w9WgXcQ" - } - ] - } -]New value: +[ + { + "archive_state": "available", + "historical_proofs": [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ], + "live_metrics": { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + }, + "proofAvailable": true, + "proof_coverage": "Exact archived snapshot_json only; changing live_metrics are not covered.", + "records": [ + { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + } + ] + } +] - added
Output schema / properties / archive_stateAdded value: +{ + "description": "available or no_archives; no synthetic receipt is created.", + "example": "available", + "examples": [ + "available" + ], + "type": "string" +} - added
Output schema / properties / historical_proofsAdded value: +{ + "description": "All archived snapshots returned by this call, or latest available archive for a live-only result.", + "examples": [ + [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ] + ], + "items": { + "additionalProperties": false, + "description": "Exact Object Storage JSON bytes and current .ots bytes, including in-place Bitcoin upgrades; proof binds snapshot_json, never changing live_metrics.", + "examples": [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ], + "properties": { + "bundle_download_url": { + "description": "Cloud historical proof bundle_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/download", + "examples": [ + "/agent-api/historical-proof/2026-10-12/download" + ], + "type": "string" + }, + "date": { + "description": "Cloud historical proof date.", + "example": "2026-10-12", + "examples": [ + "2026-10-12" + ], + "type": "string" + }, + "ots_download_url": { + "description": "Cloud historical proof ots_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/ots", + "examples": [ + "/agent-api/historical-proof/2026-10-12/ots" + ], + "type": "string" + }, + "ots_filename": { + "description": "Cloud historical proof ots_filename.", + "example": "snapshot_2026-10-12.json.ots", + "examples": [ + "snapshot_2026-10-12.json.ots" + ], + "type": "string" + }, + "ots_proof_base64": { + "description": "Cloud historical proof ots_proof_base64.", + "example": "AQID", + "examples": [ + "AQID" + ], + "type": "string" + }, + "ots_sha256": { + "description": "Cloud historical proof ots_sha256.", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "type": "string" + }, + "proof_status": { + "description": "Cloud historical proof proof_status.", + "example": "bitcoin_attestation_present_unverified", + "examples": [ + "bitcoin_attestation_present_unverified" + ], + "type": "string" + }, + "snapshot_download_url": { + "description": "Cloud historical proof snapshot_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/snapshot", + "examples": [ + "/agent-api/historical-proof/2026-10-12/snapshot" + ], + "type": "string" + }, + "snapshot_filename": { + "description": "Cloud historical proof snapshot_filename.", + "example": "snapshot_2026-10-12.json", + "examples": [ + "snapshot_2026-10-12.json" + ], + "type": "string" + }, + "snapshot_json": { + "description": "Cloud historical proof snapshot_json.", + "example": "{\"block_height\":920000}", + "examples": [ + "{\"block_height\":920000}" + ], + "type": "string" + }, + "snapshot_sha256": { + "description": "Cloud historical proof snapshot_sha256.", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "type": "string" + } + }, + "required": [ + "date", + "snapshot_filename", + "ots_filename", + "snapshot_json", + "snapshot_sha256", + "ots_sha256", + "ots_proof_base64", + "proof_status", + "snapshot_download_url", + "ots_download_url", + "bundle_download_url" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / live_metricsAdded value: +{ + "additionalProperties": true, + "description": "Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null.", + "examples": [ + { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + } + ], + "properties": { + "attribution": { + "description": "Current pipeline attribution; not a value reconstructed from the historical video index.", + "example": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "examples": [ + "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption)." + ], + "type": "string" + }, + "block_height": { + "description": "Current pipeline block_height; not a value reconstructed from the historical video index.", + "example": 920000, + "examples": [ + 920000 + ], + "type": "number" + }, + "btc_price_usd": { + "description": "Current pipeline btc_price_usd; not a value reconstructed from the historical video index.", + "example": 80000, + "examples": [ + 80000 + ], + "type": [ + "number", + "null" + ] + }, + "efficiency_baseline_j_th": { + "description": "Current pipeline efficiency_baseline_j_th; not a value reconstructed from the historical video index.", + "example": 15, + "examples": [ + 15 + ], + "type": "number" + }, + "hal_finney_horizon_multiple": { + "description": "Current pipeline hal_finney_horizon_multiple; not a value reconstructed from the historical video index.", + "example": 125, + "examples": [ + 125 + ], + "type": [ + "number", + "null" + ] + }, + "hal_finney_horizon_target_usd": { + "description": "Current pipeline hal_finney_horizon_target_usd; not a value reconstructed from the historical video index.", + "example": 10000000, + "examples": [ + 10000000 + ], + "type": "number" + }, + "network_energy_watts": { + "description": "Current pipeline network_energy_watts; not a value reconstructed from the historical video index.", + "example": 15000000000, + "examples": [ + 15000000000 + ], + "type": "number" + }, + "network_hashrate_h_s": { + "description": "Current pipeline network_hashrate_h_s; not a value reconstructed from the historical video index.", + "example": 1e+21, + "examples": [ + 1e+21 + ], + "type": "number" + }, + "network_hashrate_th_s": { + "description": "Current pipeline network_hashrate_th_s; not a value reconstructed from the historical video index.", + "example": 1000000000, + "examples": [ + 1000000000 + ], + "type": "number" + }, + "observed_at_utc": { + "description": "Current pipeline observed_at_utc; not a value reconstructed from the historical video index.", + "example": "2026-10-12T00:00:00+00:00", + "examples": [ + "2026-10-12T00:00:00+00:00" + ], + "type": "string" + }, + "snapshot_age_seconds": { + "description": "Current pipeline snapshot_age_seconds; not a value reconstructed from the historical video index.", + "example": 2, + "examples": [ + 2 + ], + "type": "number" + } + }, + "required": [ + "block_height", + "observed_at_utc", + "btc_price_usd", + "hal_finney_horizon_target_usd", + "hal_finney_horizon_multiple", + "attribution", + "network_hashrate_h_s", + "network_hashrate_th_s", + "network_energy_watts", + "efficiency_baseline_j_th", + "snapshot_age_seconds" + ], + "type": "object" +} - added
Output schema / properties / proofAvailableAdded value: +{ + "description": "True only if an archived JSON/OTS pair was returned.", + "example": true, + "examples": [ + true + ], + "type": "boolean" +} - added
Output schema / properties / proof_coverageAdded value: +{ + "description": "Only exact archived JSON is covered by each receipt, never live metrics.", + "example": "Exact archived snapshot_json only; changing live_metrics are not covered.", + "examples": [ + "Exact archived snapshot_json only; changing live_metrics are not covered." + ], + "type": "string" +} - changed
Output schema / properties / records / descriptionPrevious value: -"Validated telemetry records matching the requested range. Example: [{\"day\":422,\"title\":\"Bitcoin Stratigraphy Day 422\",\"video_id\":\"dQw4w9WgXcQ\",\"transcript_summary\":\"Mining economics and thermodynamic support strengthened.\",\"quantitative_alpha\":{\"target_multiplier\":125.83,\"difficulty_epoch_progress\":\"73.42%\",\"thermodynamic_signal\":\"accumulation\"}}]."New value: +"Selected actual live or UTC-archived complete pipeline snapshots." - removed
Output schema / properties / records / exampleRemoved value: -[ - { - "day": 422, - "quantitative_alpha": { - "difficulty_epoch_progress": "73.42%", - "target_multiplier": 125.83, - "thermodynamic_signal": "accumulation" - }, - "title": "Bitcoin Stratigraphy Day 422", - "transcript_summary": "Mining economics and thermodynamic support strengthened.", - "video_id": "dQw4w9WgXcQ" - } -] - changed
Output schema / properties / records / examplesPrevious value: -[ - [ - { - "day": 422, - "quantitative_alpha": { - "difficulty_epoch_progress": "73.42%", - "target_multiplier": 125.83, - "thermodynamic_signal": "accumulation" - }, - "title": "Bitcoin Stratigraphy Day 422", - "transcript_summary": "Mining economics and thermodynamic support strengthened.", - "video_id": "dQw4w9WgXcQ" - } - ] -]New value: +[ + [ + { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + } + ] +] - changed
Output schema / properties / records / items / additionalPropertiesPrevious value: -falseNew value: +true - changed
Output schema / properties / records / items / descriptionPrevious value: -"A validated Bitcoin Stratigraphy telemetry entry."New value: +"Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null." - changed
Output schema / properties / records / items / examplesPrevious value: -[ - { - "day": 422, - "quantitative_alpha": { - "difficulty_epoch_progress": "73.42%", - "target_multiplier": 125.83, - "thermodynamic_signal": "accumulation" - }, - "title": "Bitcoin Stratigraphy Day 422", - "transcript_summary": "Mining economics and thermodynamic support strengthened.", - "video_id": "dQw4w9WgXcQ" - } -]New value: +[ + { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + } +] - added
Output schema / properties / records / items / properties / attributionAdded value: +{ + "description": "Current pipeline attribution; not a value reconstructed from the historical video index.", + "example": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "examples": [ + "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption)." + ], + "type": "string" +} - added
Output schema / properties / records / items / properties / block_heightAdded value: +{ + "description": "Current pipeline block_height; not a value reconstructed from the historical video index.", + "example": 920000, + "examples": [ + 920000 + ], + "type": "number" +} - added
Output schema / properties / records / items / properties / btc_price_usdAdded value: +{ + "description": "Current pipeline btc_price_usd; not a value reconstructed from the historical video index.", + "example": 80000, + "examples": [ + 80000 + ], + "type": [ + "number", + "null" + ] +} - removed
Output schema / properties / records / items / properties / dayRemoved value: -{ - "description": "One-based day number in the Bitcoin Stratigraphy dataset. Example: 422.", - "example": 422, - "examples": [ - 422 - ], - "type": "integer" -} - added
Output schema / properties / records / items / properties / efficiency_baseline_j_thAdded value: +{ + "description": "Current pipeline efficiency_baseline_j_th; not a value reconstructed from the historical video index.", + "example": 15, + "examples": [ + 15 + ], + "type": "number" +} - added
Output schema / properties / records / items / properties / hal_finney_horizon_multipleAdded value: +{ + "description": "Current pipeline hal_finney_horizon_multiple; not a value reconstructed from the historical video index.", + "example": 125, + "examples": [ + 125 + ], + "type": [ + "number", + "null" + ] +} - added
Output schema / properties / records / items / properties / hal_finney_horizon_target_usdAdded value: +{ + "description": "Current pipeline hal_finney_horizon_target_usd; not a value reconstructed from the historical video index.", + "example": 10000000, + "examples": [ + 10000000 + ], + "type": "number" +} - added
Output schema / properties / records / items / properties / network_energy_wattsAdded value: +{ + "description": "Current pipeline network_energy_watts; not a value reconstructed from the historical video index.", + "example": 15000000000, + "examples": [ + 15000000000 + ], + "type": "number" +} - added
Output schema / properties / records / items / properties / network_hashrate_h_sAdded value: +{ + "description": "Current pipeline network_hashrate_h_s; not a value reconstructed from the historical video index.", + "example": 1e+21, + "examples": [ + 1e+21 + ], + "type": "number" +} - added
Output schema / properties / records / items / properties / network_hashrate_th_sAdded value: +{ + "description": "Current pipeline network_hashrate_th_s; not a value reconstructed from the historical video index.", + "example": 1000000000, + "examples": [ + 1000000000 + ], + "type": "number" +} - added
Output schema / properties / records / items / properties / observed_at_utcAdded value: +{ + "description": "Current pipeline observed_at_utc; not a value reconstructed from the historical video index.", + "example": "2026-10-12T00:00:00+00:00", + "examples": [ + "2026-10-12T00:00:00+00:00" + ], + "type": "string" +} - removed
Output schema / properties / records / items / properties / quantitative_alphaRemoved value: -{ - "additionalProperties": false, - "description": "Quantitative thermodynamic indicators for one entry.", - "examples": [ - { - "difficulty_epoch_progress": "73.42%", - "target_multiplier": 125.83, - "thermodynamic_signal": "accumulation" - } - ], - "properties": { - "difficulty_epoch_progress": { - "description": "Bitcoin mining difficulty epoch progress formatted as a percentage. Example: \"73.42%\".", - "example": "73.42%", - "examples": [ - "73.42%" - ], - "type": "string" - }, - "target_multiplier": { - "description": "Thermodynamic valuation multiplier derived for this day. Example: 125.83.", - "example": 125.83, - "examples": [ - 125.83 - ], - "type": "number" - }, - "thermodynamic_signal": { - "description": "Human-readable thermodynamic market signal. Example: \"accumulation\".", - "example": "accumulation", - "examples": [ - "accumulation" - ], - "type": "string" - } - }, - "type": "object" -} - added
Output schema / properties / records / items / properties / snapshot_age_secondsAdded value: +{ + "description": "Current pipeline snapshot_age_seconds; not a value reconstructed from the historical video index.", + "example": 2, + "examples": [ + 2 + ], + "type": "number" +} - removed
Output schema / properties / records / items / properties / titleRemoved value: -{ - "description": "Title of the source research episode. Example: \"Bitcoin Stratigraphy Day 422\".", - "example": "Bitcoin Stratigraphy Day 422", - "examples": [ - "Bitcoin Stratigraphy Day 422" - ], - "type": "string" -} - removed
Output schema / properties / records / items / properties / transcript_summaryRemoved value: -{ - "description": "Concise summary of the source transcript and market interpretation. Example: \"Mining economics and thermodynamic support strengthened.\".", - "example": "Mining economics and thermodynamic support strengthened.", - "examples": [ - "Mining economics and thermodynamic support strengthened." - ], - "type": "string" -} - removed
Output schema / properties / records / items / properties / video_idRemoved value: -{ - "description": "Source video identifier used to trace research provenance. Example: \"dQw4w9WgXcQ\".", - "example": "dQw4w9WgXcQ", - "examples": [ - "dQw4w9WgXcQ" - ], - "type": "string" -} - changed
Output schema / properties / records / items / requiredPrevious value: -[ - "day", - "title", - "video_id", - "transcript_summary", - "quantitative_alpha" -]New value: +[ + "block_height", + "observed_at_utc", + "btc_price_usd", + "hal_finney_horizon_target_usd", + "hal_finney_horizon_multiple", + "attribution", + "network_hashrate_h_s", + "network_hashrate_th_s", + "network_energy_watts", + "efficiency_baseline_j_th", + "snapshot_age_seconds" +] - changed
Output schema / requiredPrevious value: -[ - "records" -]New value: +[ + "records", + "live_metrics", + "historical_proofs", + "proofAvailable", + "archive_state", + "proof_coverage" +]
- Changed
stratigraphy.get_diff23 fields changed- changed
Output schema / descriptionPrevious value: -"Signed difference between two indexed daily records. Percent change is rounded to two decimal places; source data provides a target multiplier, not a direct difficulty or energy measurement."New value: +"Paid signed deltas between real-height live/archived snapshots, including 15 J/TH power change; includes live metrics and exact archived proof bytes. Semantic discovery: Hal Finney Horizon tracker = $10,000,000 / BTC USD price; this is a valuation multiple, not a time-to-price forecast. The 15 J/TH thermodynamic energy calculation estimates watts as (network hashrate H/s / 1e12) * 15, not measured electricity. Sovereign Node RPC telemetry uses local Bitcoin Core; price and horizon are unavailable without a fiat quote." - changed
Output schema / examplesPrevious value: -[ - { - "delta": { - "heightDelta": 144, - "multiplierDelta": 0.33, - "percentageChange": "0.26%", - "timeSpanDays": 1 - }, - "from": { - "date": "2026-09-08", - "height": 919856, - "target_multiplier": 125.5 - }, - "to": { - "date": "2026-09-09", - "height": 920000, - "target_multiplier": 125.83 - } - } -]New value: +[ + { + "archive_state": "available", + "delta": { + "energyWattsDelta": 14000000000, + "heightDelta": 100, + "multiplierDelta": -1, + "percentageChange": "-0.79%", + "timeSpanDays": 1 + }, + "from": { + "date": "2026-10-12T00:00:00+00:00", + "height": 919900, + "network_energy_watts": 1000000000, + "target_multiplier": 126 + }, + "historical_proofs": [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ], + "live_metrics": { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + }, + "proofAvailable": true, + "proof_coverage": "Exact archived snapshot_json only; changing live_metrics are not covered.", + "to": { + "date": "2026-10-12T00:00:00+00:00", + "height": 920000, + "network_energy_watts": 15000000000, + "target_multiplier": 125 + } + } +] - added
Output schema / properties / archive_stateAdded value: +{ + "description": "available or no_archives; no synthetic receipt is created.", + "example": "available", + "examples": [ + "available" + ], + "type": "string" +} - removed
Output schema / properties / delta / additionalPropertiesRemoved value: -false - changed
Output schema / properties / delta / descriptionPrevious value: -"Signed change from the starting indexed entry to the ending entry."New value: +"Signed arithmetic deltas; watts derive from the assumed 15 J/TH baseline." - changed
Output schema / properties / delta / examplesPrevious value: -[ - { - "heightDelta": 144, - "multiplierDelta": 0.33, - "percentageChange": "0.26%", - "timeSpanDays": 1 - } -]New value: +[ + { + "heightDelta": 100 + } +] - removed
Output schema / properties / delta / propertiesRemoved value: -{ - "heightDelta": { - "description": "Ending indexed height minus starting indexed height. Example: 144.", - "example": 144, - "examples": [ - 144 - ], - "type": "integer" - }, - "multiplierDelta": { - "description": "Ending stored target multiplier minus starting multiplier. Example: 0.33.", - "example": 0.33, - "examples": [ - 0.33 - ], - "type": "number" - }, - "percentageChange": { - "description": "Multiplier change divided by starting multiplier, formatted as a percentage to two decimal places. Example: \"0.26%\".", - "example": "0.26%", - "examples": [ - "0.26%" - ], - "type": "string" - }, - "timeSpanDays": { - "description": "Signed number of UTC calendar days between indexed dates. Example: 1.", - "example": 1, - "examples": [ - 1 - ], - "type": "integer" - } -} - removed
Output schema / properties / delta / requiredRemoved value: -[ - "heightDelta", - "multiplierDelta", - "percentageChange", - "timeSpanDays" -] - removed
Output schema / properties / from / additionalPropertiesRemoved value: -false - changed
Output schema / properties / from / descriptionPrevious value: -"One indexed daily stratum; the height is a deterministic dataset index, not a live Bitcoin block height."New value: +"Real captured from-target values." - changed
Output schema / properties / from / examplesPrevious value: -[ - { - "date": "2026-09-08", - "height": 919856, - "target_multiplier": 125.5 - } -]New value: +[ + { + "height": 919900 + } +] - removed
Output schema / properties / from / propertiesRemoved value: -{ - "date": { - "description": "Indexed UTC calendar date. Constraints: format: date. Example: \"2026-09-08\".", - "example": "2026-09-08", - "examples": [ - "2026-09-08" - ], - "format": "date", - "type": "string" - }, - "height": { - "description": "Deterministic indexed height for the dataset day. Example: 919856.", - "example": 919856, - "examples": [ - 919856 - ], - "type": "integer" - }, - "target_multiplier": { - "description": "Stored target multiplier; not a measured energy quantity. Example: 125.5.", - "example": 125.5, - "examples": [ - 125.5 - ], - "type": "number" - } -} - removed
Output schema / properties / from / requiredRemoved value: -[ - "height", - "date", - "target_multiplier" -] - added
Output schema / properties / historical_proofsAdded value: +{ + "description": "All archived snapshots returned by this call, or latest available archive for a live-only result.", + "examples": [ + [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ] + ], + "items": { + "additionalProperties": false, + "description": "Exact Object Storage JSON bytes and current .ots bytes, including in-place Bitcoin upgrades; proof binds snapshot_json, never changing live_metrics.", + "examples": [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ], + "properties": { + "bundle_download_url": { + "description": "Cloud historical proof bundle_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/download", + "examples": [ + "/agent-api/historical-proof/2026-10-12/download" + ], + "type": "string" + }, + "date": { + "description": "Cloud historical proof date.", + "example": "2026-10-12", + "examples": [ + "2026-10-12" + ], + "type": "string" + }, + "ots_download_url": { + "description": "Cloud historical proof ots_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/ots", + "examples": [ + "/agent-api/historical-proof/2026-10-12/ots" + ], + "type": "string" + }, + "ots_filename": { + "description": "Cloud historical proof ots_filename.", + "example": "snapshot_2026-10-12.json.ots", + "examples": [ + "snapshot_2026-10-12.json.ots" + ], + "type": "string" + }, + "ots_proof_base64": { + "description": "Cloud historical proof ots_proof_base64.", + "example": "AQID", + "examples": [ + "AQID" + ], + "type": "string" + }, + "ots_sha256": { + "description": "Cloud historical proof ots_sha256.", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "type": "string" + }, + "proof_status": { + "description": "Cloud historical proof proof_status.", + "example": "bitcoin_attestation_present_unverified", + "examples": [ + "bitcoin_attestation_present_unverified" + ], + "type": "string" + }, + "snapshot_download_url": { + "description": "Cloud historical proof snapshot_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/snapshot", + "examples": [ + "/agent-api/historical-proof/2026-10-12/snapshot" + ], + "type": "string" + }, + "snapshot_filename": { + "description": "Cloud historical proof snapshot_filename.", + "example": "snapshot_2026-10-12.json", + "examples": [ + "snapshot_2026-10-12.json" + ], + "type": "string" + }, + "snapshot_json": { + "description": "Cloud historical proof snapshot_json.", + "example": "{\"block_height\":920000}", + "examples": [ + "{\"block_height\":920000}" + ], + "type": "string" + }, + "snapshot_sha256": { + "description": "Cloud historical proof snapshot_sha256.", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "type": "string" + } + }, + "required": [ + "date", + "snapshot_filename", + "ots_filename", + "snapshot_json", + "snapshot_sha256", + "ots_sha256", + "ots_proof_base64", + "proof_status", + "snapshot_download_url", + "ots_download_url", + "bundle_download_url" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / live_metricsAdded value: +{ + "additionalProperties": true, + "description": "Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null.", + "examples": [ + { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + } + ], + "properties": { + "attribution": { + "description": "Current pipeline attribution; not a value reconstructed from the historical video index.", + "example": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "examples": [ + "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption)." + ], + "type": "string" + }, + "block_height": { + "description": "Current pipeline block_height; not a value reconstructed from the historical video index.", + "example": 920000, + "examples": [ + 920000 + ], + "type": "number" + }, + "btc_price_usd": { + "description": "Current pipeline btc_price_usd; not a value reconstructed from the historical video index.", + "example": 80000, + "examples": [ + 80000 + ], + "type": [ + "number", + "null" + ] + }, + "efficiency_baseline_j_th": { + "description": "Current pipeline efficiency_baseline_j_th; not a value reconstructed from the historical video index.", + "example": 15, + "examples": [ + 15 + ], + "type": "number" + }, + "hal_finney_horizon_multiple": { + "description": "Current pipeline hal_finney_horizon_multiple; not a value reconstructed from the historical video index.", + "example": 125, + "examples": [ + 125 + ], + "type": [ + "number", + "null" + ] + }, + "hal_finney_horizon_target_usd": { + "description": "Current pipeline hal_finney_horizon_target_usd; not a value reconstructed from the historical video index.", + "example": 10000000, + "examples": [ + 10000000 + ], + "type": "number" + }, + "network_energy_watts": { + "description": "Current pipeline network_energy_watts; not a value reconstructed from the historical video index.", + "example": 15000000000, + "examples": [ + 15000000000 + ], + "type": "number" + }, + "network_hashrate_h_s": { + "description": "Current pipeline network_hashrate_h_s; not a value reconstructed from the historical video index.", + "example": 1e+21, + "examples": [ + 1e+21 + ], + "type": "number" + }, + "network_hashrate_th_s": { + "description": "Current pipeline network_hashrate_th_s; not a value reconstructed from the historical video index.", + "example": 1000000000, + "examples": [ + 1000000000 + ], + "type": "number" + }, + "observed_at_utc": { + "description": "Current pipeline observed_at_utc; not a value reconstructed from the historical video index.", + "example": "2026-10-12T00:00:00+00:00", + "examples": [ + "2026-10-12T00:00:00+00:00" + ], + "type": "string" + }, + "snapshot_age_seconds": { + "description": "Current pipeline snapshot_age_seconds; not a value reconstructed from the historical video index.", + "example": 2, + "examples": [ + 2 + ], + "type": "number" + } + }, + "required": [ + "block_height", + "observed_at_utc", + "btc_price_usd", + "hal_finney_horizon_target_usd", + "hal_finney_horizon_multiple", + "attribution", + "network_hashrate_h_s", + "network_hashrate_th_s", + "network_energy_watts", + "efficiency_baseline_j_th", + "snapshot_age_seconds" + ], + "type": "object" +} - added
Output schema / properties / proofAvailableAdded value: +{ + "description": "True only if an archived JSON/OTS pair was returned.", + "example": true, + "examples": [ + true + ], + "type": "boolean" +} - added
Output schema / properties / proof_coverageAdded value: +{ + "description": "Only exact archived JSON is covered by each receipt, never live metrics.", + "example": "Exact archived snapshot_json only; changing live_metrics are not covered.", + "examples": [ + "Exact archived snapshot_json only; changing live_metrics are not covered." + ], + "type": "string" +} - removed
Output schema / properties / to / additionalPropertiesRemoved value: -false - changed
Output schema / properties / to / descriptionPrevious value: -"One indexed daily stratum; the height is a deterministic dataset index, not a live Bitcoin block height."New value: +"Real captured to-target values." - changed
Output schema / properties / to / examplesPrevious value: -[ - { - "date": "2026-09-08", - "height": 919856, - "target_multiplier": 125.5 - } -]New value: +[ + { + "height": 920000 + } +] - removed
Output schema / properties / to / propertiesRemoved value: -{ - "date": { - "description": "Indexed UTC calendar date. Constraints: format: date. Example: \"2026-09-08\".", - "example": "2026-09-08", - "examples": [ - "2026-09-08" - ], - "format": "date", - "type": "string" - }, - "height": { - "description": "Deterministic indexed height for the dataset day. Example: 919856.", - "example": 919856, - "examples": [ - 919856 - ], - "type": "integer" - }, - "target_multiplier": { - "description": "Stored target multiplier; not a measured energy quantity. Example: 125.5.", - "example": 125.5, - "examples": [ - 125.5 - ], - "type": "number" - } -} - removed
Output schema / properties / to / requiredRemoved value: -[ - "height", - "date", - "target_multiplier" -] - changed
Output schema / requiredPrevious value: -[ - "from", - "to", - "delta" -]New value: +[ + "from", + "to", + "delta", + "live_metrics", + "historical_proofs", + "proofAvailable", + "archive_state", + "proof_coverage" +]
- Changed
stratigraphy.get_digest14 fields changed- changed
Output schema / descriptionPrevious value: -"Compressed digest plus a flag indicating whether source entries carry per-record proofs; a date range returns an array of results in ascending date order."New value: +"Paid SHA-256 fingerprints of actual cloud JSON bytes or current live pipeline JSON, with full live telemetry and associated archived receipts alongside them. Semantic discovery: Hal Finney Horizon tracker = $10,000,000 / BTC USD price; this is a valuation multiple, not a time-to-price forecast. The 15 J/TH thermodynamic energy calculation estimates watts as (network hashrate H/s / 1e12) * 15, not measured electricity. Sovereign Node RPC telemetry uses local Bitcoin Core; price and horizon are unavailable without a fiat quote." - changed
Output schema / examplesPrevious value: -[ - { - "proofAvailable": false, - "result": "HEIGHT:920000|DATE:2026-09-09|TM:125.83|HASH:0123456789abcdef" - } -]New value: +[ + { + "archive_state": "available", + "historical_proofs": [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ], + "live_metrics": { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + }, + "proofAvailable": true, + "proof_coverage": "Exact archived snapshot_json only; changing live_metrics are not covered.", + "result": "HEIGHT:920000|DATE:2026-10-12T00:00:00+00:00|TM:125|HASH:abababababababababababababababababababababababababababababababab" + } +] - added
Output schema / properties / archive_stateAdded value: +{ + "description": "available or no_archives; no synthetic receipt is created.", + "example": "available", + "examples": [ + "available" + ], + "type": "string" +} - added
Output schema / properties / historical_proofsAdded value: +{ + "description": "All archived snapshots returned by this call, or latest available archive for a live-only result.", + "examples": [ + [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ] + ], + "items": { + "additionalProperties": false, + "description": "Exact Object Storage JSON bytes and current .ots bytes, including in-place Bitcoin upgrades; proof binds snapshot_json, never changing live_metrics.", + "examples": [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ], + "properties": { + "bundle_download_url": { + "description": "Cloud historical proof bundle_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/download", + "examples": [ + "/agent-api/historical-proof/2026-10-12/download" + ], + "type": "string" + }, + "date": { + "description": "Cloud historical proof date.", + "example": "2026-10-12", + "examples": [ + "2026-10-12" + ], + "type": "string" + }, + "ots_download_url": { + "description": "Cloud historical proof ots_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/ots", + "examples": [ + "/agent-api/historical-proof/2026-10-12/ots" + ], + "type": "string" + }, + "ots_filename": { + "description": "Cloud historical proof ots_filename.", + "example": "snapshot_2026-10-12.json.ots", + "examples": [ + "snapshot_2026-10-12.json.ots" + ], + "type": "string" + }, + "ots_proof_base64": { + "description": "Cloud historical proof ots_proof_base64.", + "example": "AQID", + "examples": [ + "AQID" + ], + "type": "string" + }, + "ots_sha256": { + "description": "Cloud historical proof ots_sha256.", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "type": "string" + }, + "proof_status": { + "description": "Cloud historical proof proof_status.", + "example": "bitcoin_attestation_present_unverified", + "examples": [ + "bitcoin_attestation_present_unverified" + ], + "type": "string" + }, + "snapshot_download_url": { + "description": "Cloud historical proof snapshot_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/snapshot", + "examples": [ + "/agent-api/historical-proof/2026-10-12/snapshot" + ], + "type": "string" + }, + "snapshot_filename": { + "description": "Cloud historical proof snapshot_filename.", + "example": "snapshot_2026-10-12.json", + "examples": [ + "snapshot_2026-10-12.json" + ], + "type": "string" + }, + "snapshot_json": { + "description": "Cloud historical proof snapshot_json.", + "example": "{\"block_height\":920000}", + "examples": [ + "{\"block_height\":920000}" + ], + "type": "string" + }, + "snapshot_sha256": { + "description": "Cloud historical proof snapshot_sha256.", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "type": "string" + } + }, + "required": [ + "date", + "snapshot_filename", + "ots_filename", + "snapshot_json", + "snapshot_sha256", + "ots_sha256", + "ots_proof_base64", + "proof_status", + "snapshot_download_url", + "ots_download_url", + "bundle_download_url" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / live_metricsAdded value: +{ + "additionalProperties": true, + "description": "Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null.", + "examples": [ + { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + } + ], + "properties": { + "attribution": { + "description": "Current pipeline attribution; not a value reconstructed from the historical video index.", + "example": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "examples": [ + "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption)." + ], + "type": "string" + }, + "block_height": { + "description": "Current pipeline block_height; not a value reconstructed from the historical video index.", + "example": 920000, + "examples": [ + 920000 + ], + "type": "number" + }, + "btc_price_usd": { + "description": "Current pipeline btc_price_usd; not a value reconstructed from the historical video index.", + "example": 80000, + "examples": [ + 80000 + ], + "type": [ + "number", + "null" + ] + }, + "efficiency_baseline_j_th": { + "description": "Current pipeline efficiency_baseline_j_th; not a value reconstructed from the historical video index.", + "example": 15, + "examples": [ + 15 + ], + "type": "number" + }, + "hal_finney_horizon_multiple": { + "description": "Current pipeline hal_finney_horizon_multiple; not a value reconstructed from the historical video index.", + "example": 125, + "examples": [ + 125 + ], + "type": [ + "number", + "null" + ] + }, + "hal_finney_horizon_target_usd": { + "description": "Current pipeline hal_finney_horizon_target_usd; not a value reconstructed from the historical video index.", + "example": 10000000, + "examples": [ + 10000000 + ], + "type": "number" + }, + "network_energy_watts": { + "description": "Current pipeline network_energy_watts; not a value reconstructed from the historical video index.", + "example": 15000000000, + "examples": [ + 15000000000 + ], + "type": "number" + }, + "network_hashrate_h_s": { + "description": "Current pipeline network_hashrate_h_s; not a value reconstructed from the historical video index.", + "example": 1e+21, + "examples": [ + 1e+21 + ], + "type": "number" + }, + "network_hashrate_th_s": { + "description": "Current pipeline network_hashrate_th_s; not a value reconstructed from the historical video index.", + "example": 1000000000, + "examples": [ + 1000000000 + ], + "type": "number" + }, + "observed_at_utc": { + "description": "Current pipeline observed_at_utc; not a value reconstructed from the historical video index.", + "example": "2026-10-12T00:00:00+00:00", + "examples": [ + "2026-10-12T00:00:00+00:00" + ], + "type": "string" + }, + "snapshot_age_seconds": { + "description": "Current pipeline snapshot_age_seconds; not a value reconstructed from the historical video index.", + "example": 2, + "examples": [ + 2 + ], + "type": "number" + } + }, + "required": [ + "block_height", + "observed_at_utc", + "btc_price_usd", + "hal_finney_horizon_target_usd", + "hal_finney_horizon_multiple", + "attribution", + "network_hashrate_h_s", + "network_hashrate_th_s", + "network_energy_watts", + "efficiency_baseline_j_th", + "snapshot_age_seconds" + ], + "type": "object" +} - removed
Output schema / properties / proofAvailable / constRemoved value: -false - changed
Output schema / properties / proofAvailable / descriptionPrevious value: -"False for indexed dataset source entries; no per-record ZK proof is stored in this dataset. Example: false."New value: +"True only if an archived JSON/OTS pair was returned." - changed
Output schema / properties / proofAvailable / examplePrevious value: -falseNew value: +true - changed
Output schema / properties / proofAvailable / examplesPrevious value: -[ - false -]New value: +[ + true +] - added
Output schema / properties / proof_coverageAdded value: +{ + "description": "Only exact archived JSON is covered by each receipt, never live metrics.", + "example": "Exact archived snapshot_json only; changing live_metrics are not covered.", + "examples": [ + "Exact archived snapshot_json only; changing live_metrics are not covered." + ], + "type": "string" +} - changed
Output schema / properties / result / descriptionPrevious value: -"Selected compact string, minimal array or kv object; a date range returns an array of selected results. The hash is a SHA-256 record fingerprint, not a Bitcoin block hash or ZK proof. Example: \"HEIGHT:920000|DATE:2026-09-09|TM:125.83|HASH:0123456789abcdef\"."New value: +"compact text, minimal tuple, kv object, or arrays for bounded date ranges; hash is SHA-256 of exact archived JSON when available." - removed
Output schema / properties / result / exampleRemoved value: -"HEIGHT:920000|DATE:2026-09-09|TM:125.83|HASH:0123456789abcdef" - changed
Output schema / properties / result / examplesPrevious value: -[ - "HEIGHT:920000|DATE:2026-09-09|TM:125.83|HASH:0123456789abcdef" -]New value: +[ + "HEIGHT:920000|DATE:2026-10-12T00:00:00+00:00|TM:125|HASH:abababababababababababababababababababababababababababababababab" +] - changed
Output schema / requiredPrevious value: -[ - "result", - "proofAvailable" -]New value: +[ + "result", + "live_metrics", + "historical_proofs", + "proofAvailable", + "archive_state", + "proof_coverage" +]
- Changed
stratigraphy.get_range28 fields changed- changed
Output schema / descriptionPrevious value: -"Ascending indexed strata between inclusive bounds, truncated at limit. Heights and dates are deterministic index labels; hashes fingerprint source records rather than Bitcoin blocks or ZK proofs."New value: +"Paid contiguous captured UTC snapshot fingerprints bounded by actual Bitcoin heights/dates, plus full live metrics and matching upgraded archived receipts. Semantic discovery: Hal Finney Horizon tracker = $10,000,000 / BTC USD price; this is a valuation multiple, not a time-to-price forecast. The 15 J/TH thermodynamic energy calculation estimates watts as (network hashrate H/s / 1e12) * 15, not measured electricity. Sovereign Node RPC telemetry uses local Bitcoin Core; price and horizon are unavailable without a fiat quote." - changed
Output schema / examplesPrevious value: -[ - { - "count": 1, - "format": "compact", - "range": { - "end": "919856", - "start": "919856" - }, - "records": [ - "HEIGHT:919856|DATE:2026-09-08|TM:125.5|HASH:0123456789abcdef" - ] - } -]New value: +[ + { + "archive_state": "available", + "count": 1, + "format": "compact", + "historical_proofs": [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ], + "live_metrics": { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + }, + "proofAvailable": true, + "proof_coverage": "Exact archived snapshot_json only; changing live_metrics are not covered.", + "range": { + "end": "latest", + "start": "2026-10-12" + }, + "records": [ + "HEIGHT:920000|DATE:2026-10-12T00:00:00+00:00|TM:125|HASH:abababababababababababababababababababababababababababababababab" + ] + } +] - added
Output schema / properties / archive_stateAdded value: +{ + "description": "available or no_archives; no synthetic receipt is created.", + "example": "available", + "examples": [ + "available" + ], + "type": "string" +} - changed
Output schema / properties / count / descriptionPrevious value: -"Number of records returned, at most limit. Constraints: minimum: 1; maximum: 100. Example: 2."New value: +"Number of actual records returned." - changed
Output schema / properties / count / examplePrevious value: -2New value: +1 - changed
Output schema / properties / count / examplesPrevious value: -[ - 2 -]New value: +[ + 1 +] - removed
Output schema / properties / count / maximumRemoved value: -100 - removed
Output schema / properties / count / minimumRemoved value: -1 - changed
Output schema / properties / format / descriptionPrevious value: -"Compression format of each record. Constraints: allowed values: compact, minimal, kv. Example: \"compact\"."New value: +"compact, minimal, or kv response format." - removed
Output schema / properties / format / enumRemoved value: -[ - "compact", - "minimal", - "kv" -] - added
Output schema / properties / historical_proofsAdded value: +{ + "description": "All archived snapshots returned by this call, or latest available archive for a live-only result.", + "examples": [ + [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ] + ], + "items": { + "additionalProperties": false, + "description": "Exact Object Storage JSON bytes and current .ots bytes, including in-place Bitcoin upgrades; proof binds snapshot_json, never changing live_metrics.", + "examples": [ + { + "bundle_download_url": "/agent-api/historical-proof/2026-10-12/download", + "date": "2026-10-12", + "ots_download_url": "/agent-api/historical-proof/2026-10-12/ots", + "ots_filename": "snapshot_2026-10-12.json.ots", + "ots_proof_base64": "AQID", + "ots_sha256": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "proof_status": "bitcoin_attestation_present_unverified", + "snapshot_download_url": "/agent-api/historical-proof/2026-10-12/snapshot", + "snapshot_filename": "snapshot_2026-10-12.json", + "snapshot_json": "{\"block_height\":920000}", + "snapshot_sha256": "abababababababababababababababababababababababababababababababab" + } + ], + "properties": { + "bundle_download_url": { + "description": "Cloud historical proof bundle_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/download", + "examples": [ + "/agent-api/historical-proof/2026-10-12/download" + ], + "type": "string" + }, + "date": { + "description": "Cloud historical proof date.", + "example": "2026-10-12", + "examples": [ + "2026-10-12" + ], + "type": "string" + }, + "ots_download_url": { + "description": "Cloud historical proof ots_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/ots", + "examples": [ + "/agent-api/historical-proof/2026-10-12/ots" + ], + "type": "string" + }, + "ots_filename": { + "description": "Cloud historical proof ots_filename.", + "example": "snapshot_2026-10-12.json.ots", + "examples": [ + "snapshot_2026-10-12.json.ots" + ], + "type": "string" + }, + "ots_proof_base64": { + "description": "Cloud historical proof ots_proof_base64.", + "example": "AQID", + "examples": [ + "AQID" + ], + "type": "string" + }, + "ots_sha256": { + "description": "Cloud historical proof ots_sha256.", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "type": "string" + }, + "proof_status": { + "description": "Cloud historical proof proof_status.", + "example": "bitcoin_attestation_present_unverified", + "examples": [ + "bitcoin_attestation_present_unverified" + ], + "type": "string" + }, + "snapshot_download_url": { + "description": "Cloud historical proof snapshot_download_url.", + "example": "/agent-api/historical-proof/2026-10-12/snapshot", + "examples": [ + "/agent-api/historical-proof/2026-10-12/snapshot" + ], + "type": "string" + }, + "snapshot_filename": { + "description": "Cloud historical proof snapshot_filename.", + "example": "snapshot_2026-10-12.json", + "examples": [ + "snapshot_2026-10-12.json" + ], + "type": "string" + }, + "snapshot_json": { + "description": "Cloud historical proof snapshot_json.", + "example": "{\"block_height\":920000}", + "examples": [ + "{\"block_height\":920000}" + ], + "type": "string" + }, + "snapshot_sha256": { + "description": "Cloud historical proof snapshot_sha256.", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "type": "string" + } + }, + "required": [ + "date", + "snapshot_filename", + "ots_filename", + "snapshot_json", + "snapshot_sha256", + "ots_sha256", + "ots_proof_base64", + "proof_status", + "snapshot_download_url", + "ots_download_url", + "bundle_download_url" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / live_metricsAdded value: +{ + "additionalProperties": true, + "description": "Hal Finney Horizon tracker and 15 J/TH thermodynamic energy calculation. Horizon = $10,000,000 / btc_price_usd (a price multiple, not a forecast). Estimated network power in watts = (network_hashrate_h_s / 1e12) * 15. Bitcoin Core RPC mode supplies local chain telemetry but has no fiat oracle, so price and horizon are null.", + "examples": [ + { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "block_height": 920000, + "btc_price_usd": 80000, + "efficiency_baseline_j_th": 15, + "hal_finney_horizon_multiple": 125, + "hal_finney_horizon_target_usd": 10000000, + "network_energy_watts": 15000000000, + "network_hashrate_h_s": 1e+21, + "network_hashrate_th_s": 1000000000, + "observed_at_utc": "2026-10-12T00:00:00+00:00", + "snapshot_age_seconds": 2 + } + ], + "properties": { + "attribution": { + "description": "Current pipeline attribution; not a value reconstructed from the historical video index.", + "example": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "examples": [ + "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption)." + ], + "type": "string" + }, + "block_height": { + "description": "Current pipeline block_height; not a value reconstructed from the historical video index.", + "example": 920000, + "examples": [ + 920000 + ], + "type": "number" + }, + "btc_price_usd": { + "description": "Current pipeline btc_price_usd; not a value reconstructed from the historical video index.", + "example": 80000, + "examples": [ + 80000 + ], + "type": [ + "number", + "null" + ] + }, + "efficiency_baseline_j_th": { + "description": "Current pipeline efficiency_baseline_j_th; not a value reconstructed from the historical video index.", + "example": 15, + "examples": [ + 15 + ], + "type": "number" + }, + "hal_finney_horizon_multiple": { + "description": "Current pipeline hal_finney_horizon_multiple; not a value reconstructed from the historical video index.", + "example": 125, + "examples": [ + 125 + ], + "type": [ + "number", + "null" + ] + }, + "hal_finney_horizon_target_usd": { + "description": "Current pipeline hal_finney_horizon_target_usd; not a value reconstructed from the historical video index.", + "example": 10000000, + "examples": [ + 10000000 + ], + "type": "number" + }, + "network_energy_watts": { + "description": "Current pipeline network_energy_watts; not a value reconstructed from the historical video index.", + "example": 15000000000, + "examples": [ + 15000000000 + ], + "type": "number" + }, + "network_hashrate_h_s": { + "description": "Current pipeline network_hashrate_h_s; not a value reconstructed from the historical video index.", + "example": 1e+21, + "examples": [ + 1e+21 + ], + "type": "number" + }, + "network_hashrate_th_s": { + "description": "Current pipeline network_hashrate_th_s; not a value reconstructed from the historical video index.", + "example": 1000000000, + "examples": [ + 1000000000 + ], + "type": "number" + }, + "observed_at_utc": { + "description": "Current pipeline observed_at_utc; not a value reconstructed from the historical video index.", + "example": "2026-10-12T00:00:00+00:00", + "examples": [ + "2026-10-12T00:00:00+00:00" + ], + "type": "string" + }, + "snapshot_age_seconds": { + "description": "Current pipeline snapshot_age_seconds; not a value reconstructed from the historical video index.", + "example": 2, + "examples": [ + 2 + ], + "type": "number" + } + }, + "required": [ + "block_height", + "observed_at_utc", + "btc_price_usd", + "hal_finney_horizon_target_usd", + "hal_finney_horizon_multiple", + "attribution", + "network_hashrate_h_s", + "network_hashrate_th_s", + "network_energy_watts", + "efficiency_baseline_j_th", + "snapshot_age_seconds" + ], + "type": "object" +} - added
Output schema / properties / proofAvailableAdded value: +{ + "description": "True only if an archived JSON/OTS pair was returned.", + "example": true, + "examples": [ + true + ], + "type": "boolean" +} - added
Output schema / properties / proof_coverageAdded value: +{ + "description": "Only exact archived JSON is covered by each receipt, never live metrics.", + "example": "Exact archived snapshot_json only; changing live_metrics are not covered.", + "examples": [ + "Exact archived snapshot_json only; changing live_metrics are not covered." + ], + "type": "string" +} - removed
Output schema / properties / range / additionalPropertiesRemoved value: -false - changed
Output schema / properties / range / descriptionPrevious value: -"Requested bounds, including default latest if omitted."New value: +"Requested inclusive real height/date bounds." - changed
Output schema / properties / range / examplesPrevious value: -[ - { - "end": "latest", - "start": "919856" - } -]New value: +[ + { + "end": "latest", + "start": "2026-10-12" + } +] - removed
Output schema / properties / range / propertiesRemoved value: -{ - "end": { - "description": "Requested ending target. Example: \"latest\".", - "example": "latest", - "examples": [ - "latest" - ], - "type": "string" - }, - "start": { - "description": "Requested starting target. Example: \"919856\".", - "example": "919856", - "examples": [ - "919856" - ], - "type": "string" - } -} - removed
Output schema / properties / range / requiredRemoved value: -[ - "start", - "end" -] - changed
Output schema / properties / records / descriptionPrevious value: -"Records in ascending indexed order; compact strings, minimal arrays, or terse key-value objects. Constraints: minItems: 1; maxItems: 100. Example: [\"HEIGHT:919856|DATE:2026-09-08|TM:125.5|HASH:0123456789abcdef\"]."New value: +"Selected actual snapshot summaries, not a synthetic daily index." - removed
Output schema / properties / records / exampleRemoved value: -[ - "HEIGHT:919856|DATE:2026-09-08|TM:125.5|HASH:0123456789abcdef" -] - changed
Output schema / properties / records / examplesPrevious value: -[ - [ - "HEIGHT:919856|DATE:2026-09-08|TM:125.5|HASH:0123456789abcdef" - ] -]New value: +[ + [ + "HEIGHT:920000|DATE:2026-10-12T00:00:00+00:00|TM:125|HASH:abababababababababababababababababababababababababababababababab" + ] +] - changed
Output schema / properties / records / items / descriptionPrevious value: -"One compressed source-record digest. Example: \"HEIGHT:919856|DATE:2026-09-08|TM:125.5|HASH:0123456789abcdef\"."New value: +"One requested compact, minimal or kv summary." - removed
Output schema / properties / records / items / exampleRemoved value: -"HEIGHT:919856|DATE:2026-09-08|TM:125.5|HASH:0123456789abcdef" - changed
Output schema / properties / records / items / examplesPrevious value: -[ - "HEIGHT:919856|DATE:2026-09-08|TM:125.5|HASH:0123456789abcdef" -]New value: +[ + "HEIGHT:920000|DATE:2026-10-12T00:00:00+00:00|TM:125|HASH:abababababababababababababababababababababababababababababababab" +] - removed
Output schema / properties / records / maxItemsRemoved value: -100 - removed
Output schema / properties / records / minItemsRemoved value: -1 - changed
Output schema / requiredPrevious value: -[ - "range", - "count", - "format", - "records" -]New value: +[ + "range", + "count", + "format", + "records", + "live_metrics", + "historical_proofs", + "proofAvailable", + "archive_state", + "proof_coverage" +]
- Changed
stratigraphy.list41 fields changed- changed
Output schema / descriptionPrevious value: -"Discoverable bounds and metrics for the stratigraphy dataset."New value: +"Free, metadata-only discovery of real UTC archive bounds and current Bitcoin tip height; no paid snapshot or proof bytes. Historical height fields are actual captured heights. Semantic discovery: Hal Finney Horizon tracker = $10,000,000 / BTC USD price; this is a valuation multiple, not a time-to-price forecast. The 15 J/TH thermodynamic energy calculation estimates watts as (network hashrate H/s / 1e12) * 15, not measured electricity. Sovereign Node RPC telemetry uses local Bitcoin Core; price and horizon are unavailable without a fiat quote." - changed
Output schema / examplesPrevious value: -[ - { - "availableMetrics": [ - "day", - "title", - "video_id", - "transcript_summary", - "quantitative_alpha.target_multiplier", - "quantitative_alpha.difficulty_epoch_progress", - "quantitative_alpha.thermodynamic_signal" - ], - "dateBounds": { - "endDate": "2026-09-09", - "startDate": "2025-07-15" - }, - "newestBlock": 920000, - "oldestBlock": 859376, - "totalSnapshots": 422 - } -]New value: +[ + { + "attribution": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "availableMetrics": [ + "block_height", + "observed_at_utc", + "btc_price_usd", + "hal_finney_horizon_target_usd", + "hal_finney_horizon_multiple", + "attribution", + "network_hashrate_h_s", + "network_hashrate_th_s", + "network_energy_watts", + "efficiency_baseline_j_th", + "snapshot_age_seconds" + ], + "dateBounds": { + "endDate": "2026-10-12", + "startDate": "2026-10-12" + }, + "efficiency_baseline_j_th": 15, + "liveBlockHeight": 920000, + "newestBlock": 919900, + "oldestBlock": 919900, + "proofArchiveCount": 1, + "source": "stratigraphy_pipeline.py + Replit Object Storage", + "totalSnapshots": 1 + } +] - added
Output schema / properties / attributionAdded value: +{ + "description": "Verbatim historical attribution of the Hal Finney Horizon.", + "example": "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption).", + "examples": [ + "Projected by Hal Finney on January 10, 2009 ($10M per coin valuation under total global wealth absorption)." + ], + "type": "string" +} - changed
Output schema / properties / availableMetrics / descriptionPrevious value: -"Telemetry metric paths available in each stratigraphy snapshot. Example: [\"day\",\"title\",\"video_id\",\"transcript_summary\",\"quantitative_alpha.target_multiplier\",\"quantitative_alpha.difficulty_epoch_progress\",\"quantitative_alpha.thermodynamic_signal\"]."New value: +"Actual fields in the live pipeline model." - removed
Output schema / properties / availableMetrics / exampleRemoved value: -[ - "day", - "title", - "video_id", - "transcript_summary", - "quantitative_alpha.target_multiplier", - "quantitative_alpha.difficulty_epoch_progress", - "quantitative_alpha.thermodynamic_signal" -] - changed
Output schema / properties / availableMetrics / examplesPrevious value: -[ - [ - "day", - "title", - "video_id", - "transcript_summary", - "quantitative_alpha.target_multiplier", - "quantitative_alpha.difficulty_epoch_progress", - "quantitative_alpha.thermodynamic_signal" - ] -]New value: +[ + [ + "block_height", + "observed_at_utc", + "btc_price_usd", + "hal_finney_horizon_target_usd", + "hal_finney_horizon_multiple", + "attribution", + "network_hashrate_h_s", + "network_hashrate_th_s", + "network_energy_watts", + "efficiency_baseline_j_th", + "snapshot_age_seconds" + ] +] - changed
Output schema / properties / availableMetrics / items / descriptionPrevious value: -"Dot-delimited path of an available telemetry metric. Example: \"quantitative_alpha.target_multiplier\"."New value: +"One live pipeline field name." - changed
Output schema / properties / availableMetrics / items / examplePrevious value: -"quantitative_alpha.target_multiplier"New value: +"network_energy_watts" - changed
Output schema / properties / availableMetrics / items / examplesPrevious value: -[ - "quantitative_alpha.target_multiplier" -]New value: +[ + "network_energy_watts" +] - removed
Output schema / properties / dateBounds / additionalPropertiesRemoved value: -false - changed
Output schema / properties / dateBounds / descriptionPrevious value: -"Inclusive ISO date bounds of the available snapshots."New value: +"Actual captured archive UTC date bounds." - changed
Output schema / properties / dateBounds / examplesPrevious value: -[ - { - "endDate": "2026-09-09", - "startDate": "2025-07-15" - } -]New value: +[ + { + "endDate": "2026-10-12", + "startDate": "2026-10-12" + } +] - changed
Output schema / properties / dateBounds / properties / endDate / descriptionPrevious value: -"ISO 8601 date of the newest available snapshot. Constraints: format: date. Example: \"2026-09-09\"."New value: +"Latest captured UTC date, or null." - changed
Output schema / properties / dateBounds / properties / endDate / examplePrevious value: -"2026-09-09"New value: +"2026-10-12" - changed
Output schema / properties / dateBounds / properties / endDate / examplesPrevious value: -[ - "2026-09-09" -]New value: +[ + "2026-10-12" +] - removed
Output schema / properties / dateBounds / properties / endDate / formatRemoved value: -"date" - changed
Output schema / properties / dateBounds / properties / endDate / typePrevious value: -"string"New value: +[ + "string", + "null" +] - changed
Output schema / properties / dateBounds / properties / startDate / descriptionPrevious value: -"ISO 8601 date of the oldest available snapshot. Constraints: format: date. Example: \"2025-07-15\"."New value: +"Earliest captured UTC date, or null." - changed
Output schema / properties / dateBounds / properties / startDate / examplePrevious value: -"2025-07-15"New value: +"2026-10-12" - changed
Output schema / properties / dateBounds / properties / startDate / examplesPrevious value: -[ - "2025-07-15" -]New value: +[ + "2026-10-12" +] - removed
Output schema / properties / dateBounds / properties / startDate / formatRemoved value: -"date" - changed
Output schema / properties / dateBounds / properties / startDate / typePrevious value: -"string"New value: +[ + "string", + "null" +] - added
Output schema / properties / efficiency_baseline_j_thAdded value: +{ + "description": "Assumed fixed hardware efficiency used by live power estimate.", + "example": 15, + "examples": [ + 15 + ], + "type": "integer" +} - added
Output schema / properties / liveBlockHeightAdded value: +{ + "description": "Current live tip from the pipeline, not an indexed archive height.", + "example": 920000, + "examples": [ + 920000 + ], + "type": "integer" +} - changed
Output schema / properties / newestBlock / descriptionPrevious value: -"Highest block height in the deterministic daily snapshot index. Constraints: minimum: 0. Example: 920000."New value: +"Real block height of the newest archive, or null." - changed
Output schema / properties / newestBlock / examplePrevious value: -920000New value: +919900 - changed
Output schema / properties / newestBlock / examplesPrevious value: -[ - 920000 -]New value: +[ + 919900 +] - removed
Output schema / properties / newestBlock / minimumRemoved value: -0 - changed
Output schema / properties / newestBlock / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - changed
Output schema / properties / oldestBlock / descriptionPrevious value: -"Lowest block height in the deterministic daily snapshot index. Constraints: minimum: 0. Example: 859376."New value: +"Real block height of the oldest archive, or null." - changed
Output schema / properties / oldestBlock / examplePrevious value: -859376New value: +919900 - changed
Output schema / properties / oldestBlock / examplesPrevious value: -[ - 859376 -]New value: +[ + 919900 +] - removed
Output schema / properties / oldestBlock / minimumRemoved value: -0 - changed
Output schema / properties / oldestBlock / typePrevious value: -"integer"New value: +[ + "integer", + "null" +] - added
Output schema / properties / proofArchiveCountAdded value: +{ + "description": "Number of complete JSON/OTS archive pairs.", + "example": 1, + "examples": [ + 1 + ], + "type": "integer" +} - added
Output schema / properties / sourceAdded value: +{ + "description": "Authoritative pipeline and Object Storage origins.", + "example": "stratigraphy_pipeline.py + Replit Object Storage", + "examples": [ + "stratigraphy_pipeline.py + Replit Object Storage" + ], + "type": "string" +} - changed
Output schema / properties / totalSnapshots / descriptionPrevious value: -"Total number of daily stratigraphy snapshots currently available. Constraints: minimum: 1. Example: 422."New value: +"Number of JSON snapshots captured in Object Storage." - changed
Output schema / properties / totalSnapshots / examplePrevious value: -422New value: +1 - changed
Output schema / properties / totalSnapshots / examplesPrevious value: -[ - 422 -]New value: +[ + 1 +] - removed
Output schema / properties / totalSnapshots / minimumRemoved value: -1 - changed
Output schema / requiredPrevious value: -[ - "totalSnapshots", - "oldestBlock", - "newestBlock", - "availableMetrics", - "dateBounds" -]New value: +[ + "totalSnapshots", + "oldestBlock", + "newestBlock", + "liveBlockHeight", + "availableMetrics", + "dateBounds", + "efficiency_baseline_j_th", + "attribution", + "proofArchiveCount", + "source" +]
2 tool updates
- Changed
payment.get_info8 fields changed- changed
Input schema / oneOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "query", - "default": "query", - "description": "Pricing query (default). Example: \"query\".", - "example": "query", - "examples": [ - "query" - ], - "type": "string" - }, - "toolName": { - "description": "Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.get_digest' or 'proof.verify'); supported legacy aliases are also accepted and resolve to canonical names. When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name or supported legacy alias. Constraints: minLength: 1. Example: \"stratigraphy.get_digest\".", - "example": "stratigraphy.get_digest", - "examples": [ - "stratigraphy.get_digest" - ], - "minLength": 1, - "type": "string" - } - }, - "type": "object" - }, - { - "additionalProperties": false, - "description": "Payment identifier and one payment proof; the matching signed L402 or x402 credential must be supplied in HTTP headers.", - "examples": [ - { - "paymentHash": "abababababababababababababababababababababababababababababababab", - "preimage": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" - }, - { - "paymentHash": "0xabababababababababababababababababababababababababababababababab", - "txHash": "0xabababababababababababababababababababababababababababababababab" - } - ], - "oneOf": [ - { - "required": [ - "preimage" - ] - }, - { - "required": [ - "txHash" - ] - } - ], - "properties": { - "action": { - "const": "settle", - "description": "Verify or execute payment settlement. Example: \"settle\".", - "example": "settle", - "examples": [ - "settle" - ], - "type": "string" - }, - "paymentHash": { - "description": "L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", - "example": "abababababababababababababababababababababababababababababababab", - "examples": [ - "abababababababababababababababababababababababababababababababab" - ], - "pattern": "^(0x)?[0-9a-fA-F]{64}$", - "type": "string" - }, - "preimage": { - "description": "L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\".", - "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", - "examples": [ - "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" - ], - "pattern": "^[0-9a-fA-F]{64}$", - "type": "string" - }, - "txHash": { - "description": "Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: \"0xabababababababababababababababababababababababababababababababab\".", - "example": "0xabababababababababababababababababababababababababababababababab", - "examples": [ - "0xabababababababababababababababababababababababababababababababab" - ], - "pattern": "^0x[0-9a-fA-F]{64}$", - "type": "string" - } - }, - "required": [ - "action", - "paymentHash" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "action": { + "const": "query", + "default": "query", + "description": "Pricing query (default). Example: \"query\".", + "example": "query", + "examples": [ + "query" + ], + "type": "string" + }, + "toolName": { + "description": "Optional case-sensitive canonical MCP tool identifier (e.g., 'stratigraphy.get_digest' or 'proof.verify'); supported legacy aliases are also accepted and resolve to canonical names. When provided, filters output to return pricing specifically for that single tool. When omitted, returns the full pricing map across all registered catalog tools. Must match an exact registered tool name or supported legacy alias. Constraints: minLength: 1. Example: \"stratigraphy.get_digest\".", + "example": "stratigraphy.get_digest", + "examples": [ + "stratigraphy.get_digest" + ], + "minLength": 1, + "type": "string" + } + }, + "type": "object" + }, + { + "additionalProperties": false, + "description": "Payment identifier and one payment proof; the matching signed L402 or x402 credential must be supplied in HTTP headers.", + "examples": [ + { + "paymentHash": "abababababababababababababababababababababababababababababababab", + "preimage": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + }, + { + "paymentHash": "0xabababababababababababababababababababababababababababababababab", + "txHash": "0xabababababababababababababababababababababababababababababababab" + } + ], + "oneOf": [ + { + "required": [ + "preimage" + ] + }, + { + "required": [ + "txHash" + ] + } + ], + "properties": { + "action": { + "const": "settle", + "description": "Verify or execute payment settlement. Example: \"settle\".", + "example": "settle", + "examples": [ + "settle" + ], + "type": "string" + }, + "paymentHash": { + "description": "L402 SHA-256 invoice hash, or Base tx hash when using x402. Constraints: pattern: ^(0x)?[0-9a-fA-F]{64}$. Example: \"abababababababababababababababababababababababababababababababab\".", + "example": "abababababababababababababababababababababababababababababababab", + "examples": [ + "abababababababababababababababababababababababababababababababab" + ], + "pattern": "^(0x)?[0-9a-fA-F]{64}$", + "type": "string" + }, + "paymentMacaroon": { + "description": "Original invoice macaroon, separate from this tool's paid access credential. Constraints: minLength: 1; maxLength: 8192. Example: \"eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ\".", + "example": "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ", + "examples": [ + "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ" + ], + "maxLength": 8192, + "minLength": 1, + "type": "string" + }, + "preimage": { + "description": "L402 32-byte hex preimage; also send Authorization: L402 <server-issued macaroon>:<preimage>. Constraints: pattern: ^[0-9a-fA-F]{64}$. Example: \"cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd\".", + "example": "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd", + "examples": [ + "cdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcdcd" + ], + "pattern": "^[0-9a-fA-F]{64}$", + "type": "string" + }, + "txHash": { + "description": "Base mainnet transaction hash, accepted only after facilitator settlement of PAYMENT-SIGNATURE. Constraints: pattern: ^0x[0-9a-fA-F]{64}$. Example: \"0xabababababababababababababababababababababababababababababababab\".", + "example": "0xabababababababababababababababababababababababababababababababab", + "examples": [ + "0xabababababababababababababababababababababababababababababababab" + ], + "pattern": "^0x[0-9a-fA-F]{64}$", + "type": "string" + } + }, + "required": [ + "action", + "paymentHash" + ], + "type": "object" + } +] - added
Input schema / properties / paymentMacaroonAdded value: +{ + "description": "Original invoice macaroon, separate from this tool's paid access credential. Constraints: minLength: 1; maxLength: 8192. Example: \"eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ\".", + "example": "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ", + "examples": [ + "eyJtYWNhcm9vbiI6ImV4YW1wbGUifQ" + ], + "maxLength": 8192, + "minLength": 1, + "type": "string" +} - changed
Output schema / properties / activeAuthSchemes / descriptionPrevious value: -"Authentication scheme for paid MCP calls; free discovery and payment.get_info require none. Example: [\"L402\"]."New value: +"Authentication schemes for paid MCP calls. Only stratigraphy.list and proof.list execute free. Example: [\"L402\"]." - changed
Output schema / properties / macaroonRequirements / descriptionPrevious value: -"A valid payment proof must match the bound invoice, provider, amount, path, expiry and single-use restriction. proof.attenuate is free but requires a valid parent token."New value: +"A valid payment proof must match the bound invoice, provider, amount, path, expiry and request quota. proof.attenuate requires payment and a valid parent token." - removed
Output schema / properties / macaroonRequirements / properties / maxRequests / constRemoved value: -1 - changed
Output schema / properties / macaroonRequirements / properties / maxRequests / descriptionPrevious value: -"Each issued paid-tool macaroon is single-use. Example: 1."New value: +"Default credentials allow one call; X-L402-Batch-Size: 100 buys a tool-scoped 100-call credential. Constraints: allowed values: 1, 100. Example: 1." - added
Output schema / properties / macaroonRequirements / properties / maxRequests / enumAdded value: +[ + 1, + 100 +] - changed
Output schema / properties / macaroonRequirements / properties / maxRequests / examplesPrevious value: -[ - 1 -]New value: +[ + 1, + 100 +]
- Added
proof.notarize
Publisher details
- Operator
- Charles R. Strogish · Publisher source
- Operator website
- https://bitcoinstratigraphy.com · Publisher source
- Vendor relationship
- First-party · Publisher source
- Documentation
- https://bitcoinstratigraphy.com · Publisher source
- Trust center
- https://bitcoinstratigraphy.com · Publisher source
- Restrictions
- Paid execution requires L402 Lightning Network micropayment settlement (250 sats per call) or an active Enterprise Commercial License. · Publisher source
Related MCP Connectors
Score, seal and prove AI decisions in Bitcoin, plus 739 compliance checks, free to verify.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Bitcoin intelligence API. Pay per call via L402 Lightning (10-200 sats). No accounts needed.
Bitcoin-anchored, tamper-evident audit-permanence layer for AI agents, FRE 902(13)/(14)-shaped.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceMetered log ingestion server for autonomous agents, allowing NDJSON log posting with USDC payment per line on Base L2. Agents can freely tail and search their own logs with configurable retention tiers.MIT
EVIDIQ Notary MCPofficial
AlicenseNot gradedqualityBmaintenanceCryptographic receipt layer for AI inferences. Enables notarization and verification of AI outputs with on-chain proofs via x402 payment.1MIT
A-Pay Protocolofficial
AlicenseBqualityAmaintenanceUniversal HTTP 402 Micropayment Protocol & Autonomous Economic Settlement Engine for AI Agents on Base L2.5140 PyPIMIT
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.