A signed receipt is a precise, narrow statement. This is a careful account of the three things a valid Trustvice receipt establishes, the many things it does not, what you are still trusting us for, and how to present receipts so nobody overstates them.
By The Trustvice team5 min read
Agents, evidence, governance, commerce and disclosure are all in Trustvice 360. Sign up free and open every suite from one dashboard.
© 2026 Trustvice. All rights reserved. Trustvice is a product by Trustvice. Secured and supercharged by Avonao Labs.
Report abuseCryptographic evidence invites overstatement. "Signed" sounds like "true", and "tamper-evident" sounds like "certified". Neither is right. If you use Trustvice receipts in an audit, a contract or a dispute, the most valuable thing you can do is describe them exactly: no more than they show, and no less.
This post is that description. It is the page we would want a careful lawyer, auditor or counterparty to read before they rely on a receipt, and it repeats things our documentation already says on purpose.
A receipt that verifies against a published Trustvice key proves three things.
Origin. The envelope was signed by the holder of the private key matching signatureKeyId, which is a Trustvice signing key. Nobody else, including you, can produce a receipt that verifies against that key.
Integrity. Every member of the envelope except signature is exactly as signed: the type, the body, the issuedAt time and the key id. Changing a single character makes verification fail.
A signed time. Trustvice asserts the receipt was created at issuedAt. That is the issuer's own clock.
Anyone can check all three, offline, without an account and without asking us. The check is deterministic: two independent implementations given the same receipt and the same key reach the same answer. That is the strength of a receipt, and it is real.
Before listing the limits, one distinction decides how much any particular receipt means.
A receipt can state facts that someone supplied to Trustvice, signed to show they were presented, or facts about something Trustvice performed or saw itself. A receipt over reported facts proves they were presented by issuedAt; a receipt over observed facts proves what Trustvice saw. The receipts look the same in both cases, so read the receipt type to know which one you hold.
These are not defects. They are the boundary of the claim.
A receipt over a hash covers a hash. The hash of a false document verifies exactly like the hash of a true one. A receipt over a reported exchange, such as a prompt and a response, proves that the exchange was presented at a time, not that it happened as described.
What a reported-fact receipt does give you is still worth having: it fixes the claim in time, so it cannot be quietly back-dated, and any later change to it is detectable.
The envelope carries no workspace or account identifier, and no person's signature. Anyone holding the JSON can present it. A hash identifies bytes, not an owner: it does not show that nobody else holds the same content. If authorship matters, put your own signatures inside the content.
The receipt holds a hash. To show a document matches, hash the document and compare it with the body. The receipt only helps if you kept the content somewhere you can produce it.
issuedAt is our clock at signing. For a reported fact, the event happened some time before the receipt. A receipt is not a qualified timestamp under any legal regime. Do not claim precision finer than the interval between the event and the receipt. If you need an external anchor, publish the receipt's signature somewhere that has its own trusted clock.
A receipt proves what it says, not what was left unsaid. A gap in receipts is not proof that nothing happened, in your favour or against it.
There is no revocation. A receipt that verified when issued verifies for as long as its signing key stays published. There is also no key revocation list. A leaked signing key would let its holder create receipts that verify, and the signature check alone could not tell them apart from genuine ones.
Verification removes the need to trust us for a lot: you do not need us to tell you whether a receipt was altered, which key signed it, or whether the key inside it was swapped. What remains is a small, named set:
Trustvice 360x value from a network you trust, and verify against that copy.For the strongest position in a dispute, combine receipts with records you control.
When a receipt leaves your hands, a short covering note prevents most misunderstandings. A good note does five things:
4d9a…7d62 to Trustvice under the label proof v3 delivered."trustvice.com themselves, so they are not relying on a key file you supplied.Our guide Evidence for disputes shows the whole pattern: deciding before a dispute which claims you will need, capturing receipts at the moment things happen, and assembling an evidence pack that the other side can verify without trusting you.
Whether a receipt is admissible, or sufficient, in a given court, regulatory or contractual setting depends on the jurisdiction and the case. A receipt is a technical record of what was presented to, or observed by, a signing service. It is not legal advice, not a certification and not proof of compliance. Ask your own counsel, and consider writing into your contracts that both sides accept receipts verified against the published keys as evidence of the facts they state.
A limit stated plainly builds more trust than a claim, because a receipt is only as useful as the precision with which people describe it. If you find a place where our own pages overstate what a receipt proves, tell us at /contact and we will fix it.
Trustvice receipts are built on SHA-256 hashes and metadata, not on your documents, prompts or response bodies. This is the privacy design behind that choice, what it protects, and the places where it does not protect you on its own.
3 min read
A field-by-field tour of the Trustvice receipt envelope, why we sign an RFC 8785 canonical form instead of the bytes on the wire, how key IDs are derived from the keys themselves, and what the published key set promises.
6 min read
Two correct RFC 8785 implementations can still disagree on key order, big numbers and unpaired surrogates. We walk through each edge case in JavaScript and Python, what our canonicalizers do, and how shared test vectors catch drift.
8 min read
Paste any Trustvice receipt into the verifier. It checks the signature in your browser against our published keys, with no account needed.
Trustvice 360: trust and govern your AI agents with signed, verifiable evidence.
Digital Trust. On the Record.
The innovation platform for
Software‑as‑a‑Service.