Fireblocks put it plainly on your own blog: “Every decision an agent makes is either a compliance event or evidence in a dispute, and the wallet is where that trail either lives or dies.” That sentence is the entire reason this page exists, and it is right.
A compliance event and evidence in a dispute are not the same artifact. A compliance event answers to you. Evidence answers to the other side. The wallet holds the trail, the policy engine made the call, and both belong to Fireblocks, so the counterparty’s counsel gets to ask why they should credit either one. That is not a criticism of the trail. It is a structural fact about who produced it.
You already ship the hard part. The agent has its own wallet, the spend is governed by permissions on amount, counterparty, purpose and time, and in your words “anything outside the rules is refused outright, not held for review.” None of that needs replacing. What is missing is a second artifact, signed under gates neither side controls, that lets somebody outside Fireblocks confirm the controls held without being handed your log and asked to believe it.
Nine of these are deployed in production and eight of them run on this page. Not screenshots. Your browser posts to the open verify route and shows you what came back.
This is not a pitch to replace the policy engine, and it is not a claim that Hive does governance better than the platform securing more than $14 trillion in digital asset transactions. Every gate on this page assumes your controls work exactly as documented.
The gap is narrower than that, and harder. Enforcement and provability are different problems. A policy engine that refuses a bad transaction has protected the customer. It has not, by itself, produced something a regulator, an insurer, an auditor or an opposing party can check without trusting the platform that refused it. Those two jobs happen to look identical right up until the moment somebody disputes the outcome.
Keith Lawhorn, Chief Information Security Officer at the Wyoming Stable Token Commission, set the bar in your own announcement: “Agent-initiated payments raise the bar on every part of that: who authorized a transaction, what the limits are, whether it can be explained to an auditor.” Explained to an auditor is the operative phrase. An explanation the auditor has to accept on faith is a weaker instrument than one they can recompute.
So the proposal is small. Hive sits beside the policy engine and emits a signed receipt per decision, under gates that are open and deterministic. You keep the enforcement. The receipt makes the enforcement checkable by someone who was not in the room.
Ofrat said the protocols answered how agents pay, and that Fireblocks built the layer making sure they do it with the right controls in place. These are the four questions that arrive after the controls have already done their job.
Somebody has to show the business behind the agent actually held the authority it handed over, and that the grant it wrote was inside what it held.
authority.qualification returns a class derived from a committed entitlement source, checked by a qualifier the gates require to be a different party from the granter.
The grant stops being a claim and starts being a finding.
Your blog sets the rules at setup: a session cap, a booking cap, a counterparty category. After an incident, the contested question is whether those were the rules at the time, or the rules as remembered.
mandate.conformance binds the mandate under a salt committed before the payment, so widening it afterwards to cover a bad transaction fails a gate instead of passing quietly.
The limits cannot be edited into the past.
Keith Lawhorn at the Wyoming Stable Token Commission put the bar in one line: who authorized a transaction, what the limits are, whether it can be explained to an auditor.
authorization.decision recomputes the verdict from committed inputs and requires the stated reason to match the gate that fired, so the explanation is derived rather than narrated.
An auditor can check it without taking your word for the log.
This is where a compliance trail and evidence part company. The trail was produced by the platform whose policy engine made the call, so the other side's counsel gets to ask why they should credit it.
fault.attribution derives single, shared or hindsight from the committed artifacts, and the hindsight finding protects the party who broke nothing even though the outcome was bad.
The trail stops being yours and starts being checkable.
You let a business provision a wallet and hand an agent the right to spend from it. Before any downstream check is worth running, one thing has to be true: the business that granted that authority actually held it. A policy engine faithfully enforcing a grant nobody was entitled to make still moves the money.
Three artifacts go in. The grant, an entitlement source the granting party claims to hold, and a qualification record. SCOPE_CONTAINMENT and QUANTITY_CONTAINMENT check the grant fits inside the entitlement. ENTITLEMENT_INTERVAL_ORDER checks the timing. QUALIFICATION_RECOMPUTE derives the class instead of reading it, and QUALIFICATION_PRECEDENCE requires the qualification record to have been committed in the right order, so nobody writes the paperwork after the loss.
Run the unqualified case. It comes back valid true with a class of unqualified, because the granter granted more than its own entitlement source supported. A valid true receipt that says the grant was bad is the more useful of the two outcomes, and it is exactly the one you cannot get from a party with a stake in the grant standing up.
QUALIFIER_DISJOINT carries the independence claim. The qualifier cannot be the granting party. That is enforced in the verifier, not promised in a deck.
What it does not prove, in plain words. It does not say the entitlement source is genuine, accurate, current, or lawfully obtained, and it does not say the qualifier is competent or free of conflict in fact. A class of qualified does not make the grant valid, enforceable or binding.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Your own words: an agent needs “a set of constraints the business issuing the agent actually trusts.” The moment that agent hands part of the job to a second agent, the constraint has to survive the handoff. Delegation is only safe if it narrows. This receipt proves the child scope sits strictly inside the parent, every hop down the chain.
ATTENUATION_CATEGORY_SUBSET requires each child scope to be a subset of the one above it. ATTENUATION_CEILING_NONINCREASING does the same for amounts, so a child can never carry a larger cap than its parent. ATTENUATION_EXPIRY_NONEXTENDING and ISSUANCE_WITHIN_PARENT_TERM keep the child window inside the parent window, which is the hop where session limits usually leak.
CHAIN_CONTINUITY and LINK_ORDINAL_DENSE walk the whole chain in order and refuse a gap. ATTENUATION_DEPTH_STRICT_DECREASING stops a chain from looping back on itself to widen scope, which closes the gap where a later grant is presented as if it had existed earlier.
The output is one receipt for the chain, not a pile of separate approvals a reviewer has to reconcile by hand after something goes wrong.
What it does not prove, in plain words. It does not say any party in the chain was honest, solvent, or authorized in the world outside the committed artifacts. It attests to the containment and ordering relationships between the named delegations.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
This is the receipt that matches the example on your own blog: “up to $25 for research and data costs this session, up to $1,200 for the booking, and only travel-category counterparties.” Your policy engine enforces that. This produces the artifact that lets somebody who is not Fireblocks confirm it held.
AMOUNT_WITHIN, CURRENCY_MATCH and SCOPE_MATCH check the transaction against the mandate the user set at setup. VALIDITY_WINDOW checks it happened inside the live window rather than after the session should have closed.
MANDATE_PRECEDES_TRANSACTION and MANDATE_INTEGRITY are the two that matter for a dispute. The mandate has to have been committed before the payment, and it has to hash to what it hashed to then. That is what stops a mandate from being widened after the fact to cover a payment that broke it.
Run the fail case and read the gate list. You get a signed statement of which specific constraint the payment broke. Not a log line saying it was refused, a receipt naming the gate.
What it does not prove, in plain words. It does not say the mandate reflected what the user actually wanted, that the user understood it, or that the counterparty performed. It attests that the named payment satisfies the named mandate under the stated gates.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Your policy engine evaluates every transaction before signing and, in your words, anything outside the rules “is refused outright, not held for review.” That decision is the single most contested fact after an incident. This turns the verdict itself into an independent artifact, so the decision does not rest on the log of the party that made it.
DECISION_BASIS_RECOMPUTE and DECISION_RELATION_RECOMPUTE re-derive the verdict from the committed inputs instead of trusting the recorded outcome. If the stored decision and the recomputed decision disagree, the receipt says so.
DECISION_INSTANT_ORDERED and SALT_BINDING require the inputs to have been fixed before the decision, which closes the retrofit gap. CONSTRAINT_EVALUATION_RECOMPUTE re-runs the constraint check itself, so a decline cannot be relabelled later with a more comfortable reason.
Three cases run here: approved, declined, and revoked. The revoked case is the one that gets litigated, because it turns on whether the revocation had landed at the moment of the decision.
What it does not prove, in plain words. It does not say the policy was correct, fair, lawful, or well designed. It attests that the named decision follows deterministically from the named inputs under the stated gates.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Every agent wallet needs a stop. The hard part is never the button, it is proving afterwards which side of the stop a given payment fell on. Machine speed makes that window small enough to argue about, and an argument about ordering is an argument nobody can settle from two separate logs.
PRECOMMITMENT_ORDER establishes the revocation in the commitment chain. ACTION_AUTHORITY_MATCH ties the effect to the authority being revoked, and CLASSIFICATION_RECOMPUTE derives which side it fell on. Together they produce an ordering that does not depend on two systems agreeing on the time.
CLOCK_CONSERVATISM refuses to resolve an ordering the evidence cannot actually support. When the window is genuinely too tight to call, you get an honest unresolved rather than a confident guess that falls apart under scrutiny.
Run before and after back to back. Same shape, opposite finding, and neither one depends on Fireblocks or the counterparty being believed.
What it does not prove, in plain words. It does not say the revocation was justified or properly authorized, and it does not say the effect was harmful. It attests to the order of the named revocation and the named effect.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
You wrote that nothing happens off the record. Proving something did happen is the easy direction. Proving nothing did, across a bounded window, is the direction every auditor asks for and almost nobody can produce. An empty log is not evidence of quiet, it is evidence of a log.
SALT_PRECOMMITMENT and INTERVAL_ORDER fix the interval in advance so it cannot be trimmed to exclude an inconvenient event. ROSTER_COMMITMENT_RECOMPUTE and CHANNEL_SET_COMPLETE name what was supposed to stay absent and across which channels, which turns a vague claim of quiet into a specific one.
COVERAGE_RECOMPUTE and GAP_BOUND are the gates that make this worth anything. They require the observation to actually cover the whole window. A gap in coverage returns a gap, not a clean bill of health.
The effect case is the honest half. Something did land, and the receipt names it. A quiescence primitive that could only ever return quiet would be worthless.
What it does not prove, in plain words. It does not say the window was the right window to look at, or that the prohibited classes were the right ones to name. It attests to absence of the named classes across the named interval, to the extent of the stated coverage.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Fireblocks wrote that every decision an agent makes is either a compliance event or evidence in a dispute. Evidence in a dispute has a property a compliance event does not: it has to hold up when read by somebody who does not trust the party that produced it. That is the whole gap this closes.
Fault lands in one of three shapes. Single, where one party's breach explains the outcome. Shared, where more than one contributed and the receipt refuses to pick a favourite. Hindsight, where the outcome was bad but no committed constraint was actually broken, which is the finding that protects a party who did everything right.
ATTRIBUTION_CLASS_RECOMPUTE and ATTRIBUTED_ROLE_RECOMPUTE derive the shape and the party from the artifacts rather than reading a conclusion somebody typed. PRECOMMITMENT_PRECEDENCE and VIOLATION_SUBSET_INTEGRITY stop a loss from being retrofitted into somebody's breach because a loss occurred.
The hindsight case is the one worth running. A signed finding that nobody breached anything is often the most valuable receipt in the whole set, and it is the single hardest thing to produce from your own audit trail.
What it does not prove, in plain words. It does not assign legal liability, damages, or negligence, and it is not a legal determination of any kind. It attests to which committed constraints were broken by which named party under the stated procedure.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
You settle across 100+ countries and reconcile inside one platform, producing settlement data you say can be explained to auditors from day one. Explaining it is one job. Proving the internal view and the chain view still agree, at a named moment, without the auditor taking your reconciliation on faith, is a different one.
COMMITMENT_EQUALITY_RECOMPUTE derives the comparison from committed positions rather than trusting two summaries. TIME_ANCHOR_DRIFT_BOUND and OBSERVATION_WINDOW_TOLERANCE fix the moment of comparison in advance so the check cannot drift to a flattering timestamp.
DIVERGENCE_CONSISTENCY and MAGNITUDE_CLASS_ENUM require a mismatch to be reported with its size class. The diverge case returns valid true with a named gap, which is the outcome an auditor actually wants and the one an internal dashboard is least likely to volunteer.
ATTESTOR_KEY_DISTINCTNESS and ATTESTOR_QUORUM carry the independence claim here. The attestors signing the comparison have to be distinct keys meeting a quorum, so a parity claim cannot be produced by one party alone.
What it does not prove, in plain words. It does not say the internal ledger is complete, that the chain view is the right chain, or that either party is solvent. It attests to agreement or divergence between the named views at the named moment.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Every receipt above is deployed, open to verify, and honest about what it does not prove. If the argument holds, the next step is one integration against a route you can already call from a terminal.
Verify a receiptRead the canon
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.