LKS Notary

Prove that a document existed, unchanged, on a given date

The first service of the network. You submit a hash; the network records a proof; you receive a certificate that anyone can verify — without trusting us, and without your document ever leaving your systems.

Notarise a document Verify a document See the API Legal positioning
How it works

Six steps, one verifiable artefact

Hash the content locally

Your system computes the SHA-256 digest of the file or of the canonicalised dataset. The content itself never leaves your infrastructure.

Submit the hash

The digest is sent to LKS Notary over the REST API with an idempotency key, so a network retry never produces a duplicate proof.

The proof is written to the chain

The service builds a transaction carrying the proof and submits it to the network.

Finality is established

The block is confirmed and, once ChainLocks are active, signed by a masternode quorum — making the record irreversible within seconds rather than after a long confirmation wait.

The aggregated root is anchored to Bitcoin

All proofs in a time window are aggregated into a Merkle tree whose root is committed to Bitcoin through OpenTimestamps.

You receive a certificate

Certificate ID, transaction reference, timestamp, QR code and the .ots attestation file — everything a third party needs to verify independently.

# 1 — hash locally, nothing else leaves your systems
sha256sum contract.pdf
# 6258a5e0…56ba

# 2 — submit the digest
POST /api/v1/notarize
X-API-Key: …
Idempotency-Key: po-2026-00417
{
  "hash": "6258a5e0…56ba"
}

# 3 — the receipt, HTTP 202
# proofs are aggregated, so the chain
# reference appears a few minutes later
{
  "certificate_id": "99e32d42-97f1-437e-a48c-…",
  "status": "pending",
  "received_at": "2026-08-26T07:28:48Z",
  "leaf_hash": "0e01a808…2d34",
  "verify_url": "https://notary.lkschain.io/v/99e32d42-…"
}

# 4 — the proof, once it is on chain
GET /api/v1/verify/99e32d42-…
{
  "status": "confirmed",
  "merkle": { "root": "…", "path": [ … ] },
  "chain": {
    "txid": "7a9d4378…f326",
    "block_height": 997711,
    "chainlocked": false
  },
  "bitcoin": { "anchored": false }
}

No protocol change required

Notarisation is written as an unspendable output carrying arbitrary data, already supported by the codebase. No hard fork, no activation window to coordinate, no mandatory upgrade for wallets, exchanges or operators — which is precisely why it can ship on the available budget.

Verification

A proof nobody has to take on trust

Verifiability is the product. If a certificate can only be checked on our servers, it is a database record with extra steps.

Verify a document now

Public verification page

Every certificate resolves to a page — reachable by QR code — showing the recorded proof, the transaction reference, the timestamp and the anchoring status. Only what the issuer chose to publish is shown.

Independent verifier

An open tool that lets any third party validate a certificate — Merkle path, chain reference and Bitcoin attestation — without depending on our servers. This is the element that makes the whole architecture credible.

Survives the network

Because the Merkle root is committed to Bitcoin, certificates already issued stay verifiable even in the worst-case scenario where the LKS network itself were to degrade in the future.

Use cases

What organisations actually notarise

Contracts & agreements

Prove the version that was in force on a given date, and detect later alteration.

Technical documentation

Manuals, drawings, specifications and revisions with a verifiable version history.

Quality & compliance records

Test reports, inspection minutes and certificates that a customer or auditor can check independently.

Media & photography

Establish which content was associated with an identity at a point in time — including C2PA manifests.

Source code & releases

Anchor build artefacts and release hashes for supply-chain integrity.

Datasets & reports

Canonicalised structured data, so a reordering of JSON keys never breaks verification.

AI-generated material

Record what a system produced or modified, when, and under whose responsibility.

Editorial & scientific content

Publication proofs and a verifiable genealogy of subsequent revisions.

Beyond timestamping

Proof of authenticity and content genealogy

Notarisation naturally evolves into a proof-of-provenance protocol. The system does not claim that a piece of content is “true” in any absolute sense — it demonstrates which content was associated with a given identity at a given date, and whether it was modified afterwards.

Every significant change produces a new proof linked to the previous one, turning the ledger into a registry of verifiable versions: contracts, technical manuals, certifications, software, scientific documentation and editorial content.

Version chain

document v1  →  hash A
document v2  →  hash B   (parent: A)
document v3  →  hash C   (parent: B)
                 ▼
        verifiable history

A proof record carries the issuing identity, the timestamp, the content hash, the version, any attestations and the link to its parent.

Complementary to C2PA, not a competitor

For media and AI-generated material the market standard is C2PA (Content Credentials). Rather than defining a rival proprietary format, LKSCOIN positions itself as the anchoring registry for C2PA assertions: the manifest stays in the standard format, its proof of existence and non-alteration is anchored on the network.

Interested in an early pilot?

We are looking for organisations with a real, already-felt problem: lot recalls, quality disputes, or documentation requests from their own customers.

Verify a document Contact the Foundation Read the API design