When you open a verification link or check a proof programmatically, Invoance is answering one narrow question:
Is this the exact content that was anchored at a specific point in time and has it been altered since?
Verification is deterministic, reproducible, and independent. It does not require trusting Invoance; it requires trusting mathematics.
Invoance anchors three categories of records. Each has its own public proof page where anyone can verify a record without an account.
Anchored documents such as invoices, contracts, and compliance records. Verification confirms the document content is unchanged since it was recorded on the ledger.
invoance.com/proof/document/{event_id}Verify now Compliance events ingested via API. Verification confirms the event payload is intact. Supports both SHA-256 hash input and direct JSON payload comparison.
invoance.com/proof/event/{event_id}Verify now AI-generated outputs with cryptographic provenance. Verification confirms the exact AI output was anchored, including model, provider, and input/output hashes.
invoance.com/proof/ai/{attestation_id}Verify now All proof pages share a common set of fields. No login required.
The verified organization that issued the record, identified by their domain. Domain verification is performed via DNS TXT record — independently auditable by anyone.
The SHA-256 fingerprint of the exact payload at the moment it was anchored. If the content changes by a single character, this hash changes completely.
The Ed25519 digital signature produced by the tenant's private key. Proves the record was issued by the stated organization and has not been tampered with.
The timestamp recorded when the event was ingested. This is part of the signed payload and cannot be backdated after the fact.
The Ed25519 public key used to verify the signature. Anyone can use this key to independently validate the signature matches the signed payload.
When you open a proof page, this is what happens in order. You can replicate every step yourself using standard tools.
The original event payload is serialized into a deterministic canonical form. This ensures the same content always produces the same hash regardless of how it was originally formatted.
canonical = serialize_deterministic(payload)SHA-256 is applied to the canonical payload bytes. The result is a 256-bit fingerprint that uniquely identifies this exact content. Any change — even a space — produces a completely different hash.
payload_hash = SHA256(canonical_payload)
→ 9f3ac21e4b7d...The computed hash is compared against the hash stored in the immutable ledger at anchor time. If they match, the content is intact. If they differ, the content has changed since anchoring.
computed_hash === stored_hash → ✓ content intact
computed_hash !== stored_hash → ✗ content changedThe digital signature is validated against the tenant's public key. A valid signature proves the record was produced by the holder of the private key — the issuing organization.
Ed25519.verify(public_key, payload_hash, signature)
→ true ✓ signature authenticThe public key is matched against the tenant's verified domain. Domain verification is performed via DNS TXT record, which is independently auditable by anyone.
DNS TXT → invoance-verify=<public_key_fingerprint>
→ domain ownership confirmed ✓Document proof pages verify anchored business records such as invoices, contracts, purchase orders, and compliance filings. The proof page displays the following.
To verify, enter the SHA-256 hash of the original document content. The system compares it against the anchored hash and returns a match or mismatch result.
Event proof pages verify compliance events ingested via the Invoance API. These are arbitrary structured events — audit logs, status changes, webhook receipts, or any business event your system records.
Two ways to verify an event
The event verification page accepts two input modes:
AI attestation proof pages work identically to standard event proofs but include additional fields specific to AI-generated content.
You do not need Invoance to be online or trusted to verify a record. If you have the original payload and the proof bundle, verification is a local cryptographic operation.
Original payloadThe exact bytes of the content that was anchored. For events, this is the JSON payload sent to the ingest API. For documents, this is the document content. For AI attestations, this is the attested output.payload_hashFrom the proof response. The stored SHA-256 fingerprint to compare against.signatureFrom the proof response. The Ed25519 signature to validate.public_keyFrom the proof response or the tenant key registry. Used to validate the signature.SHA-256 toolAny standard implementation. OpenSSL, Python hashlib, Node.js crypto — all produce identical results.Ed25519 libraryAny Ed25519-compatible library. libsodium, PyNaCl, Node.js crypto, Go's ed25519 package.Choose the type of record you want to verify. No account required.