Core concepts

Understanding how Invoance works at the cryptographic level. These concepts underpin every anchored event, every signature, and every independent verification.

Canonical payload

Before hashing or signing, every submitted record is normalized into a deterministic canonical form. This ensures that the same logical record always produces the same hash, regardless of whitespace or encoding differences in the original request.

Why it mattersWithout canonicalization, two identical records could produce different hashes depending on how the payload was serialized. Verification would be unreliable.

Server-sideCanonicalization is always performed server-side. You submit a structured JSON payload, Invoance handles normalization before hashing and signing.

Version fieldEvery canonical struct includes a version field (v: 1) to allow schema evolution without breaking existing proofs.

Invoance uses two canonicalization strategies depending on the resource type:

Events, lexicographic key sort

Event payloads are recursively sorted by key before serialization. This means key order in your request does not matter, the same logical payload always produces the same canonical form.

AI Attestations and Documents, struct field order

Attestation and document payloads use a fixed struct field order defined server-side. The canonical struct includes internal fields (attestation_id, tenant_id, hashes, timestamps) that your request does not contain, these are added by the server at ingestion time.

Event canonicalization (lexicographic sort)

// Input (any key order)
{ "data": { "id": "inv_9f3a", "amount": 14200 }, "type": "invoice.approved" }

// Canonical form (keys sorted recursively, whitespace stripped)
{"data":{"amount":14200,"id":"inv_9f3a"},"type":"invoice.approved"}

// SHA-256 of canonical form
→ 9f3ac21e4b7d…

Attestation canonical struct (fixed field order)

// Server builds the canonical struct with internal fields:
{
  "v": 1,
  "attestation_id": "9549c332-a52b-…",
  "tenant_id": "cf912d40-865c-…",
  "attestation_type": "output",
  "input_hash": "2f096d5e…",
  "output_hash": "8a331903…",
  "payload_hash": "8c741766…",
  "model_provider": "openai",
  "model_name": "gpt-4.1",
  "model_version": "2026-01-01",
  "created_at": "2026-03-06T03:57:29.529647Z"
}

// This entire struct is serialized, then Ed25519-signed

Content hashing

Every anchored record is reduced to one or more SHA-256 hashes. These hashes are the immutable fingerprints of the record, they are what verification resolves against.

AlgorithmSHA-256, deterministic, collision-resistant, and independently computable by any verifier using standard tools.

Server-sideAll hashes are computed server-side from the canonical form. You never need to pre-compute hashes (though you can, for client-side verification).

Tamper evidenceIf the payload changes, even by a single character, the hash changes. This makes silent modification detectable without trusting Invoance.

Each resource type computes multiple independent hashes for different verification and deduplication purposes:

AI Attestations, 3 hashes

input_hash, SHA-256 of the input text alone

output_hash, SHA-256 of the output text alone

payload_hash, SHA-256 of the entire canonical request body (used for deduplication)

Events, 3 hashes

payload_hash, SHA-256 of the canonicalized payload

request_hash, SHA-256 of event_type + event_time + payload (used for deduplication)

event_hash, SHA-256 of the full event record

Documents, 1 hash

document_hash, SHA-256 of the original document bytes (provided by the client at anchor time)

Ed25519 signing

After canonicalization, Invoance signs the full canonical payload bytes using Ed25519, a modern, high-performance elliptic curve signature scheme. The signature proves the record was issued by the stated tenant's key and that no field has been altered since ingestion.

AlgorithmEd25519 (Edwards-curve Digital Signature Algorithm). Widely supported, computationally efficient, and deterministic.

Key bindingEach tenant has a unique Ed25519 keypair. The private key signs records. The public key is returned in API responses and exposed at a public endpoint for independent verification.

What is signedThe full canonical payload bytes, not just the hash. This means the signature covers every field in the canonical struct, including the attestation ID, tenant ID, all hashes, and the timestamp.

Signed payload storageThe exact bytes that were signed are stored in the database and returned as the signed_payload field in GET responses. This allows any verifier to reproduce the exact verification without reconstructing the canonical form.

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.

Because the timestamp is included in the signed payload, the signature also proves when the record was created. Backdating a record would require forging a valid Ed25519 signature, which is computationally infeasible.

Immutability

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.

Database enforcementPostgres triggers prevent UPDATE and DELETE operations on all ledger tables. REVOKE UPDATE, DELETE FROM PUBLIC is applied to every table. Application-layer bypasses are structurally impossible.

Duplicate detectionSubmitting identical content returns the existing record with status 'duplicate' rather than creating a new entry. AI attestations use payload_hash, events use request_hash, and documents use document_hash for deduplication.

Why this matters legallyImmutability is what makes proof records defensible. A record that could be altered by an administrator has no evidentiary value.

Access tiers and retention

Rather than deleting records when a retention period expires, Invoance seals them. Sealed records remain in the database to preserve the cryptographic proof chain, but they are hidden from standard read operations.

ActiveDefault tier. Records are visible in GET, LIST, and VERIFY operations. Full read access.

SealedRecords are hidden from GET and LIST responses, but remain accessible to VERIFY endpoints. The cryptographic proof chain is preserved, verification still works. Records can be unsealed on plan upgrade.

Why not deleteHard-deleting records would break the proof chain. A third party holding a proof bundle could no longer verify it against the ledger. Sealing preserves verification integrity while restricting routine access.

Independent verification

Any third party can verify an anchored record without an API key, without an Invoance account, and, using the public key and signed_payload alone, without contacting Invoance at all. Verification is a mathematical operation, not a trust assertion.

Verification steps

1. Retrieve the proof
   GET https://invoance.com/proof/{event_id}
   → { signed_payload, signature, public_key, anchored_at, ... }

2. Verify the Ed25519 signature (strongest)
   Ed25519.verify(public_key, signed_payload, signature)
   → if true, no field has been tampered with

3. Recompute the content hash (optional, content-level)
   SHA-256(canonical(original_payload))
   → must match the payload_hash in the signed_payload

4. Confirm the public key against the tenant domain (optional)
   GET https://api.invoance.com/keys/{tenant_domain}
   → cross-reference public_key against the tenant registry

Steps 2–4 can be performed entirely offline if you have retained the proof bundle (signed_payload, signature, and public_key). Invoance does not need to be reachable for verification to succeed. The SDKs provide verify_signature() and verify_payload() methods that automate this process.

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"
}

How verification works

Public verification endpoints, SDK methods, and offline proof validation.

Endpoints

Full API reference with request and response schemas.

SDKs

Client-side verify_payload, verify_signature, and get_raw.

// Input (any key order) { "data": { "id": "inv_9f3a", "amount": 14200 }, "type": "invoice.approved" } // Canonical form (keys sorted recursively, whitespace stripped) {"data":{"amount":14200,"id":"inv_9f3a"},"type":"invoice.approved"} // SHA-256 of canonical form → 9f3ac21e4b7d…

// Server builds the canonical struct with internal fields: { "v": 1, "attestation_id": "9549c332-a52b-…", "tenant_id": "cf912d40-865c-…", "attestation_type": "output", "input_hash": "2f096d5e…", "output_hash": "8a331903…", "payload_hash": "8c741766…", "model_provider": "openai", "model_name": "gpt-4.1", "model_version": "2026-01-01", "created_at": "2026-03-06T03:57:29.529647Z" } // This entire struct is serialized, then Ed25519-signed

1. Retrieve the proof GET https://invoance.com/proof/{event_id} → { signed_payload, signature, public_key, anchored_at, ... } 2. Verify the Ed25519 signature (strongest) Ed25519.verify(public_key, signed_payload, signature) → if true, no field has been tampered with 3. Recompute the content hash (optional, content-level) SHA-256(canonical(original_payload)) → must match the payload_hash in the signed_payload 4. Confirm the public key against the tenant domain (optional) GET https://api.invoance.com/keys/{tenant_domain} → cross-reference public_key against the tenant registry

// 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" }

Core concepts

Canonical payload

Content hashing

Ed25519 signing

Immutability

Access tiers and retention

Independent verification

Tenants and domain verification

Related

Core concepts

Canonical payload

Content hashing

Ed25519 signing

Immutability

Access tiers and retention

Independent verification

Tenants and domain verification

Related