Receipt an event, payment intent, API call, or on-chain transaction, then see it in Hive Ledger. The relay endpoints are live now. Circle and USDC direct integration is a next-stage target, not a live Circle call.
Hook any external action, API call, agent step, payment claim or on-chain transaction into Hive and get back a signed, verifiable receipt.
Evidence is graded honestly into tiers, so a receipt never over-claims: self_attested (your described
claim, signed as-is), relay_observed (Hive made the outbound call and signed the request and response hashes,
status, and timing it directly saw), and chain_verified (an on-chain tx read back from a public RPC and
confirmed), falling back to submitted_unverified when a chain read-back is not available. Every receipt
round-trips the public verifier against did:hive:hivemorph. This relay is how
any action joins the same signed proof layer as model calls and agent trips.
A relay receipt proves exactly what its evidence tier says, no more. A self_attested receipt signs the claim you described. It does not prove the underlying action happened. A relay_observed receipt is only issued when Hive itself made the HTTP call and signs the request hash, response hash, status, and timing it directly saw. A chain_verified receipt is only issued when a transaction was read back from a public RPC and confirmed. Circle and USDC are a receipt schema on the event endpoint. Hive signs your stablecoin-transfer claim, but it does not contact Circle. Nothing is ever made up, and the chain verifier never fails open.
/v1/receipt/verify. You can check it offline, ok.You describe an event: an API call, an agent action, an invoice paid, a stablecoin transfer. Hive signs it exactly as described.
Hive makes an SSRF-guarded outbound HTTP request itself and signs the request hash, response hash, status code, and timing it directly saw happen.
A named on-chain tx gets looked up on a public RPC (Base, Ethereum, Solana). Confirmed goes to chain_verified, a genuine miss goes to chain_not_found, and any RPC error goes to verification_unavailable.
The chain verifier only checks existence and status, and it never fails open. Any exception resolves to
verification_unavailable, never to a verified result. It does not decode transfer amounts or match
recipients. The relay_observed HTTP path refuses private, loopback, link-local, and cloud-metadata targets
(no open proxy, no SSRF), does not follow redirects, and caps body size and timeout.
/v1/receipt-relayliveAdvertises supported modes, evidence tiers, action schemas, the receipt schema, and the signer and verify endpoints. No key required, no secrets returned.
Signs a receipt over any event payload you describe. It hashes the intent plus any optional request, response, or evidence. Circle, USDC, generic API calls, and agent actions all land here as self-attested claims.
An SSRF-guarded outbound request Hive makes itself, signing the request hash, response hash, status,
and timing it directly saw. dry_run:true gives you a prepare-only signed event with no request made. There is no free tier
here, since it makes outbound calls.
Records a base, ethereum, or solana tx. It defaults to
submitted_unverified. verify:true runs a read-only public-RPC lookup that can upgrade the receipt to
chain_verified.
This calls receipts.thehiveryiq.com/v1/receipt-relay/health directly from your browser and
reads back the live schema version and the evidence tiers it advertises. If a fetch fails, the copyable
curl commands below still work on their own.
Discovery and verification are free. The event and chain endpoints allow a small
free per-IP burst, then return a real HTTP 402 with a redeemable x402 nonce. The http pass-through always
needs an activation key or x402 access token, because it makes outbound calls.
curl -sS https://receipts.thehiveryiq.com/v1/receipt-relay/health
curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt-relay/event \
-H 'Content-Type: application/json' \
-d '{"action":"stablecoin_transfer","external_system":"circle",
"payload":{"asset":"USDC","amount":"10.00","network":"base"},
"actor":{"agent_did":"did:example:agent"}}'
curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt-relay/http \
-H 'Content-Type: application/json' \
-H 'X-Hive-Activation-Key: tk_live_...' \
-d '{"url":"https://api.example.com/ping","method":"POST","body":"hi","dry_run":true}'
curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt-relay/chain \
-H 'Content-Type: application/json' \
-d '{"chain":"solana","tx":"<signature>","verify":true}'
curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt/verify \
-H 'Content-Type: application/json' \
-d '{"receipt_id":"<id>","payload_sha256":"<hash>","sig_b64u":"<sig>","ts":<ts>}'
Circle and USDC (and any stablecoin): a self_attested event on /event with
action:"stablecoin_transfer" and external_system:"circle". Hive signs the claim, but it does
not contact Circle. With an on-chain tx hash, the caller can move up to /chain with
verify:true for a chain_verified receipt. Direct Circle API integration is an
opportunity, not a live capability.
Solana: /chain with chain:"solana" and a transaction signature.
verify:true runs a getTransaction lookup. Confirmed goes to chain_verified with
slot and success. EVM (Base or Ethereum): /chain with the tx hash. verify:true runs an
eth_getTransactionByHash lookup. Confirmed goes to chain_verified with block number.
Hive does not claim every payment can be reversed. It proves what happened early enough to act where the rail allows it, and it proves what happened afterward when the rail does not allow it. The Circle/USDC-compatible receipt schema is live today. Direct Circle integration is next-stage.
R3Pv™ stands for Receipt Relay, Recovery, and Routing Proof Vectors. It is the layer on top: Receipt Relay signs, Hive Ledger groups receipts into teams and graphs, and R3Pv proof vectors route, recover, and heal. The vector primitive is live today: sign a receipt at /v1/receipt-relay/event, team receipts with POST /v1/r3pv/groups, then GET /v1/r3pv/vector?group_id=… returns one Ed25519-signed proof vector (verification_depth, weakest_proof_boundary, healing_state, routing_recommendation, permitted_next_actions) that itself round-trips /v1/receipt/verify. Smoke path: GET /v1/r3pv/health returns HTTP 200 today. See measured latency and runnable curl → Measure receipt latency separately from settlement or rail latency. At enterprise scale, protected flows group into Protected Flow Fleets → and package as a Proof Credit Profile →. You can model your own in the proof-state calculator.
"Receipt anything" refers to the relay's pass-through design, not a claim that every external action gets
independently verified. Evidence is graded into tiers: self_attested signs your described claim without
proving the underlying action happened; relay_observed is issued only when Hive itself made the outbound HTTP call
and signed what it directly saw; chain_verified is issued only when an on-chain tx was read back from
a public RPC and confirmed, and otherwise the event stays submitted_unverified,
chain_not_found, or verification_unavailable. Circle and USDC are receipt schemas on the event
endpoint, not live Circle API calls. Hive signs the transfer claim you describe and does not contact Circle. Chain
verification only checks existence and status, and does not decode transfer amounts or match recipients. The live
controls call receipts.thehiveryiq.com directly and reflect current state. Every relay receipt checks out
against did:hive:hivemorph through the public /v1/receipt/verify endpoint.