Invoance does not ask you to trust its administrators, its infrastructure, or its claims. Every record is independently verifiable using public-key cryptography. Tampering is detectable by construction — not by monitoring.
Every record in Invoance is secured using two well-established, independently auditable cryptographic standards. No proprietary algorithms. No black boxes.
Content hashingApplied to every record payload before signing. Produces a deterministic 256-bit fingerprint. Any alteration to the content — a single character, a timestamp, a whitespace change — produces a completely different hash. Collisions are computationally infeasible.
Digital signaturesEach tenant is issued a unique Ed25519 keypair. The private key signs the SHA-256 hash of every record at ingestion. The corresponding public key is discoverable at a well-known endpoint and can be used by any third party to verify signatures without contacting Invoance.
Immutability enforcementLedger tables have UPDATE and DELETE structurally revoked at the database level via triggers and permission controls. No administrative action, no API call, and no code path can modify a written record. The constraint is architectural, not policy-based.
Deterministic serializationEvery payload is recursively key-sorted before hashing — objects are ordered lexicographically, arrays preserved in sequence. This deterministic serialization guarantees that identical data always produces an identical SHA-256 hash regardless of the original key order, eliminating false mismatches during verification.
Verification of any Invoance record requires only the public key and the record itself. No API key. No account. No contact with Invoance. Any auditor, regulator, or counterparty can verify independently.
GET https://api.invoance.com/keys/acme.com
{
"domain": "acme.com",
"public_key": "MUOiPd4ipnp7amyezsEt9eu3_IuTieQigyfxEIu-3xU",
"algorithm": "ed25519",
"key_id": "invoance:pk_cf912d40"
}import hashlib, json
# The signed_payload from the proof response contains the
# exact canonical structure. Each proof type has its own shape:
#
# ── Event ──────────────────────────────────────────────────
# { "v": 1, "event_id": "...", "tenant_id": "...",
# "event_type": "payment.approved",
# "payload_hash": "a1b2c3...", "request_hash": "d4e5f6...",
# "ingested_at": "2026-03-09T11:07:14Z" }
#
# ── Document ───────────────────────────────────────────────
# { "v": 2, "tenant_id": "...", "actor_type": "api_key",
# "actor_id": "...", "event_type": "document.anchored",
# "document_hash_hex": "9f3a...c21e",
# "ts": "2026-03-09T11:07:14Z" }
#
# ── AI Attestation ─────────────────────────────────────────
# { "v": 1, "attestation_id": "...", "tenant_id": "...",
# "attestation_type": "output",
# "input_hash": "...", "output_hash": "...",
# "payload_hash": "...", "model_provider": "openai",
# "model_name": "gpt-4o", "model_version": "2026-01-01",
# "created_at": "2026-03-09T11:07:14Z" }
signed_payload = record["signed_payload"] # from proof response
canonical = json.dumps(signed_payload, sort_keys=True, separators=(',',':'))
hash = hashlib.sha256(canonical.encode()).digest()from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
import base64
public_key = Ed25519PublicKey.from_public_bytes(
base64.urlsafe_b64decode(fetched_public_key + "==")
)
# Works the same for events, documents, and AI attestations
# Raises InvalidSignature if tampered
public_key.verify(base64.b64decode(record["signature"]), hash)
print("Signature valid — record is untampered")This verification works offline. No network call to Invoance is required after fetching the public key. The key itself is stable per tenant and publicly discoverable.
Each tenant has a unique Ed25519 signing keypair. Keys are generated at tenant creation and stored in an encrypted HSM-backed cache. Cross-tenant key access is structurally impossible — not just prohibited.
Ledger tables have UPDATE and DELETE revoked via database-level triggers. Row-level security ensures tenants can only access their own records. No administrative bypass exists.
Events are published to NATS JetStream before DB writes. Messages are durably persisted with explicit ack — no event is acknowledged until confirmed written. No fire-and-forget paths in the write chain.
All traffic is routed through Cloudflare. DDoS mitigation, TLS termination, and bot protection are applied at the edge before requests reach the application layer.
Tenant identity is bound to DNS. Domain verification via DNS TXT records prevents key squatting — a tenant cannot claim a public key for a domain they do not control.
Public verification endpoints are rate-limited independently from authenticated API paths. Key discovery endpoints are capped to prevent tenant metadata harvesting.
The following are not policy restrictions. They are architectural constraints enforced at the infrastructure level. No administrative action, support request, or API call can override them.
UPDATE and DELETE are revoked at the Postgres role level. The application has no write path that modifies existing rows.
Append-only constraints are enforced by database triggers independent of application logic. Deletion requires dropping the database itself.
Signing keys are scoped per tenant. The signing function accepts only the authenticated tenant's key. Cross-tenant signing is not a code path that exists.
Timestamps are recorded at ingestion by the server and included in the signed payload. The signature covers the timestamp — backdating invalidates the signature.
Verification is performed against the tenant's public key. Forging a valid signature without the private key is computationally infeasible under Ed25519.
Most security models rely on access control — limiting who can read or write records. Invoance adds cryptographic proof — making tampering detectable regardless of access. These are complementary, not competing.
Invoance security is based entirely on open, auditable cryptographic standards — SHA-256, Ed25519, and append-only Postgres. No proprietary algorithms. No trust required beyond the mathematics.