Security through cryptographic enforcement, not policy.
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.
Data privacy and protection
We understand that sending data to a third party requires trust, legal review, and guarantees. Invoance is built to meet the data protection expectations of regulated institutions — from encryption and tenant isolation to data residency controls.
All data is encrypted in transit using TLS 1.3. At rest, every record is encrypted before it reaches storage. Your data is never stored in plaintext — not in the database, not in object storage, not in backups.
Each organization operates as a fully isolated tenant with its own Ed25519 signing keypair, database-level row isolation, and scoped API credentials. There is no shared keyspace. One tenant cannot access, query, or reference another tenant's data under any circumstance.
Your data is never shared with other tenants, third-party analytics providers, advertisers, or training pipelines. Invoance processes your data solely to produce cryptographic proofs. Nothing more.
Each subscription tier includes a default retention duration. Need longer retention to meet regulatory or internal requirements? You can purchase extended retention at any time. When the retention period expires, records are purged. You can also request deletion of your tenant and all associated data.
What happens when you send data to Invoance
Every piece of data sent to Invoance follows the same pipeline — encrypted, hashed, signed, and stored immutably. Here is exactly what happens, step by step.
Your data is sent over TLS 1.3. It is encrypted from the moment it leaves your system until it reaches the Invoance processing layer. No intermediary can read it.
Your API key is verified and the request is scoped to your tenant. No other tenant's data is accessible during processing. Rate limits and permissions are enforced before any data is written.
The payload is canonicalized, hashed with SHA-256, and signed with your tenant's unique Ed25519 private key. This produces a cryptographic proof that the data existed in this exact form at this exact time.
The signed record is encrypted and written to append-only storage. Once written, no API call, no admin action, and no code path can modify or delete the record. The constraint is architectural.
A public proof link is generated. Anyone with the link can verify the record's integrity using your organization's public key — without logging in, without contacting Invoance, without trusting anyone.
Cryptographic primitives
Every record in Invoance is secured using 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.
Independent verification — no trust required
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
signed_payload = record["signed_payload"]
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 + "==")
)
# 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.
Infrastructure controls
Each tenant has a unique Ed25519 signing keypair. Keys are generated at tenant creation and stored encrypted. 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 a durable message queue before database writes. Messages are persisted with explicit acknowledgment — no event is confirmed until written. No fire-and-forget paths exist.
All traffic is routed through a global edge network. DDoS mitigation, TLS termination, and bot protection are applied 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.
What Invoance cannot do — by design
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 database 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.
Row-level security and scoped API keys enforce tenant boundaries. There is no admin panel, no support tool, and no API endpoint that crosses tenant boundaries.
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.
There is no data pipeline, export function, or integration that sends tenant data to any external service. Data is processed solely to produce cryptographic proofs.
Cryptographic proof vs. access control
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.
Explicit scope boundaries
Invoance security is based entirely on open, auditable cryptographic standards — SHA-256, Ed25519, and append-only storage. No proprietary algorithms. No trust required beyond the mathematics.
Invoance Security Architecture
Security through cryptographic enforcement, not policy. 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. SHA-256 hashing, Ed25519 signatures, append-only storage.