Proof, not promises. Infrastructure for verifiable data.
LKSCOIN is a decentralised network to certify, notarise, verify and trace data, documents, content and industrial processes — with public verifiability, quorum-based finality and periodic anchoring to Bitcoin.
One network, one job: making data provable
LKSCOIN is not trying to become a general-purpose blockchain. It builds on what already exists — a live chain, a working consensus and an active masternode network — to deliver one class of service that organisations actually need.
Notarisation is the first service. On top of it sit proof of authenticity, identity and signatures, industrial traceability, off-chain storage references, oracles and governance. Each layer reuses the same cryptographic primitive: a proof recorded on a public ledger, independently verifiable by anyone.
See the architecture →Data stays yours
Only hashes, timestamps and minimal metadata go on-chain. Documents and sensitive data never leave your systems.
Open standards
GS1 Digital Link, W3C DID/VC, C2PA, RFC 8785 and OpenTimestamps — not proprietary formats.
Built in layers, shipped in order
Each service is a thin application layer over the same chain. Notary comes first because it requires no protocol change and can be verified by anyone today.
LKS Notary
Certify the existence and integrity of a document or dataset at a given point in time. Hash in, verifiable certificate out — with a QR code and a public verification page.
Notarisation →LKS Trace
A proof-of-integrity layer for supply chains. Lot genealogy, transformation events and chain of custody — aligned to GS1 Digital Link and positioned for the EU Digital Product Passport.
Traceability →LKS Identity & Proof
Decentralised identifiers, verifiable credentials, signatures and content genealogy — including anchoring of C2PA content credentials for media and AI-generated material.
Identity layer →A notarisation is worth exactly as much as the finality of the ledger behind it
Most notarisation products stop at “we wrote a hash to a blockchain.” That is not an answer to the only question a technical evaluator will ask: what would it cost to rewrite that history? LKSCOIN answers it with three independent layers.
Consensus — Proof of Work (X11)
Block ordering and production on a chain that has been running continuously since launch.
Finality — BLS quorums and ChainLocks
Masternode quorums sign the first-seen block. A competing chain is rejected regardless of accumulated proof of work, so reversal requires compromising the quorum rather than out-mining the network.
External anchoring — Merkle roots on Bitcoin
Proofs are aggregated into a Merkle tree whose root is committed to Bitcoin via OpenTimestamps. Verification requires trusting neither LKSCOIN nor the Foundation, and certificates stay verifiable independently of the network's future.
The commercial consequence: a proof that is as inexpensive to produce as on LKSCOIN, and as robust to verify as one anchored to Bitcoin. No privileged key is involved in that verification — anyone can check that on a given date the ledger was in a given state.
An infrastructure asset, not a whitepaper
The masternode network kept running through four years of project inactivity. It is the layer that makes the cryptographic proof defensible in front of an enterprise buyer.
* Figure inherited from the network's historical state and currently under validation through the operator census. It will be replaced by measured data as soon as the census closes.
Deterministic masternode list (DIP-3)
An on-chain, publicly auditable registry of operators — the basis for quorum formation and for measurable decentralisation.
LLMQ — BLS quorums
Deterministic signing quorums formed by masternodes, already present in the codebase and to be sized against the real scale of the network.
Governance & treasury
Proposal and voting infrastructure inherited with the codebase. To be activated once the network is stable and the community is active enough to produce quality proposals.
Three audiences, three entry points
Companies
Manufacturers, food producers and service providers that need to demonstrate a document or a production event has not been altered after the fact — priced and invoiced in euro, under an ordinary commercial contract.
Legal positioning →Developers
A REST API with idempotency keys, deterministic canonicalisation and versioned hashing — plus an independent verifier that validates any certificate without depending on our servers.
API and tooling →Masternode operators
Reproducible builds, a public testnet, a step-by-step migration guide for the DIP-3 transition and a fixed cadence of technical updates — including the ones that report negative results.
Operator area →Design principles
- Real utility before feature count. One service that works beats six that are announced.
- Do not change the protocol when it is not needed. Notarisation runs as an application layer over the existing chain — no hard fork, no coordination with exchanges or third-party wallets.
- Separate data from proof. Sensitive or bulky data stays off-chain; the ledger records hashes, timestamps and minimal metadata.
- Open standards over proprietary formats. Identifiers, credentials and canonicalisation follow recognised specifications, or enterprise integration becomes impractical.
- State the limits before the client finds them. The legal perimeter of the proof is written down in the technical and commercial material.
- Commit only to what is funded. Every publicly declared deliverable has budget coverage and a date. Everything else is labelled as direction, not commitment.
Follow the work, not the announcements
Public repository, continuous integration, reproducible builds and a technical update every two weeks — including the ones with negative results.