Understanding how Invoance works at the cryptographic level. These concepts underpin every anchored event, every signature, and every independent verification.
Before hashing or signing, every submitted event is normalized into a deterministic canonical form. This ensures that the same logical event always produces the same hash — regardless of JSON key ordering, whitespace, or encoding differences.
Why it mattersWithout canonicalization, two identical events could produce different hashes depending on how the payload was serialized. Verification would be unreliable.
How it worksInvoance serializes the payload using a deterministic algorithm: keys are sorted lexicographically, whitespace is stripped, and Unicode is normalized before SHA-256 is applied.
Server-sideCanonicalization is always performed server-side. You submit a structured JSON payload — Invoance handles normalization before signing.
Canonicalization example
// Input (any key order, any whitespace)
{
"type": "invoice.approved",
"data": { "amount": 14200, "id": "inv_9f3a" }
}
// Canonical form (sorted keys, no whitespace)
{"data":{"amount":14200,"id":"inv_9f3a"},"type":"invoice.approved"}
// SHA-256 of canonical form
→ 9f3ac21e4b7d...Every anchored event is reduced to a SHA-256 hash of its canonical payload. This hash is the immutable fingerprint of the event — it is what verification resolves against.
AlgorithmSHA-256 — deterministic, collision-resistant, and independently computable by any verifier.
What is hashedThe canonical form of the submitted event payload. Not the raw request body.
VerificationTo verify a record, a verifier recomputes SHA-256 of the original payload and compares it to the stored hash. Any change to the payload produces a different hash.
Tamper evidenceIf the payload changes — even by a single character — the hash changes. This makes silent modification detectable without trusting Invoance.
After hashing, Invoance signs the canonical payload hash using Ed25519 — a modern, high-performance elliptic curve signature scheme approved by NIST. The signature proves the record was issued by the stated tenant's key.
AlgorithmEd25519 (Edwards-curve Digital Signature Algorithm). NIST-approved, widely supported, and computationally efficient.
Key bindingEach tenant has a unique Ed25519 keypair. The private key signs records. The public key is exposed for independent verification.
What is signedThe SHA-256 hash of the canonical payload, plus the tenant ID and timestamp. This binds the proof to a specific organization and point in time.
Forgery resistanceA valid signature can only be produced by the holder of the private key. Invoance cannot produce a valid signature for a record it did not anchor.
The Invoance ledger is append-only by design. Once an event is anchored, it cannot be modified or deleted — not by your system, not by Invoance operators. This constraint is enforced at the database level, not just in application logic.
EnforcementPostgres immutability triggers prevent UPDATE and DELETE operations on ledger tables. Application-layer bypasses are structurally impossible.
No soft deletesThere are no soft delete fields, status flags, or archival states that would allow a record to be hidden from verification.
Retention expiryRecords are retained for the duration of your plan's retention period. At expiry, records are purged — not modified. The proof itself remains verifiable offline if you have retained the original payload.
Why this matters legallyImmutability is what makes proof records defensible. A record that could be altered by an administrator has no evidentiary value.
Any third party can verify an anchored record without an API key, without an Invoance account, and — using the public key alone — without contacting Invoance at all. Verification is a mathematical operation, not a trust assertion.
Verification steps
1. Retrieve proof
GET https://invoance.com/proof/{event_id}
→ { payload_hash, signature, public_key, anchored_at }
2. Recompute hash
SHA-256(canonical(original_payload))
→ must match payload_hash exactly
3. Verify signature
Ed25519.verify(public_key, payload_hash, signature)
→ must return true
4. Confirm public key (optional, offline)
GET https://api.invoance.com/keys/{tenant_domain}
→ cross-reference public_key against tenant registrySteps 1–3 can be performed entirely offline if you have retained the original payload and the proof bundle. Invoance does not need to be reachable for verification to succeed.
Tenants and domain verification
Every Invoance account belongs to a tenant — an isolated organizational unit with its own keypair, event ledger, and verification namespace. Tenants verify ownership of their domain via DNS TXT record, which binds their public key to a publicly auditable domain identity.
DNS TXT recordYou add a TXT record to your domain's DNS zone. Invoance polls for it and marks the domain as verified once confirmed.
Key bindingAfter verification, your tenant's Ed25519 public key is associated with your domain. Third parties can confirm the key belongs to your organization.
Proof attributionVerification responses include the tenant's verified domain alongside the public key, allowing auditors to confirm organizational identity without trusting Invoance.
// DNS TXT record to add
invoance-verify=<your_verification_token>
// Once verified, your domain appears in proof responses
{
"tenant_domain": "acme.com",
"public_key": "invoance:pk_tenant_7b1c"
}
