— R3Pv™ benchmark

Measure the R3Pv™ primitive yourself.

R3Pv™ — 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 fabricated.

Read this first

These are client round-trip times — they include your network, TLS, the Cloudflare edge, and the rail — not server signing time. Receipt latency should be measured separately from settlement / rail latency: a signed receipt is issued in milliseconds; the underlying money movement settles on the rail's own clock.

— Measured stages

What each stage costs, measured.

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–0.64s
Group creation	`POST /v1/r3pv/groups`	Live	~0.13s	0.11–0.50s
Vector generation (signed)	`GET /v1/r3pv/vector`	Live	~0.11s	0.10–0.28s
Verification (signature)	`POST /v1/receipt/verify`	Live	~0.12s	0.11–0.34s
Health / smoke	`GET /v1/r3pv/health`	Live	~0.12s	0.10–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.

— Reproduce it

Run the benchmark.

Copy, paste, run. The loops print time_total per call so you can compute your own median.

Receipt generation — sign 10 receipts (no funds move), print round-trip

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

Vector derivation + verification — sign one, then verify it 10×

# 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

Group + signed vector — team a receipt, generate the vector, verify it (all live)

# 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"

Verify the vector itself — a signed proof vector round-trips /v1/receipt/verify

# 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

Health / smoke — confirm the R3Pv primitive is up (HTTP 200 today)

curl -s -w '\nHTTP %{http_code} %{time_total}s\n' \
  https://receipts.thehiveryiq.com/v1/r3pv/health

— Latest smoke

Latest run — 2026-07-06.

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

See where the vector comes from.

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.

R3Pv on Hive Ledger Receipt Relay Payment Healing Postman collection

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.