Demo Docs Pricing Integrity Sign in Try it free
Integrity model

Verifiable by anyone. Trusted by no one.

DarkMatter’s guarantees are cryptographic, not contractual. Here is exactly what we claim, and how to verify it yourself.

Run the verifier →Read ENVELOPE_SPEC_V1
Three properties · non-negotiable
L101 / 03

Tamper-evident hash chain

Every commit is SHA-256 hashed and linked to its parent. The SDKs compute the hash on your machine before transmission; a direct API call is hashed by the server. Modifying any record breaks every downstream hash, detectable by anyone, offline, with no DarkMatter dependency.

L202 / 03

Timestamp anchor

Checkpoints sign the Merkle root of the log and are delivered to registered witnesses for co-signature. Every witness running today is operated by DarkMatter, so the co-signature does not yet let you check the attestation without trusting us.

L303 / 03

Non-repudiation

Commits are signed with a key only you hold before they reach our servers. DarkMatter cannot forge a record on your behalf. Non-repudiation by construction, not by policy.

Verification levels

Assurance levels (L1 through L3) describe the strength of the cryptographic guarantee. Each level is additive.

L101
Verifiable record
SHA-256 payload hash + parent chain linkage. Tampering at any node breaks every downstream hash. Independent offline verifier included.
Default with every dm.commit() call. No extra steps.
L202
Independent verification
Signed checkpoints, delivered to registered witnesses for co-signature (all witnesses currently operated by DarkMatter). Live status at /api/log/checkpoint.
Automatic. Every checkpoint batch is anchored and signed.
L303
Non-repudiation
Customer-held signing keys. Even DarkMatter cannot forge a record. Only your key can sign a valid commit.
Available now. Generate a key with dm.generate_customer_keypair() in Python. See L3 setup.
What we claim · and what we don’t
We claim

Payload wasn’t altered after commit

The SHA-256 hash is computed on your machine before transmission when you use an SDK, and by the server when you post to the API directly. Any modification breaks the hash. Verifiable offline in both cases.

We claim

Records are sealed when they happen

Each record commits to the hash of the one before it, so a record cannot be altered, reordered or inserted after the fact without breaking every record that follows. This is what the offline verifier checks. It establishes ordering and integrity. For a time reference, a checkpoint signs the log root on a ten-minute cycle and is delivered to registered witnesses for co-signature, with the result published as witness_count and witness_status at /api/log/checkpoint. Every witness running today is operated by DarkMatter, so that co-signature is not yet attestation by a party other than us. If your organisation wants to change that, the reference witness server is a single Python file with no dependencies beyond the standard library: darkmatter_witness_server.py. It verifies our signature, co-signs the same canonical envelope with a key only you hold, and keeps its own log. Email [email protected] with your public key to be registered.

We claim (L3)

DarkMatter cannot forge a record

Customer-held Ed25519 keys sign the envelope before it reaches our servers. We never see the private key. We cannot produce a valid signature.

We do not claim

Payload confidentiality

Payloads are stored in plaintext by default. DarkMatter personnel with database access can read them. To keep payloads private, encrypt client-side before calling dm.commit(). This works on any plan. DarkMatter stores whatever you send.

Technical specification
Hash algorithm
SHA-256 · canonical JSON serialization
Signature algorithm
Ed25519 · ENVELOPE_SPEC_V1
Timestamp anchor
Witnessed checkpoint
Key management
Customer-generated Ed25519 keypair · public key registered · private key never transmitted
Offline verifier
Get started

Verify it yourself.

Download a proof bundle and run the offline verifier. No DarkMatter account required.

Run the verifier →Read the docs