Receipt a payment intent or event now. Pause, quarantine, and recovery controls apply where the rail allows. Healing is a defined spectrum, not universal reversibility: pre-broadcast stop or revoke, escrow or quarantine hold, issuer or custodian freeze if integrated, counter-transfer recovery, or evidence-only after final settlement.
Most agentic-payment safety products either can't act fast enough or pretend blockchain payments are always reversible. Neither is true. Hive receipts every step of an agentic payment: intent, policy check, signature, submission, settlement, and acts exactly as fast, and exactly as far, as each rail actually allows: pause, quarantine, revoke a key, request an issuer freeze, trigger a counter-transfer, or preserve evidence. This is not universal reversibility. Its value is honest classification of recoverability, built on the same signed Receipt Relay and Hive Ledger that underpin the rest of the proof layer. Recovery readiness is one dimension of a Proof Credit Profile →.
Hive does not claim that broadcast, finalized transactions on public blockchains can be reversed. Once a transfer reaches finality on a base-layer public chain, no software layer, Hive included, can claw the assets back without cooperation from whoever now controls them, or without the issuer holding a contractual / technical clawback capability.
Nothing here is a promise of FDIC/SIPC-style protection, Reg E chargeback rights, or guaranteed fund recovery. "Healing" describes a spectrum of outcomes, not a guarantee. The recoverability class of each payment path is shown as a visible property before an incident, not discovered after one.
Recoverability is a property of the rail and the integration depth, not of Hive alone. Every payment path resolves to one of these five outcomes, and Hive states which one applies going in.
Most fraud systems bolt detection onto a payment after the fact by watching logs. Receipted Payment Healing makes the receipt itself the control object: a payment intent cannot be authorized without first existing as a signed, hashed, policy-evaluated receipt, and every state transition appends to that same chain. That is what makes millisecond response possible. The system isn't searching for what happened. It already holds a live, structured object it is continuously re-scoring.
Who (agent id + human principal), what (amount, asset, destination), why (task or invoice reference), and when, all signed and hashed before any funds move.
Spend limits, velocity limits, destination allow / deny lists, jurisdiction rules, dual-control thresholds evaluated against org policy.
Novel destination, invoice text changed from the last known vendor record, velocity anomaly, poisoned-address near-match: all scored in real time.
A single-use payment-intent ID plus nonce is bound to the scored intent. It's not a free-floating amount and address the agent could replay.
Signed and broadcast, submitted to a custodial API, or queued to a processor. The exact payload and timestamp are receipted.
For rails with a pre-settlement window, scoring continues between submission and finality.
Freeze, quarantine, cancel, revoke, escalate, or counter-transfer: only the action the specific rail and stage actually supports. If final, evidence-only.
One cryptographically chained bundle of every step, including an explicit "no action was technically possible" state where that is the truth.
The stages are ordered by dependency, not hype. Early stages need only Hive-built infrastructure; later stages depend on third parties and, eventually, licensed-entity and regulatory posture.
Hive receipts intent, policy check, submission and outcome for agentic payments across supported rails. No blocking authority. Pure observability and audit trail. This runs on the Receipt Relay that is live today.
What's real at this stage: zero custody, minimal regulatory surface, and the strongest foundation for the Ledger / Verifier architecture.
Hold a payment intent pre-submission pending policy / risk clearance, and route eligible payments through Hive-deployed escrow / quarantine contracts on EVM / Solana where the customer opts in.
What's real at this stage: first real prevention power, but entirely within infrastructure Hive itself deploys or synchronous pre-signature hooks the customer's agent calls. No dependency on a third-party issuer API.
Direct integration with account-abstraction / session-key spending policies (ERC-4337 on EVM) and Solana program-based policy accounts, so Hive's risk score is a live input to the wallet's own signature authorization, not just an external advisory.
What's real at this stage: achievable against public smart-contract-wallet ecosystems Hive does not need permission to build against. Wallet-provider SDK cooperation helps but isn't strictly required.
Formal integration with custodial / issuer platforms (starting with Circle Agent Wallets / Programmable Wallets) so a Hive-detected anomaly can trigger an actual freeze / hold inside the issuer's own systems pre-settlement, and structured freeze-request payloads can be delivered into issuer investigation queues post-settlement.
What's real at this stage: requires Circle (or an equivalent issuer / processor) partnership and API access that does not exist today. This is the outreach conversation, not a shipped capability. It's an opportunity, not a live integration.
SmartRecoveryAgent operates with pre-authorized, policy-bounded autonomy to execute counter-transfers, initiate issuer freeze requests, and coordinate multi-step recovery for defined risk and impact tiers, with full audit receipting throughout.
What's real at this stage: requires the most mature trust, security and regulatory posture, dual control, insurance / liability structuring, and almost certainly a licensed-entity conversation. A multi-year destination, not a near-term milestone.
Circle's publicly documented Agent Wallets carry 2-of-2 MPC custody, spending policies, and pre-submission sanctions screening. If Hive were integrated at that layer, its policy engine could sit alongside Circle's checks and withhold authorization before submission.
A payment can be routed through a smart-contract escrow that holds funds for a delayed-settlement window before release. This is the cleanest "reversible by design" case, because reversibility is a property of the contract logic, not a claim about the base chain.
Some regulated / permissioned tokens include an issuer-controlled freeze or blacklist function at the contract level. This is issuer authority, not a Hive capability. Hive's role would be to detect and receipt an incident fast enough to make an issuer freeze request actionable, before funds are moved onward. The tokens sit frozen in the recipient's wallet; they are not automatically returned. Hive never describes this as "Hive can reverse a stablecoin transfer." The accurate claim is: "Hive can detect and receipt the incident fast enough to support an issuer freeze request within the window before the tokens are moved again."
| Capability | Hive-built infra only | Needs third party |
|---|---|---|
| Receipting every intent / action / outcome | Yes | Not applicable |
| Risk scoring and anomaly detection | Yes | Not applicable |
| Pre-signature blocking via Hive-deployed escrow / policy contracts | Yes | Not applicable |
| Duplicate / nonce-based double-payment prevention | Yes | Not applicable |
| Poisoned-address similarity flagging | Yes | Not applicable |
| Session-key / account-abstraction policy integration | Partial (public smart-wallet ecosystems) | Wallet SDK helps |
| Freezing a Circle-custodied wallet mid-flight | Not yet | Requires Circle API / partnership |
| Issuer-side token clawback / blacklist trigger | Not yet | Requires issuer authority + process |
| Bank / ACH recall execution | Not yet | Requires bank / processor API |
| Reversing a finalized public-chain transfer | Not possible | Not possible for anyone, on any rail |
The safest initial architecture is receipt, policy and detection only, no custody, no fund control. Hive advises and triggers actions through the custodian's or issuer's own APIs; it does not hold funds. Any screening Hive adds is described as additional / defense-in-depth, not a replacement for issuer-native sanctions and AML screening. Hive avoids language implying Reg E-equivalent guarantees. That liability structure belongs to the licensed / regulated entity in the flow. A control plane with freeze / counter-transfer power is itself a high-value target, so its own key management, action authorization and dual-control posture must be at least as rigorous as the rails it protects.
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™ stands for Receipt Relay, Recovery, and Routing Proof Vectors. It's the higher-order layer: Receipt Relay signs → Hive Ledger groups receipts into teams & graphs → 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 & runnable curl → Measure receipt latency separately from settlement / rail latency.
Receipted Payment Healing is a receipt-first control discipline, not a universal reversibility guarantee. Hive does not claim that broadcast, finalized transactions on public blockchains can be reversed; where a transfer is final, Hive produces evidence-grade Recovery Receipts to support human, issuer, or regulator-mediated recovery. "Healing" describes a spectrum of outcomes: prevented, quarantined, clawed back, counter-acted, or evidence-only, not a guarantee. Any Circle-specific capability described is a mapping of Circle's publicly documented product surface to where a Hive integration could plug in, conditioned on "if integrated" / "would require"; it is not a claim that Circle has built or endorsed Hive's product, and direct issuer-side integration (roadmap v3) requires a partnership and API access that does not exist today. Clawback-capable freezes are issuer authority, not a Hive capability. Autonomous recovery (roadmap v4) is a multi-year, licensed-entity destination, not a current capability. Nothing here is a promise of FDIC/SIPC-style protection, Reg E chargeback rights, or guaranteed fund recovery. As of 2026-07-05 the live-eligible stage is v0 (receipt-only), running on the Hive Receipt Relay.
Payment Healing tells you what's recoverable on this rail, at this depth. Hive Protected Flow now builds on top of that. It takes an R3Pv proof vector, applies a declared policy pack (default / strict_bank / high_risk_agent) and a 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 behind it, the actions allowed next, and a three-part meter quote (platform fee, R3Pv/Healing premium, and optional basis points on protected exposure). The meter is a quote, not a settlement. No funds move. Policy overrides can only make decisions stricter, never looser. Endpoints: GET /v1/protected-flow/health, POST /v1/protected-flow/assess, GET /v1/protected-flow/evidence/{group_id}/export. The signed assessment round trips through /v1/receipt/verify like any Hive receipt. Runnable Postman collection →