Hive Ledger™: the convenience layer for signed receipts

A searchable index for every signed action.

Start Receipting Now → Run a free model receipt Receipt any action

Run a signed receipt, then find it indexed and searchable right here. The ledger is the convenience layer; each row points back to a receipt that verifies on its own.

Hive Ledger™ is the searchable receipt index for AI actions, model calls, agent tasks, x402 payments, API workflows, and human-origin attestations. Each indexed row points back to a Hive Receipt that verifies on its own, canonical bytes, a SHA-256 hash, an Ed25519 signature, a published public key, and a public verifier. The ledger makes those receipts discoverable, searchable, and auditable. It is not required to trust them.

The one rule that matters

The ledger is convenience. The receipt is proof. Verification is portable: a receipt carries everything needed to check it offline: canonical bytes, hash, signature, and public key, verifiable by any party with no required call back to Hive. The ledger helps you find and audit receipts; it never sits between you and the truth of one.

The big distinction

The ledger is convenience. The receipt is proof.

Convenience layer

Hive Ledger™: index & discovery

  • Searchable index across every receipted event type
  • Query, filter, and paginate by sequence, event type, and time
  • Aggregate summaries for audit and reconciliation
  • Points at receipts. It does not replace or gate them
  • Optional: if the ledger is unreachable, receipts still verify
Proof layer

Hive Receipts: portable proof

  • Canonical bytes + SHA-256 hash bind the exact content
  • Ed25519 signature verifies against a published public key
  • Checkable offline by any party, re-verifiable later
  • No required call back to Hive to establish trust
  • Attests the operation, never a route on correctness
Architecture

From event to portable proof. The ledger sits to the side.

Trace one event through the pipeline. Proof is established at the offline verifier (green). The ledger index and any anchor / mirror are convenience and durability. They're additive, never on the trust path.

Event lifecycle
1 · Event
An AI action, model call, agent task, x402 payment, or attestation happens.
source
2 · Canonical payload
Fields are serialized to a single canonical byte encoding.
deterministic
3 · Hash
SHA-256 over the canonical bytes binds the content.
sha-256
4 · Signature
Ed25519 signs the receipt against the issuer key.
ed25519
5 · Offline verifier
Proof. Any party checks bytes, hash, signature, and key. No Hive call needed.
portable
6 · Ledger index
The verified receipt is indexed for search, discovery, and audit.
convenience
7 · Anchor / mirror
Optional durability: transparency-log root, customer mirror.
additive
Idle. Press “Trace an event”. Proof is established at step 5, before indexing.
Product modules

What Hive Ledger gives you.

Each module is tagged by what is live today versus next-stage or enterprise. Nothing here is required to verify a receipt. Every module is built on top of portable proof.

Receipt Explorer

Index API live

Browse, page, and inspect indexed receipts across every event type. The read API is live today; a fully embedded, browsable UI inside third-party apps is next-stage.

GET /v1/receipts · GET /v1/receipts/summary

Public Verifier

Live

Verify any receipt against the published Ed25519 public key. Free, and the proof is portable. The same check runs offline with no call back to Hive.

GET /v1/receipts/pubkey · GET /v1/receipts/verify/{seq}

x402 Payment Ledger

Live

Every x402 event becomes its own receipted row, real payment_required metadata on quote and emit. x402 is the only payment rail.

POST /v1/x402/quote · POST /v1/receipt/emit

Agent Action Ledger

Live

Agent-task receipts across registered adapters (Manus configured today). Index a full route as a chain of signed receipts. See Agent Trip.

GET /v1/agent-receipts/adapters

Transparency Anchors

Ed25519 log live

A signed, append-only Merkle accumulator: Ed25519-signed roots across canonical provenance domains, live today. External public / blockchain anchoring is next-stage; post-quantum ML-DSA roots are reserved for a future algorithm epoch.

GET /v1/accumulator/policy · GET /v1/accumulator/receipts/root

Audit Bundle Export

Next-stage

Today you can assemble an audit bundle yourself from the public index plus the offline verifier. Each receipt is self-contained. A one-click signed bundle export endpoint is next-stage.

Build from /v1/receipts + offline verify · one-click export = next-stage

Customer Ledger Mirror

Enterprise · next-stage

Per-tenant portal ledger read is live today. A fully customer-hosted, self-hosted mirror you run in your own infrastructure is an enterprise / next-stage capability, not live yet.

GET /v1/portal/{tenant}/ledger (read, live) · self-hosted mirror = enterprise

Embedded Explorer

Next-stage

A browsable receipt explorer embedded natively inside your own app or a partner surface. The read APIs exist today; the drop-in embedded UI is next-stage.

Built on /v1/receipts · embedded UI = next-stage
Live today vs next-stage

Exactly what is real right now.

Live today
  • Receipt index & summary: searchable ledger read API
  • Public key & public verifier: portable, offline-checkable
  • Model receipts: signed proof for model calls
  • x402 quote & receipt emit: real payment_required
  • Agent-task receipts: registered adapters (Manus)
  • Signed Ed25519 Merkle transparency log: accumulator roots
  • Per-tenant portal ledger read · activation keys
Next-stage / enterprise
  • External public / blockchain anchoring of roots
  • Fully customer-hosted, self-hosted mirror
  • Embedded browsable explorer inside third-party apps
  • One-click signed audit-bundle export endpoint
  • Post-quantum ML-DSA signature roots (future epoch)
Guardrail we hold to

We do not claim public blockchain anchoring is live. The live transparency log is a signed Ed25519 Merkle accumulator, and external public anchoring is next-stage. We do not claim a fully customer-hosted mirror is live. Per-tenant portal read is live, and self-hosting is enterprise / next-stage. And the ledger is never required to verify a receipt.

Live ledger

Read the index, live.

Read-only. This pulls the public ledger summary from receipts.thehiveryiq.com directly, numbers reflect current state. If the endpoint is briefly unreachable, the widget says so rather than inventing data.

Open raw JSON
Idle. Press “Load ledger summary”.
Indexed entries
...
Next sequence
...
Event types indexed
...
Signing algorithm
...
Public key
...
Developers

Call it yourself.

All read/verify endpoints below are live today against https://receipts.thehiveryiq.com. Verification is free and portable. The public key lets you check a receipt offline, with no call back to Hive.

Public key: verify receipts offline (Ed25519) curl https://receipts.thehiveryiq.com/v1/receipts/pubkey
Ledger index: list receipts (searchable, paginated) curl 'https://receipts.thehiveryiq.com/v1/receipts?limit=5'
Ledger summary: aggregate counts by event type curl https://receipts.thehiveryiq.com/v1/receipts/summary
Verify a receipt by sequence: returns the verification result curl https://receipts.thehiveryiq.com/v1/receipts/verify/13100
Model receipt: receipt a live model call curl -X POST https://receipts.thehiveryiq.com/v1/model-receipts/run \ -H 'Content-Type: application/json' \ -d '{"provider":"mistral","model":"leanstral-1-5","prompt":"State the theorem add_comm for Nat."}'
x402 quote: real payment_required metadata (x402 is the only payment rail) curl -X POST https://receipts.thehiveryiq.com/v1/x402/quote \ -H 'Content-Type: application/json' \ -d '{"sku":"receipt.emit"}'
Agent action ledger: registered agent-task adapters curl https://receipts.thehiveryiq.com/v1/agent-receipts/adapters
Transparency log: signed Ed25519 Merkle accumulator policy + root curl https://receipts.thehiveryiq.com/v1/accumulator/policy curl https://receipts.thehiveryiq.com/v1/accumulator/receipts/root
R3Pv™ proof vectors

From a receipt group to a signed proof vector.

R3Pv™, short for Receipt Relay, Recovery, and Routing Proof Vectors, is the higher-order layer the ledger builds from signed receipts: receipt group → receipt graph → signed proof vector → permitted next action. The vector encodes verification depth, policy, economic exposure, recoverability / healing, routing, risk, and the single permitted next action an agent or workflow may take. It is now a live callable primitive: POST /v1/r3pv/groups teams signed receipts, GET /v1/r3pv/vector?group_id=… generates and Ed25519-signs the vector under did:hive:hivemorph, and the vector itself round-trips POST /v1/receipt/verify. At enterprise scale these vectors underwrite Protected Flow Fleets → and package as a Proof Credit Profile →. Model your own in the proof-state calculator.

1 · Receipt group
Signed receipts that belong to one intent are teamed: by intent, actor, asset, or workflow.
2 · Receipt graph
Ordered edges between receipts: request → observe → settle → recover, each edge a signed row.
3 · Proof vector
Verification, policy, economic, recoverability, routing, risk fields, computed from the group's signed receipts.
4 · Permitted next action
continue · block · reroute · require_approval · recover · export_evidence: the one move the proof allows.
Live today: the R3Pv primitive
  • Receipt grouping: POST /v1/r3pv/groups teams signed receipts (inline objects and/or receipt IDs) with optional graph edges, and returns a group_id.
  • Signed vector object: GET /v1/r3pv/vector?group_id=… computes and Ed25519-signs the vector under did:hive:hivemorph. POST /v1/r3pv/vector does group + vector in one call.
  • Vector is verifiable: the signed vector round-trips POST /v1/receipt/verify (verified: true, signature-verified). It is a first-class proof object, not just JSON.
  • Discovery: GET /v1/r3pv/health declares the schema, signer, 11 healing states, and vector dimensions.
What the vector encodes: computed, not asserted
  • verification_depth (strongest tier) and weakest_proof_boundary (a group is only as provable as its weakest receipt).
  • healing_state / recoverability_window from the 11-state contract: the least-recoverable window across the group. No reversal of finalized chain txs.
  • economic_exposure (only when asset/amount are present), policy_state, routing_recommendation, and permitted_next_actions[].
  • Each dimension records whether it was computed from a signed receipt, declared by the caller, or not inferable. We keep that distinction honest.

The live pipeline is three calls: sign a receipt, group it, then generate the signed vector. All are live against https://receipts.thehiveryiq.com and were smoke-tested 2026-07-06.

1 · Sign a receipt (self-attested, free ≤30/IP/hr): no funds move curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt-relay/event \ -H 'Content-Type: application/json' \ -d '{"action":"stablecoin_transfer","external_system":"usdc","actor":{"did":"did:example:agent"}, "payload":{"asset":"USDC","amount":"25.00","from":"0xSender","to":"0xRecipient","network":"base","note":"no_funds_moved"}}'
2 · Group the receipt → get a group_id (live, free ≤30/IP/hr) # receipt.json = the "receipt" object from step 1 GID=$(curl -sS -X POST https://receipts.thehiveryiq.com/v1/r3pv/groups \ -H 'Content-Type: application/json' \ -d "{\"label\":\"agentic-payment-flow\",\"receipts\":[$(cat receipt.json)]}" \ | python3 -c 'import sys,json; print(json.load(sys.stdin)["group_id"])')
3 · Generate the signed proof vector, then verify the vector itself curl -sS "https://receipts.thehiveryiq.com/v1/r3pv/vector?group_id=$GID" # the signed vector round-trips the public verifier (verified: true) curl -sS "https://receipts.thehiveryiq.com/v1/r3pv/vector?group_id=$GID" \ | python3 -c 'import sys,json; v=json.load(sys.stdin)["signed_vector"]; json.dump({"receipt_id":v["vector_id"],"payload_sha256":v["payload_sha256"],"sig_b64u":v["sig_b64u"],"ts":v["ts"]}, open("vector.json","w"))' curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt/verify \ -H 'Content-Type: application/json' --data @vector.json
Live signed proof vector: real response from GET /v1/r3pv/vector (schema r3pv-v1.0.0)
{
  "signed_vector": {
    "vector_id": "r3pv.vector_1783314171_1943fee9f9ba",
    "payload_sha256": "0037409e…d8c1bbf",
    "sig_b64u": "YJXZqVrv98I6…tkP3aDg",
    "key_id": "did:hive:hivemorph",
    "algorithm": "Ed25519",
    "vector": {
      "schema": "r3pv-v1.0.0",
      "group_id": "r3pv.group_1783314047_e3ee9cb9351d",
      "receipt_count": 1, "resolved_receipts": 1, "unresolved_receipts": 0,
      "verification_depth":      { "strongest_tier": "self_attested", "source": "computed_from_signed_receipts" },
      "weakest_proof_boundary":  { "tier": "self_attested", "meaning": "The group is only provable up to its weakest receipt." },
      "healing_state":           "not_applicable",
      "recoverability_window":   { "state": "not_applicable", "note": "Rail-/window-dependent. R3Pv does not reverse finalized chain transactions." },
      "economic_exposure":       { "inferable": false, "note": "no asset/amount present on grouped receipts" },
      "policy_state":            "not_evaluated",
      "routing_recommendation":  "require_approval",
      "permitted_next_actions":  ["hold", "require_approval", "export_evidence"]
    }
  },
  "verification": { "ok": true, "verify_endpoint": "/v1/receipt/verify" }
}

This is a live response, not a mock. economic_exposure is inferable: false here because a standard relay receipt stores only an intent_hash, not cleartext amounts. Supply asset/amount on the grouped object and the vector computes exposure by asset. Unresolved receipt IDs weaken the vector and force require_approval; a settled / chain_verified receipt yields evidence_only_final with no recover action offered.

Benchmark the primitive yourself.

Real measured round-trip latency for receipt generation, group creation, signed-vector generation, and verification, all live, plus runnable curl, is published on the R3Pv benchmark page. Numbers are network-dependent round-trips, not server signing time.

Hive Protected Flow · signed decisions on top of R3Pv · live now

The signed proof vector becomes a signed decision: permit, hold, recover, or escalate, with a meter quote

R3Pv tells you the honest state of a receipt group. Hive Protected Flow is the premium decision layer that takes that vector, applies a declared policy pack and declared exposure at risk, and returns an Ed25519-signed assessment: one of eight decision classes (permit, permit_with_evidence, require_approval, hold, recover, reroute, escalate, block), the risk factors that drove it, the permitted next actions, and a three-part meter quote: platform fee, plus R3Pv/Healing premium band, plus optional basis points on protected exposure. The meter is a quote, not a settlement. No funds move. Overrides can only make policy stricter, never looser.

Signed decision, honestly derived

The decision is the strictest of the R3Pv routing recommendation, the exposure band, and any policy hard-fail. POST /v1/protected-flow/assess returns signed_assessment with decision, rationale, risk_factors, and permitted_next_actions, all signed by did:hive:hivemorph. The assessment round-trips /v1/receipt/verify like any Hive receipt.

Three-part meter (protected-value pricing)

Broad coverage prices as lightweight infrastructure. Protected/high-risk flow prices as protected value: platform_fee_usd + protection_premium_usd (banded by decision class) + optional exposure_premium_usd (basis points on declared exposure). Named policy packs ship today: default, strict_bank, high_risk_agent.

Evidence export, auditor-ready

GET /v1/protected-flow/evidence/{group_id}/export bundles the signed R3Pv vector, the latest signed assessment, the referenced signed receipts, and the signer's pubkey material into a single signed bundle. Everything an auditor needs to re-verify the whole flow offline, no Hive call required.

Live signed assessment · real response shape from POST /v1/protected-flow/assess
{
  "signed_assessment": {
    "assessment_id": "protected_flow.assessment_1783344027_2941ed841f06",
    "payload_sha256": "2d137891401ae1a8d1820478…",
    "sig_b64u": "lTCi2JjQO4c-y9SiHeGBWnk7…",
    "key_id": "did:hive:hivemorph",
    "algorithm": "Ed25519",
    "assessment": {
      "schema": "protected-flow-v1.0.0",
      "decision": "hold",
      "rationale": "r3pv_routing=require_approval→require_approval; exposure_band=permit; policy_hard_fail=hold; strictest wins.",
      "permitted_next_actions": ["hold","export_evidence","preserve_evidence"],
      "risk_factors": [
        {"factor": "weakest_boundary_below_policy", "severity": "high"}
      ],
      "policy_pack": {"name": "default", "require_min_tier": "relay_observed"},
      "declared_exposure_usd": 500.0,
      "meter_quote": {
        "platform_fee_usd": 0.10,
        "protection_premium_usd": 1.00,
        "exposure_premium_usd": 0.0001,
        "total_usd": 1.10,
        "note": "Quote only. No funds move."
      }
    }
  },
  "verification": { "ok": true, "verify_endpoint": "/v1/receipt/verify" }
}

Runnable smoke test: hit production yourself

Assess a Circle-shaped USDC intent under the default policy pack, then again under strict_bank. Same receipt, stricter policy → stricter decision. No funds move. This service never calls Circle APIs.

# Protected Flow: end-to-end smoke against live production
curl -sS https://receipts.thehiveryiq.com/v1/protected-flow/health | head -c 400; echo

# Sign a stablecoin-intent receipt (no funds moved)
curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt-relay/event \
  -H "Content-Type: application/json" \
  -d '{"action":"stablecoin_transfer","external_system":"circle","actor":{"did":"did:example:agent"},"payload":{"asset":"USDC","amount":"1000.00","from":"0xSender","to":"0xRecipient","network":"base","net_moved":"0.00"},"healing_state":"pre_broadcast_stoppable"}' \
  | python3 -c 'import sys,json; json.dump(json.load(sys.stdin)["receipt"], open("receipt.json","w"))'

# Assess (default policy, $500 exposure): expect hold on self_attested weakest boundary
curl -sS -X POST https://receipts.thehiveryiq.com/v1/protected-flow/assess \
  -H "Content-Type: application/json" \
  -d "{\"label\":\"circle-usdc\",\"receipts\":[$(cat receipt.json)],\"policy_pack\":\"default\",\"declared_exposure_usd\":500.0}"

# Assess (strict_bank policy, $50k exposure): expect hold with chain_verified requirement
curl -sS -X POST https://receipts.thehiveryiq.com/v1/protected-flow/assess \
  -H "Content-Type: application/json" \
  -d "{\"receipts\":[$(cat receipt.json)],\"policy_pack\":\"strict_bank\",\"declared_exposure_usd\":50000.0}"

Pricing framing

Broad coverage prices as lightweight infrastructure. Protected/high-risk flow prices as protected value: platform fee + R3Pv/Healing premium band + optional basis points on declared exposure. Named policy packs ship today: default, strict_bank, and high_risk_agent. Custom packs are a strategic-window conversation. Protected Flow is category-defining and, like R3Pv, it never reverses finalized chain transactions and never calls Circle APIs.

Start with one signed receipt.

The fastest way to understand the ledger is to put one receipt in it. Run a paid receipt over x402, test a model receipt, or request an activation key, then watch it appear in the index and verify it portably.

The receipted money-movement loop
1 · Receipt Relay signs The money-movement event is signed under Ed25519. It covers intent, actor, policy, asset, amount, and network. 2 · Hive Ledger searches, exports, verifies Every signed receipt is discoverable, exportable, and verifiable against the public verifier, with no shared secret. 3 · Payment Healing classifies recovery Rail-specific: pre-broadcast stop/revoke, escrow or quarantine hold, issuer/custodian freeze if integrated, counter-transfer recovery, or evidence-only after final settlement.

Hive does not claim every payment can be reversed. It proves what happened early enough to act where the rail allows, and proves what happened afterward when it does not. The Circle/USDC-compatible receipt schema is live today; direct Circle integration is next-stage.

R3Pv™ (Receipt Relay, Recovery, and Routing Proof Vectors) is the higher-order layer: Receipt Relay signs → R3Pv groups receipts into teams & graphs → R3Pv proof vectors route, recover, and heal. The vector primitive is live: POST /v1/r3pv/groups then GET /v1/r3pv/vector returns an Ed25519-signed vector that verifies at /v1/receipt/verify. Smoke path: /v1/r3pv/health returns HTTP 200 today. Measure receipt latency separately from settlement / rail latency.

Private by design. Hive does not store your prompts. Every request is already receipted by a one-way SHA-256 fingerprint, not the words. Proof, not surveillance.