Chime already owns the hard part: ChimeCore, a homegrown core banking platform built to embed AI safely without leaning on black-box vendors or legacy infrastructure, with human oversight and accountability at every stage. Hive doesn’t re-run any of that. Hive takes each AI-assisted action the control plane already governs and turns it into an independently signed, portable receipt under a post-quantum signature — so the control plane’s decisions become provable to an examiner, a partner, or a member, long after the moment passed.
Figures above are Chime’s own published numbers, cited from the Chime newsroom (chime.com/newsroom) — reported by Chime, not asserted by Hive. They show the scale at which AI already acts inside Chime; Hive’s role is to make that scale provable.
Every governed AI action crosses the same independent rail on its way to a signed receipt — support replies, dispute triage, fraud checks, compliance operations. Illustrative visual of the live rail; not live production traffic.
Chime supplies the control plane and the accountability; Hive supplies the independent proof. Keeping the two roles separate is exactly what makes the proof worth anything to a regulator, a partner bank, or a member.
ChimeCore and human-overseen AI decide what happens across support, disputes, fraud triage, and compliance operations. That judgment is Chime’s, and stays Chime’s — Hive never makes the decision.
An internal log Chime writes about its own AI is credible but self-referential. An independent receipt — signed by a party with no stake in the outcome — is what an examiner or partner can treat as evidence rather than assertion.
Hive signs the attested conditions of the action — model and tool identity, guardrail and consent trace, human handoff, output hash — under ML-DSA-65 (NIST FIPS 204). It attests conditions and actions, never a verdict on the member.
For a fintech operating at Chime’s scale, partner-bank and examiner oversight is a standing, recurring request. This isn’t about whether Chime has controls — it does. It’s about how quickly the independent evidence of those controls can be assembled and handed to someone who wasn’t in the room.
Pick a surface. Each shows what Chime already does (with its own published facts), the one place a durable-proof gap tends to open, and the Hive receipt that closes it. Nothing here changes Chime’s methodology — the receipt wraps around the action Chime already governs.
Chime reports AI powers roughly 70% of support interactions, with cost to serve down 60% and member satisfaction more than doubled — all under human oversight (source 1).
Transcripts show what was said, but they aren’t independently signed evidence per interaction of which model/tool answered, which guardrails applied, and where a human took over — the record an examiner or partner asks for.
A signed support-action receipt binds model + tool identity, guardrail/consent trace, and human-handoff point under ML-DSA-65 — verifiable offline, no access to Chime’s systems required.
Runs member disputes and chargeback workflows where AI helps classify, gather evidence, and draft resolutions under human oversight — a regulated process with strict timing and documentation duties.
A dispute’s outcome plus its evidence is exactly what a regulator or network wants chain-of-custody on: which evidence was considered, which model assisted, which human decided, and when.
A dispute evidence bundle seals each artifact and step into one content-sealed, exportable receipt package a reviewer can re-verify — independently and after the fact.
Uses AI to triage suspicious activity at scale, escalating to humans where accountability requires it — part of the “human oversight at every stage” posture Chime describes.
Model scores drive action, but the per-decision trail — which model version, which features/tools, which guardrail fired, which human confirmed — isn’t an independently signed artifact.
AFiR emits an independent ML-DSA-65 receipt for each triage move — model identity, tool calls, escalation, and human confirmation — tying the automated score to the human who owned the call.
Operates compliance workflows — monitoring, reviews, and controls — increasingly assisted by AI, with humans accountable for the outcomes.
Controls are documented internally, but demonstrating to an examiner that a control actually ran, on which inputs, under which policy version — not just that a policy exists — is the hard part.
A control-execution receipt signs the policy version, inputs hash, model/tool used, and human sign-off — assembling into an audit-ready bundle exportable to a regulator as one verifiable package.
Where Chime surfaces risk or eligibility decisions, it maintains human accountability and explanation obligations that regulated finance requires.
An explanation given to a member should be provably the same one the model produced, tied to the model version and inputs — not a reconstruction after the fact.
An explanation receipt binds the model identity, the input hash, the explanation text hash, and the human reviewer — so the member-facing reason and the model’s reason are provably one and the same. Hive attests the trace, never the merits of the decision.
Runs many models and tools across support, fraud, and ops, with humans stepping in where accountability demands — a rich internal graph of who/what acted.
That graph lives in Chime’s systems. Once an artifact leaves — to a partner, an examiner, a member — which model, which tool, which human is no longer independently checkable.
Every Hive receipt carries model identity, tool identity, and human-handoff as first-class signed fields — the shared spine beneath support, dispute, fraud, and compliance receipts alike.
Under Regulation E, a bank generally has up to 10 business days to investigate a disputed electronic transaction (or issue provisional credit). The point isn’t to “win” the clock — it’s that when independent receipts are captured as the AI and humans act, the evidence is already assembled and signed before the window closes.
Receipts assemble as the action unfolds
Illustrative timeline only — not Chime’s actual process, and not legal or compliance advice. Hive attests the conditions and actions of the governed workflow (model identity, guardrail and consent trace, human handoff, output hash), never a verdict on the member or a guarantee of any regulatory outcome.
Every Hive receipt is signed with ML-DSA-65 (NIST FIPS 204 post-quantum signature) and is dual-signed alongside Ed25519. Tap a Chime workflow to see which primitives apply; the matching cards light up green.
Enter your own assumptions to estimate the operational proof footprint — how many signed evidence events a receipted deployment would produce and export. This is a planning estimate, not a quote: no revenue, pricing, or economics, just receipt volume.
Click the evidence a pilot would sign into a member-support or dispute action. Each component adds its fields to the exportable bundle preview — the same shape a reviewer or examiner would re-verify offline.
Click any step to see exactly what evidence Hive signs there. The decision and accountability are Chime’s; the signature, portability, and export are Hive’s.
This hits Hive’s public, no-auth x402 quote endpoint and returns a live settlement envelope with an ML-DSA-65 (FIPS 204) signed quote receipt. No key, no secret, nothing to install. To see signed receipts for real model calls, run the free live demo at /model-receipts/.
curl -sS -X POST https://receipts.thehiveryiq.com/v1/x402/quote \ -H 'Content-Type: application/json' \ -d '{"agent_did":"did:example:chime-support","profile":"nano"}'
The response includes the rail (USDC on Base 8453), a signed quote receipt, and its ML-DSA-65 / FIPS 204 post-quantum posture. To emit a paid receipt end-to-end, walk the live flow at /x402-checkout/; to start a pilot, request an activation key at /activate/. No secrets are ever placed on this page.
The same independent rail that receipts Chime’s AI, support, and compliance actions can receipt money movement — fraud interventions, dispute and Reg E evidence, account actions, and AI-assisted transfers. Stablecoins move value. Hive proves the intent, actor, policy, receipt, settlement state, and recoverability window around that movement.
Intent receipt: actor, amount, asset, recipient, policy context, authorization state — signed before anything leaves.
Submitted, relay-observed, chain-pending, escrowed, quarantined, or an issuer/custodian hold requested — the live state, receipted.
Chain-verified, receiver-attested, counter-transfer initiated, evidence-only, or a recovery bundle exported for a dispute or examiner.
A Hive receipt is a machine-readable proof-state object. Group receipts into receipt teams, bundles, or graphs — a dispute, a transfer, a support case — and Hive Ledger derives an R3Pv: a Receipt Relay, Recovery, and Routing Proof Vector. The vector encodes verification, policy, economic, healing/recoverability, routing, risk, and permitted-next-action state, so a person or workflow knows whether to continue, pause, escalate, hold, recover, or preserve evidence.
Verification & policy state, economic exposure, the healing/recoverability window, routing, risk, and the permitted next action — one object, not a pile of logs.
Fraud interventions, dispute & Reg E bundles, AI-assisted support, and transfer hold / release decisions — continue, pause, escalate, or route for human review.
Every decision points back to signed receipts. The vector is the summary; the receipts are the proof — replayable for the member, an examiner, or an audit.
The proof vector is now a live callable primitive — group signed receipts with POST /v1/r3pv/groups, then GET /v1/r3pv/vector?group_id=… returns a single Ed25519-signed vector that round-trips POST /v1/receipt/verify. For a member transfer under review, the signed vector reads like this:
{
"signed_vector": {
"vector_id": "r3pv.vector_…",
"key_id": "did:hive:hivemorph",
"algorithm": "Ed25519",
"vector": {
"schema": "r3pv-v1.0.0",
"verification_depth": "self_attested",
"weakest_proof_boundary": "self_attested",
"healing_state": "pre_broadcast_stoppable",
"policy_state": "not_evaluated",
"routing_recommendation": "require_approval",
"permitted_next_actions": ["hold", "require_approval", "preserve_evidence"]
}
},
"verification": { "ok": true, "verify_endpoint": "/v1/receipt/verify" }
}
The signed Receipt Relay and the live R3Pv proof-vector primitive are both callable now: GET /v1/r3pv/health, POST /v1/receipt-relay/event, POST /v1/r3pv/groups, and GET /v1/r3pv/vector all returned HTTP 200 on 2026-07-06, and the signed vector verified verified=true at /v1/receipt/verify. Round-trip is network-dependent — measure receipt latency separately from settlement / rail latency. Measured latency & runnable curl →
# sign a receipt for the event under review curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt-relay/event \ -H 'Content-Type: application/json' \ -d '{"action":"account_action","external_system":"chime", "actor":{"did":"did:example:support-agent"}, "payload":{"kind":"transfer_hold","reason":"review"}, "healing_state":"pre_broadcast_stoppable"}' \ | python3 -c 'import sys,json; json.dump(json.load(sys.stdin)["receipt"],open("r.json","w"))' # group it, then generate + sign the proof vector GID=$(curl -sS -X POST https://receipts.thehiveryiq.com/v1/r3pv/groups \ -H 'Content-Type: application/json' \ -d "{\"label\":\"chime\",\"receipts\":[$(cat r.json)]}" \ | python3 -c 'import sys,json; print(json.load(sys.stdin)["group_id"])') curl -s -w '\nvector %{time_total}s %{http_code}\n' \ "https://receipts.thehiveryiq.com/v1/r3pv/vector?group_id=$GID"
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 + R3Pv/Healing premium band + 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.
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.
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.
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.
{
"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" }
}
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}"
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, high_risk_agent — and 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.
Every action below hits a real, running Hive surface. Start with one paid receipt, test a model receipt for free, or request an activation key to scope a pilot.
Act I receipts the AI, support, and compliance actions Chime already runs — making today’s control plane independently provable. Act II points the same independent proof layer at what Chime has publicly said it is building toward: proactive, trusted financial assistants delivered with transparency, consent, and human safeguards (source 1). These are strategic options to weigh, not a claim that everything is live today.
Candidate line 01
Hive attests the assistant’s conditions and actions — never that a financial recommendation was right. That honest boundary is what keeps it credible to a regulator.
Candidate line 02
The chain of custody is the product; the bundle is the artifact that survives an audit.
Candidate line 03
Audit-surviving controls are a candidate category; the receipt graph is the audit trail.
Candidate line 04
x402 settlement and signed receipts are live; specific third-party agent-platform integrations are labelled as fast-follow, never asserted as shipped.
Candidate line 05
Issuer/custodian freeze and counter-transfer are labelled with integration, never asserted as live; the intent receipt and evidence bundle are provable today.
Act I proves what Chime runs today. Act II points the same independent proof layer at where Chime is heading — each a strategic option to weigh, harder to replicate because independence can’t be self-supplied, and none of them a claim that the line is live today.
Chime governs. Hive proves. Together the control plane isn’t only trusted — it’s independently provable.
Every link below is a real, running page — not a mock.
Public references for the Chime statements cited above. Where numbers appear on those pages, treat them as source-reported by Chime, not asserted here.