R3Pv™, short for Receipt Relay, Recovery, and Routing Proof Vectors, is now a live callable primitive. Group signed Hive receipts, then generate a single Ed25519-signed proof vector that verifies on its own. This page publishes real, measured client round-trip latency for every stage, all live today, and runnable curl so you can reproduce every number. Nothing here is made up.
These are client round-trip times. They include your network, TLS, the Cloudflare edge, and the rail. They are not server signing time. You should measure receipt latency separately from settlement / rail latency. A signed receipt is issued in milliseconds; the underlying money movement settles on the rail's own clock.
Sampled from a single client on 2026-07-06, n=10 per stage, against
https://receipts.thehiveryiq.com. Your numbers will differ by network path and region. That is the point.
Reproduce them with the curl below.
| R3Pv stage | Endpoint | Status | Median | Observed range |
|---|---|---|---|---|
| Receipt generation | POST /v1/receipt-relay/event | Live | ~0.16s | 0.11 to 0.64s |
| Group creation | POST /v1/r3pv/groups | Live | ~0.13s | 0.11 to 0.50s |
| Vector generation (signed) | GET /v1/r3pv/vector | Live | ~0.11s | 0.10 to 0.28s |
| Verification (signature) | POST /v1/receipt/verify | Live | ~0.12s | 0.11 to 0.34s |
| Health / smoke | GET /v1/r3pv/health | Live | ~0.12s | 0.10 to 0.40s |
Every R3Pv stage is live as of 2026-07-06. POST /v1/r3pv/groups teams signed receipts into a
group; GET /v1/r3pv/vector?group_id=… computes and Ed25519-signs a proof vector
(verification_depth, weakest_proof_boundary, healing_state,
economic_exposure, policy_state, routing_recommendation,
permitted_next_actions) under did:hive:hivemorph. The vector itself round-trips
POST /v1/receipt/verify like any receipt. One cold-start / edge outlier (~5.3s on health) was observed and
excluded from the typical range above. That is a Cloudflare / cold-start artifact, not signing time.
Copy, paste, run. The loops print time_total per call so you can compute your own median.
for i in $(seq 1 10); do
curl -s -o /dev/null -w 'event %{time_total}s HTTP %{http_code}\n' \
-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"}}'
done
# 1) sign one receipt and keep just the receipt object
curl -s -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":"0xS","to":"0xR","network":"base","note":"no_funds_moved"}}' \
| python3 -c 'import sys,json; json.dump(json.load(sys.stdin)["receipt"], open("receipt.json","w"))'
# 2) derive the vector fields / verify 10×
for i in $(seq 1 10); do
curl -s -o /dev/null -w 'verify %{time_total}s HTTP %{http_code}\n' \
-X POST https://receipts.thehiveryiq.com/v1/receipt/verify \
-H 'Content-Type: application/json' --data @receipt.json
done
# 1) sign a receipt, keep the receipt object
curl -s -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","net_moved":"0.00","note":"no_funds_moved"}}' \
| python3 -c 'import sys,json; json.dump(json.load(sys.stdin)["receipt"], open("receipt.json","w"))'
# 2) create a group from that receipt → get a group_id
GID=$(curl -s -X POST https://receipts.thehiveryiq.com/v1/r3pv/groups \
-H 'Content-Type: application/json' \
-d "{\"label\":\"bench\",\"receipts\":[$(cat receipt.json)]}" \
| python3 -c 'import sys,json; print(json.load(sys.stdin)["group_id"])')
# 3) generate the signed proof vector for the group
curl -s -w '\nvector %{time_total}s HTTP %{http_code}\n' \
"https://receipts.thehiveryiq.com/v1/r3pv/vector?group_id=$GID"
# generate a vector, then verify its own signature (verified: true)
curl -s "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 -s -w '\nverify %{time_total}s HTTP %{http_code}\n' \
-X POST https://receipts.thehiveryiq.com/v1/receipt/verify \
-H 'Content-Type: application/json' --data @vector.json
curl -s -w '\nHTTP %{http_code} %{time_total}s\n' \
https://receipts.thehiveryiq.com/v1/r3pv/health
Captured with the commands above from a single client. Reproduce and you will get your own numbers.
| Call | Result |
|---|---|
GET /v1/r3pv/health | HTTP 200, engine r3pv, schema r3pv-v1.0.0, signer did:hive:hivemorph (Ed25519), 11 healing states |
POST /v1/receipt-relay/event | HTTP 200, signed receipt, verification.ok = true, tier self_attested, Ed25519 |
POST /v1/r3pv/groups | HTTP 200, group created (resolved=2, unresolved=1 on a mixed inline+id group) |
GET /v1/r3pv/vector | HTTP 200, signed vector, verification.ok = true, algorithm: Ed25519, key_id: did:hive:hivemorph, routing_recommendation + permitted_next_actions[] returned |
POST /v1/receipt/verify (on the vector) | HTTP 200, verified: true, proof_status: signature-verified. The proof vector is itself a verifiable object |
The proof vector is generated from signed receipts grouped via the live /v1/r3pv/* endpoints. Read the
R3Pv section for the full group → graph → signed vector → permitted-next-action model, or receipt anything against
the relay.
Honesty note. R3Pv™ is now a live primitive: GET /v1/r3pv/health, POST /v1/r3pv/groups,
GET /v1/r3pv/vector, and POST /v1/r3pv/vector all returned HTTP 200 when smoke-tested on
2026-07-06, and the generated vector verified with verified: true at /v1/receipt/verify. A
proof vector is derived from the receipts in its group. Each dimension records whether it was computed from a
signed receipt, declared by the caller, or not inferable; the vector attests the state of those receipts at signing
time, not that the underlying actions were correct or authorized. Published latencies are client round-trip times,
network-dependent, and are not a server signing benchmark; measure receipt latency separately from settlement / rail
latency. Hive proves what happened early enough to act where the rail allows, and proves what happened afterward when
it does not.
Hive Protected Flow is the premium decision layer on R3Pv. Give it an R3Pv group_id (or inline receipts), a declared policy pack, and a declared exposure at risk, and you get back an Ed25519-signed assessment (decision, rationale, risk_factors, permitted_next_actions) and a three-part meter quote (platform fee + R3Pv/Healing premium band + optional bps on protected exposure). Same signer, same canonical form, same /v1/receipt/verify round-trip as any Hive receipt. The meter is a quote, not a settlement, so no funds move.
curl -sS https://receipts.thehiveryiq.com/v1/protected-flow/health | head -c 400; echo
# sign one 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)
curl -sS -X POST https://receipts.thehiveryiq.com/v1/protected-flow/assess \
-H "Content-Type: application/json" \
-d "{\"label\":\"pf-smoke\",\"receipts\":[$(cat receipt.json)],\"policy_pack\":\"default\",\"declared_exposure_usd\":500.0}" \
| tee /tmp/pf1.json | python3 -c 'import sys,json; d=json.load(sys.stdin); print("decision:", d["signed_assessment"]["assessment"]["decision"]); print("total_usd:", d["signed_assessment"]["assessment"]["meter_quote"]["total_usd"])'
# assess same receipt under strict_bank policy at $50k
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}" \
| python3 -c 'import sys,json; d=json.load(sys.stdin); print("decision:", d["signed_assessment"]["assessment"]["decision"])'
# evidence export
GID=$(python3 -c 'import json; print(json.load(open("/tmp/pf1.json"))["group_id"])')
curl -sS "https://receipts.thehiveryiq.com/v1/protected-flow/evidence/$GID/export" | head -c 800; echo
Note: Protected Flow assessments carry a rationale string that names the strictest input, such as r3pv_routing=…, exposure_band=…, or policy_hard_fail=…. The strictest one wins. A self-attested weakest boundary under strict_bank hard-fails to hold; over-cap exposure hard-fails to block. Nothing over-permits.