Codebase modernised and maintained — network live

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.

The proposition

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 →
“LKSCOIN is a decentralised network to certify, notarise, verify and trace data, documents, content and processes.”

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.

Services

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.

Live — beta

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 public verification page anyone can use. Running on mainnet since August 2026.

Notarise a document → Verify a document → How it works →
Live — beta

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.

Record a lot event → How it works →
Planned

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 →
Public beta

Everything below is live on mainnet — try it, then tell us what breaks

No registration and no cost: 20 proofs a day per connection. Every one of them is a real transaction on the LKSCOIN chain, anchored to Bitcoin within hours.

Why the proof holds

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.

L1

Consensus — Proof of Work (X11)

Block ordering and production on a chain that has been running continuously since launch.

Live
L2

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.

To activate
L3

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.

Phase D

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.

The network

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.

702Registered masternodes*
5.18Core release
2 OSLinux & Windows builds
X11PoW algorithm

* Entries in the on-chain deterministic list. The operator census of August 2026 found that only a small fraction of them still answer on the network: the rest are entries left behind by four years of inactivity, which no quorum has been able to evict because eviction itself depends on quorums. Restoring that is the point of the network revival described in the roadmap — and stating the measured figure rather than the registered one is the only version of this page worth publishing.

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.

Who it is for

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 →
How we work

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.