Every agent payment scheme we could find checks the delegation chain downward from whoever signed it. Not one of them checks whether that party held the authority it handed out.
These six receipts cover the whole life of a delegated authority. How it is admitted. Whether the granter actually held it. Whether every hop narrowed. Whether it was still alive when the action ran. Whether it was spent twice across parties who do not talk to each other. And whether it was used at all inside a window you declared quiet. Each one is a signed contract with its own gate engine, its own schema, and its own open verify route.
Read the stage column top to bottom and you have the life of one delegated authority, from the moment an agent is let in to the moment someone asks you to prove it did nothing.
| Stage | The question | The receipt | Type |
|---|---|---|---|
| Admission | Is this agent bound to the terms it joined under? | Admission Binding Receipt | admission.binding |
| Qualification | Did the granter actually hold what it handed out? | Granter Qualification Receipt | authority.qualification |
| Attenuation | Did every hop narrow, or did one of them widen? | Delegation Attenuation Receipt | delegation.attenuation |
| Liveness | Was the authority still alive when the action ran? | Authority Revocation Receipt | authority.revocation |
| Conservation | Was one mandate spent twice across parties who do not talk? | Cross Acceptor Receipt | mandate.crossacceptor |
| Quiescence | Can you prove nothing happened? | Effect Quiescence Receipt | effect.quiescence |
Two of these are the reason the other four exist. Granter Qualification is the step before the token, and Effect Quiescence is the step after it. Both are holes that every scheme we read leaves open. UCAN concedes the first one in its own specification. The second one has no defined answer anywhere: the standards name non inclusion and then define nothing for it.
An agent shows a credential to get in the door. Later it does something you care about. Nothing in most systems ties those two moments together, so an agent can be admitted under one identity and act as another, or act so long after admission that the credential no longer means anything. This receipt binds the admission to the conduct: same subject, conduct at or after admission, and inside a separation bound that was fixed in advance. The credential itself never leaves your side. What gets signed is a commitment to it.
What it does not do. It does not say the credential was a good one, and it does not judge the conduct. It says the actor that acted is the actor that was let in, within the window you set.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
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 in the first place. 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 not the granter or 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.
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.
Authority passed from hand to hand is only safe if it shrinks at every step. In practice the widening happens quietly: a per action ceiling that goes up one hop down, a category that was never in the parent, a depth limit that gets ignored. This receipt walks the whole chain and checks each link against the one above it on ceiling, category set, expiry, and remaining onward depth, then checks the action itself against the last link. If a hop widened, the answer names the hop.
What it does not do. It does not decide whether the root should have had that authority. That is the question the Granter Qualification Receipt answers.
Nothing has run yet. Click Run it and the answer below comes back from the verifier, not from this page.
Pulling an authority is not instant. There is a moment the revocation is issued and a later moment every checker has seen it, and actions land in between. Arguing about that gap after the fact is guesswork. This receipt fixes the action instant, the revocation instant, and the propagation bound you published, then classifies where the action fell: clearly before, inside the propagation window, or clearly after. It also carries clock drift instead of pretending everyone's clock agrees.
What it does not do. It does not stop the action. It settles, afterward and in writing, which side of the pull the action landed on.
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.
An agent with a daily cap can present the same mandate to several acceptors who are competitors and share nothing. Each one sees a spend inside the cap. Together they are well past it. Fixing that by pooling transaction data is a non starter for the acceptors. This receipt aggregates over commitments and pseudonyms instead, so a window can answer whether cumulative spend stayed inside the mandate without any acceptor learning another acceptor's volume, counterparty, or prices.
What it does not do. It does not tell you who spent what. It answers one question about the whole window and keeps the parts private.
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.
Proving something happened is the easy direction. Proving nothing happened, across a declared freeze window, is the one people actually get asked in a deposition or an audit. An empty log proves nothing, because an empty log is what a disabled log looks like too. This receipt commits to the full channel roster up front, then requires every channel in that roster to show continuous heartbeats with no gap wider than the bound, and closing anchors past the settlement lag. Silence only counts when every channel that could have spoken is provably still listening.
What it does not do. It does not cover a channel that was never on the roster. The roster is committed before the window opens, so a channel cannot be quietly dropped to manufacture a quiet window.
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 can adopt any one of them on its own. They compose because they all speak the same envelope: canonicalized with RFC 8785, hashed with SHA-256, signed Ed25519, verified against a published key registry.
Admission binds the agent to the terms it joined under. Qualification checks the root actually held the authority. Attenuation checks nothing widened on the way down.
Liveness settles which side of a revocation the action fell on. Conservation answers whether one mandate was spent across acceptors who share nothing.
Quiescence answers the hardest one. Not what happened, but that nothing did, across every channel that could have spoken.
Every contract in Hive Proof Architecture →
The Authority Line. Patent pending. Six typed receipt contracts: Admission Binding, Granter Qualification, Delegation Attenuation, Authority Revocation, Cross Acceptor, and Effect Quiescence. The runs on this page post published example bodies to the open verify routes and print what comes back. Example receipts are signed with did:hive:example: keys and verify reports key_trust example_registry, so nothing on this page is a production issuance, a customer record, or an endorsement. Hive Civilization Inc.