Live now. No account, no login, no call

Two things you can check yourself

Pick an attack on a wire transfer and watch execution refuse. The digests are computed in your own browser. Then take the record it hands you and check the second signature against a published key, again in your own browser.

Break a $40,000 wire Check a countersignature

What the demo does not do. It proves the instruction did not change in custody. It does not prove the answer was right or that any model was honest. The second signer is a separate key, a separate clock and a separate log operated by Hive, so it is not an outside party and the service reports that itself. It signs Ed25519, which is not post quantum. The operator side signs ML-DSA-65 under NIST FIPS 204. The second signer's log does not survive a redeploy today, and it says so too. Patent pending.

Private outbound brief · noindex · Hive is not a Circle customer or partner
Hive Civilization checkmark logo Hive Hive Proof Architecture
proposed technical fit · one integration surface · nothing in Circle's path changes

On July 27, Circle bought
nearly a thousand patents
about verifiable infrastructure.

Then it shipped a stack that makes agents economically capable. Hive adds a receipt another party can verify without asking the operator to restate what happened.

Circle is building the regulated money, the wallet, the marketplace, the policy layer, the chain, and the settlement path for agents. That is the hard part, and it is Circle's. Hive is an additive, removable proof sidecar that binds independently verifiable evidence beside those actions, without changing Circle's route, price, policy, or settlement logic.

680+patent families acquired from the IBM blockchain portfolio, with nearly 1,000 issued patents worldwide
OCC approvedCircle National Trust, a federally supervised national trust bank, final approval July 10, 2026
25+ chainsreached by CPN Managed Payments, with Gateway presenting one balance across 12
the proposed commercial shape

Circle owns the customer-facing proof product.
Hive signs underneath it.

Stated up front because it determines whether anything else on this page is worth reading. This is a proposed structure, not a current commercial arrangement.

Circle keeps

The customer, the product, the price

The customer-facing proof product, the packaging, the pricing, and the relationship. The wallet policy stays enforced at Circle's wallet layer. Routing, orchestration, attestation and settlement stay authoritative and unchanged. Nothing moves out of Circle's control.

Hive provides

The independent signature

The signer and verifier underneath, so the artifact a counterparty checks has cryptographic separation from the operating record it references. That independent signature adds portability without replacing Circle's native evidence.

the load bearing claim · test it here

Beside the path.
Never in it.

Circle's payment path runs across the top. Hive receipts bind underneath as each step passes. Switch Hive off and watch what happens to the path.

0actions completed on Circle's path
0receipts bound beside them
0receipts visibly absent
Hive online
Every step carries a signed receipt bound beside it. Emission is out of band, so the payment never waits on the evidence.

Take Hive out and Circle's behavior is identical to today. There is no shim to unwind, no policy to restore, and no settlement dependency to migrate, because Hive never held any of them. A receipt already issued still checks from the artifact itself, offline, against published key material, with no call to Hive.

what changed since June · stated from Circle's own published material

Both sides moved.
This brief is written against what Circle shipped.

Agent StackChain and protocol agnostic open infrastructure for the agentic economy: Agent Wallets, Agent Marketplace, Circle CLI, Nanopayments powered by Gateway, and Circle Skills.
Human defined policyAgents hold and move USDC under human defined policies, with time bound spending limits, allowlists and blocklists, enforced at the wallet layer.
x402 per callAn API takes USDC payment per call with no checkout and no account setup, and agents discover the service through Agent Marketplace.
CCTP V2Native USDC through a 1:1 burn and mint. Circle observes and attests the source burn, then the application mints on the destination chain. Hooks trigger follow-on actions.
GatewayOne USDC balance across 12 supported chains, accessible on a destination chain in under 500 milliseconds once established.
CPN Managed PaymentsWallets, custody, minting, redemption, interoperability and orchestration across more than 25 blockchains, with real-time notification and reconciliation.
Patent portfolioThe IBM blockchain portfolio acquired July 27, 2026. Over 680 families, nearly 1,000 issued patents worldwide.
Circle National TrustFinal OCC approval July 10, 2026 for a federally supervised national trust bank offering fiduciary digital asset custody.

Hive makes no claim about Circle's internal systems beyond what Circle publishes. Every item above is linked at source in the footer.

three proposed surfaces · each one optional · the proof of concept asks for exactly one

Three places evidence could sit.
None requires the others.

surface A in sequence · one route, one signed trail

Five steps. One artifact at the end.

1
Before the request. Stipryn™ fixes the required proof level before transmission, while the party bearing the consequence still controls the request. The requirement attaches to anchored regions of the request. Stipryn does not inspect, rewrite, or otherwise change what is being asked.
2
Authority. The human or institution defined wallet policy is already enforced at Circle's wallet layer. The receipt records the declared authority reference and the proof level demanded against it. Hive does not evaluate, replace, or relax that policy, and a Hive record is never a precondition for the policy to work.
3
The action. The priced call runs on Circle's path. Where a model or service produced the work, which model or service served the step can be bound in. Where the response is streamed, the run can be committed before the first content leaves, so the record cannot be backfilled to match a later result.
4
The payment event. After Circle settles, a signed event receipt records the reference, the amount as declared, and the parties as declared, with the evidence tier stated plainly. Emission is out of band. If it fails, the payment has already happened and is unaffected.
5
The export. The grouped receipts become one signed package a counterparty can check offline. What was demanded, what was authorized, what served the call, and what was paid, in one artifact, with the weakest verified boundary stated rather than hidden.
Circle Gateway and ERC-1271 · noted August 4, 2026

Gateway now speaks ERC-1271.
Hive signs a receipt beside it.

Circle Gateway supports ERC-1271, so a smart contract, a smart wallet, or an application can reach a unified USDC balance while its own existing authorization logic keeps making the decision, with no delegate accounts and with expanded crosschain access. That is a clean fit for evidence: the authorization already happens in one place, and the flow already produces the exact references a receipt needs. Hive adds an independently checkable receipt beside the existing flow and changes nothing about it.

Circle and the contract stay authoritative

The contract’s ERC-1271 validation result and Circle’s Gateway attestation remain the native evidence for what was authorized and what settled. Hive preserves those references as supplied and never restates them as its own claim.

Where Hive sits

Beside the flow, Hive can operate a separate countersigner and log whose evidence is independently checkable; true institutional independence requires non-Hive custody. Hive does not evaluate, gate, replace, or change any authorization policy, does not sign for any wallet, does not hold or move funds, and is never in the authorization path. Emission is out of band, so the transfer never waits on a receipt.

No secret crosses the boundary

Private keys, seeds, session material, raw call data, and raw request bodies are never sent, held, or stored. Addresses, chain identifiers, public references, and caller computed digests are the only inputs.

No new primitive was invented for this

Source analysis of the existing contracts found no unfilled proof boundary here, so the mapping reuses primitives that already exist and already verify. A new type would duplicate boundaries rather than fill a gap.

Bound fieldWhat the receipt recordsExisting Hive primitive
chain_idThe chain identifier the authorization is scoped to and the chain the balance is requested on.HiveBound Envelope (typed facade)Delegated authority chain
gateway_or_smart_wallet_addressThe Gateway wallet contract or smart wallet address acting as the subject of the authorization.Delegated authority chainHiveBound Envelope (typed facade)
erc1271_validation_contractThe address of the contract whose isValidSignature result the flow relies on.Delegated authority chainImprimatur (pre-attestation clearance primitive)
authorization_policy_version_or_digestThe version string or canonical digest of the authorization logic in force, as the application declares it. Hive records the declared value and never interprets or alters the policy.Imprimatur (pre-attestation clearance primitive)Delegated authority chain
signed_intent_digestThe digest of the intent that was signed, fixed before transmission. The digest travels, the intent body does not.Stipryn (pre-submission proof-level binding)HiveBound Envelope (typed facade)
requested_chain_and_materialized_chainThe chain requested and the chain the balance actually materialized on, carried as separate declared and observed values so any difference stays visible.Multi Source Divergence Detection (MSDD)Proof state transition container
circle_gateway_attestation_referenceCircle's own Gateway attestation reference or its digest, preserved as an admitted input rather than restated as a Hive claim.Proof state transition containerEffect closure receipt
amount_and_assetThe USDC amount and asset identifier as declared and as observed.Effect closure receiptHive Settlement Feed
policy_decisionThe allow or deny the application's own authorization logic returned, recorded as an outcome of that logic.Imprimatur (pre-attestation clearance primitive)Delegated authority chain
execution_transactionThe execution transaction reference on the materialized chain.Effect closure receiptProof state transition container
effect_closureCompletion status and idempotency key bound to the observed outcome and its evidence digests.Effect closure receiptReceipt Reduction and Recovery Proof Vector (R3Pv)
settlement_reference_valuesWhere a settlement value is what the flow is measured against, that value can be independently signed rather than taken on trust. Supported where a feed exists.Hive Settlement FeedMulti Source Divergence Detection (MSDD)
portable_exportA fixed size export of the whole lifecycle for a counterparty, auditor or insurer to check offline.Portable transition proofProtected Flow
weakest_verified_boundaryThe weakest verified boundary across the receipt group for one flow, stated rather than implied. Available through the external Protected Flow and R3Pv service where that service is in use.Receipt Reduction and Recovery Proof Vector (R3Pv)Protected Flow
Open the full mapping in the canon explorer Search canon for Circle Gateway
Sources · Circle Gateway · Circle Gateway developer documentation, for the unified USDC balance, the non custodial Gateway Wallet contracts, and sub second mint on a destination chain · ERC-1271, the signature validation standard · Gateway now supports ERC-1271 for Programmable Authorization, Circle's own announcement of August 4, 2026, which is the public citation for the ERC-1271 support described above.
control map · already public Hive instruments only

What each instrument fixes,
and its exact maturity today.

Maturity labels are taken from the Hive Proof Architecture pages themselves. Nothing is labeled live unless a Hive production endpoint answers today. Instruments filed as art and not yet exposed as an endpoint say so.

Adjacent instruments that could apply to a later surface, listed for completeness rather than proposed here: HiveSeal · QPuF hardware root of trust · AFiR · fragment level inference receipts · Imprimatur · pre attestation gate · SmartAgent Route Graph · route proof · Hive Settlement Feed · signed settlement values · The complete Hive Proof Architecture
architecture · a design proposal, not a live integration

Circle remains authoritative for the money event.
Hive makes selected surrounding events portable and checkable.

Pick a Circle boundary. The architecture keeps each system in its proper role.

Circle remains authoritative for

Hive can bind beside it

Portable result

Sidecar placementHive sits beside the action, not between Circle and its customer. It is invoked out of band, and its output is an artifact rather than a decision imposed on the flow.
Hash first where supportedThe binding is over a one way SHA-256 fingerprint and content addressed roots, not the underlying text. Change one byte and the address changes, which breaks the signature.
No prompt or completion storageThe request is receipted by fingerprint. Proof, not surveillance, is the standing rule across Hive surfaces.
No custody, no route selectionHive holds no keys to anyone's funds, never takes possession of value, and never picks a chain, a corridor, or a counterparty. Routing and settlement stay entirely with Circle and the network.
No policy substitutionCircle's human defined wallet policy remains the enforcement point. Hive records a reference to the declared authority and the proof level demanded. It never becomes the gate.
Fail open and removableIf a Hive component is slow, unavailable, or deleted, the action still runs. A missing receipt stays visibly missing rather than being backfilled or faked.
scope boundaries · precise limits on Hive, not criticisms of anything Circle built

What Hive is,
and the lines it does not cross.

Not a customer, not a partnerHive is not a Circle customer or partner. This page is a proposed technical fit written by Hive. It is not a joint document, and there is no co branding, no attribution promise, and no revenue arrangement described anywhere on it.
No live Circle integrationNo direct Circle integration is represented as live. Hive services described as live are Hive's own endpoints. Nothing on this page calls a Circle API, and no Circle interface is assumed to exist beyond what Circle publishes.
Hive does not touch the moneyHive does not move funds, does not custody assets, does not set or substitute wallet policy, does not select a route, and does not reverse a finalized transaction. Those belong to Circle, to the human who set the policy, and to the network.
Evidence, not judgmentA Hive receipt records what was demanded, declared, observed, and committed. It is not a compliance determination, not a regulatory approval, not a fiduciary opinion, and not a correctness or safety claim about a model or a payment.
Beside the path, not in itEvidence is bound beside the action. Receipt emission is out of band from the payment path, so a slow or unavailable Hive component does not gate a transfer, a quote, or a settlement.
Circle's marks stay Circle'sThis page uses the word Circle as a plain reference only. There is no Circle logo, no lockup, and no imitation of Circle trade dress. Product and company names belong to their respective owners.
Scope note on durability. Hive states that a previously issued receipt remains independently verifiable offline using published verifier behavior and published key material. Hive does not claim indefinite verifiability, and does not claim that any future verifier release will preserve a given format without change.
the ask

PICK ONE SURFACE.
HIVE RUNS THE POC.

A suitable scope is one Agent Stack or x402 route for 30 days, with evidence bound beside the action. Circle's route, price, policy, and settlement logic stay exactly as they are.

The integration scope is limited to the proof fields and the signing path Circle chooses to expose, and Hive removes itself on request at any point.

one surface · A, B, or C additive · nothing in the serving or settlement path changes fail open · removable on request
Non customer notice. Hive is not a Circle customer or partner. This is a private outbound technical brief prepared by Hive Civilization Inc. and it describes a proposed technical fit only. No direct Circle integration is live. Hive does not move funds, custody assets, set wallet policy, select a route, or reverse finalized transactions. Nothing on this page is a partnership, endorsement, deployment, agreement, certification, or regulatory or compliance outcome.
Sources, checked August 5, 2026 UTC · Agent Stack · agent ready API revenue · CCTP V2 · Circle Gateway · CPN Managed Payments · patent portfolio acquisition, July 27, 2026 · OCC final approval for Circle National Trust, July 10, 2026
Hive is not a Circle customer or partner. Private outbound brief · noindex, nofollow, noarchive · not affiliated with, endorsed by, or produced in cooperation with Circle Internet Group, and product and company names referred to here belong to their respective owners · this page describes a proposed technical fit and no direct Circle integration is live · Hive does not move funds, custody assets, set wallet policy, select a route, or reverse finalized transactions · Hive produces evidence, never a compliance determination or a regulatory approval · Stipryn™, Foretoken™, and R3Pv™ are Hive marks and Hive primitives are patent pending · maturity labels on this page are governed by the Hive typed receipt production manifest (hive-verifier-api/PRODUCTION_MANIFEST.json), regenerated from the live production health check and this repository's own tests, smoke coverage, and benchmark artifacts rather than asserted from memory · a code complete label means the schema, signer, mint route, open verifier, tests, adversarial smoke coverage, and benchmark coverage exist in the codebase and nothing more; it is not a claim that the endpoint is deployed, reachable, or independently verifiable in production, and it is never presented as live or partly live · an automated check (hive-verifier-api/test/circle-page-manifest.test.mjs, sharing its logic with the standalone hive-verifier-api/scripts/check-circle-page-manifest.mjs command) runs against this page's rows on every npm test pass, offline, against the manifest already committed to the repository, in both directions: it fails the test suite by name if a live or partly-live row claims a status the manifest does not currently support (overclaim), and it separately fails by name if a row's mapped type is already production_ready_for_canon:true in the manifest but the row still reads built, filed, or only partly live (underclaim), so this page's status claims cannot silently drift out of sync with production_ready_for_canon in either direction · as of the manifest checked into this repository on August 4, 2026, all 13 canonical typed receipt types (EvAR, both legs of Bonded Performance Attestation, Stipryn™, Foretoken™, Multi Source Divergence Detection, the proof state transition container and its portable export, the multi-provider assembly receipt, the proof-driven routing receipt, the delegated authority chain, the correction and supersession receipt, and the effect closure receipt) have a confirmed production deployment, alongside Receipt Relay and Hive Receipt, R3Pv, Protected Flow Fleets, SiGR, and the Hive Typed Signer · for Foretoken™ specifically, the evidence-bearing chain fold has its own dedicated, open, unauthenticated production endpoint at POST /verify/stream-attestation/chain, distinct from and additional to the base verify route, which remains unchanged and honestly reports chain_fold_independently_verified:false when no caller-held unit evidence is supplied · prepared by Steve Rotzin, Founder, Hive Civilization Inc. · Wyoming, USA
new in the canon · runnable on this page

Carry settlement authority into a checkable record

These receipts add a direct comparison of two settlement records and a check that one transaction fit its delegated mandate beside the settlement, authority, and delegation work already described here. They answer in production right now, and the runs below prove it end to end. Three more from The Authority Line sit directly on that work: whether the granter held what it granted, whether every hop narrowed, and whether one mandate was spent twice across acceptors with no shared ledger.

ledger.parity

Compare two settlement records without exposing their contents

This receipt lets settlement and operations teams compare two named records at specific cursors and times. It fixes the field list, uses separate registered attestor keys, and commits a fingerprint for each record. The service recomputes whether the records match within the declared timing window. A divergence remains explicit when a source and destination view need investigation. Legal, risk, and counterparties can inspect the result without seeing balances, holders, or account identifiers.

What it does not do. It does not reveal positions, balances, holder identities, or account identifiers, and it cannot confirm that either fingerprint accurately represents the record named because it grants no access to that record. It does not choose the correct record, assign fault, determine whether the settlement, transfer, or register update was proper, or carry out or reverse settlement, and a late window says only that the observations were too far apart to decide.

Open the Ledger Parity Receipt pageCanon entrySchema
POST /verify/ledger-parity · case pass, a clean record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/ledger-parity · case diverge, the two records disagree

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/ledger-parity · case fail, a forged record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

mandate.conformance

Check one settlement action against its delegated mandate

This receipt compares one named transaction with a delegated authority receipt signed before that transaction was authorized. It checks the declared amount, currency, timing, and scope against that mandate's constraints. The service recomputes the outcome from the comparison rather than relying on a caller supplied result. That gives an Arc or stablecoin settlement reviewer a narrow, checkable statement about this action and the supplied delegation. It can accompany the authority record without changing the system that decides or settles the transaction.

What it does not do. It does not prove that a cardholder granted the delegation, that the agent identity is genuine, that a network authorized or settled the transaction, that goods or services were delivered, or that a person read the displayed terms. It is not payment authorization, holds no cardholder credential, has no recognition as authentication data, compelling evidence, or liability shift from a network, issuer, or regulator, cannot resolve or affect a dispute or consumer rights, cannot assess aggregate spend or velocity, and cannot show that the supplied mandate remained unrevoked when the transaction was authorized.

Open the Mandate Conformance Receipt pageCanon entrySchema
POST /verify/mandate-conformance · case pass, a clean record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/mandate-conformance · case fail, a forged record

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

authority.qualification

Show the granter actually held what it handed out

Every delegation scheme we could find checks the chain downward. Each link is signed, each link narrows, the math works. None of them check the very first step: whether the party at the root held the authority it delegated. UCAN says so in its own spec, that a cryptographically valid chain can still be semantically invalid and the executor has to go look. This receipt is that look, made into evidence. It reads an entitlement source and a grant instrument, verifies the grant instrument's own signature, and answers whether the grant sits inside the entitlement on scope, on amount, and on time. A third party who is neither the granter nor the grantee has to sign the check.

What it does not do. It does not judge whether the entitlement source is telling the truth. It proves the grant did not exceed what that source said the granter had.

Open the Granter Qualification Receipt pageCanon entrySchema
POST /verify/authority-qualification · case qualified, the granter held what it granted

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/authority-qualification · case unqualified, the granter granted more than it held

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

delegation.attenuation

Show every hop narrowed and none of them widened

Authority is supposed to shrink as it passes down a chain. In practice a hop can quietly add a scope, raise a cap, or push an expiry out, and the chain still verifies because every signature is good. This receipt compares each hop against the one above it on scope, amount, and time, and reports whether the chain only ever narrowed. It reads the whole chain, not just the last link.

What it does not do. It does not decide whether the top of the chain should have had that authority. That is the qualification receipt. This one only answers whether anything widened on the way down.

Open the Delegation Attenuation Receipt pageCanon entrySchema
POST /verify/delegation-attenuation · case conforms, every hop only narrowed

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

mandate.crossacceptor

Show one mandate was not spent twice across parties who do not talk

A single delegated mandate can be presented to two acceptors who have no shared ledger and no reason to trust each other's books. Each one sees a valid mandate and each one is right about its own slice. This receipt fixes each acceptor's consumption as a commitment, then reports the cumulative relation of all of them against the mandate constraint, so the total is checkable without either acceptor handing the other its transaction history.

What it does not do. It does not reconcile the two ledgers, reverse anything, or say which acceptor should have declined. It says whether the sum of what was consumed stayed inside the constraint or went past it.

Open the Cross Acceptor Receipt pageCanon entrySchema
POST /verify/cross-acceptor · case within, spend stayed inside the mandate

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

POST /verify/cross-acceptor · case breached, spend went past the mandate

Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.

Every run above posts a verified request body from this domain to the open verify route and prints what came back. The example receipts are signed with published example keys, so verify reports key_trust example_registry. That is on purpose. Nothing on this page is a production issuance, a customer record, or an endorsement. Patent Pending.

Canon cross reference

The exact canon entries behind this page

Each link opens that entry in the canon implementation explorer, where its schema, mint route, open verify route, auth requirement and implementation state are stated. The state shown here is read from the same registry file the explorer renders from, so the two cannot drift apart. Nothing here implies a customer, a deployment or an endorsement.

Search the explorer for Circle proof surface