Three layers of guarantee behind every proof
A notarisation is a proof of existence and integrity anchored to a ledger. If the ledger can be reorganised, the proof can be disputed. This page explains, without hand-waving, why it cannot be.
Conceptual stack
Services are thin application layers over a chain that already provides consensus, deterministic quorums and a public operator registry. A significant part of what a project like this would normally have to build does not need building — it needs activating and correctly sizing.
LKSCOIN BLOCKCHAIN
PoW X11 + LLMQ + ChainLocks
│
┌───────────┴───────────┐
│ Masternode network │
│ consensus / BLS quorums │
└───────────┬───────────┘
│
┌────────────────────┬────────────────────┐
│ │ │
LKS Notary LKS Trace LKS Identity
documents / data lots / supply chain identity / signatures
│ │ │
└────────────────────┴────────────────────┘
│
LKS Service API
│
┌──────────────────┬──────────────────┐
│ │ │
Storage Oracle Governance
/ metadata / IoT / API MN voting
│
Bitcoin anchoring (OTS)
Finality is the product requirement
A proof-of-work chain with marginal hashrate is exposed to reorganisations obtainable with rented hashrate. The number of masternodes does not, by itself, protect against this: under pure PoW, masternodes do not participate in choosing the valid chain. That is the problem the finality layer exists to solve.
PoW X11 — consensus
Ordering and block production. Existing and continuously operating.
LLMQ + ChainLocks — finality
Block irreversibility within seconds. A reorganisation requires compromising the signing quorum, not accumulating hashrate.
Bitcoin anchoring — external attestation
Verifiable by parties that trust neither the LKS quorums nor the Foundation; independent of the network's own survival.
What ChainLocks do
ChainLocks were designed precisely to neutralise the 51% attack. When an LLMQ quorum signs a block, nodes reject any competing chain regardless of accumulated proof of work: a chain mined in private, however long, is discarded the moment it is published.
The classic attack — a deep reorganisation and a double spend against an exchange — stops being achievable with hashrate alone.
Sizing quorums for this network
The default LLMQ presets are calibrated for networks in the order of thousands of nodes. At the scale of the LKS network the parameters have to be resized, verifying that the distributed key generation converges reliably and that quorum formation does not fail in the presence of offline nodes.
- Select smaller quorum types instead of large-network presets.
- Measure the rate of failed DKG rounds and the share of members actually participating, on testnet, before mainnet activation.
- Verify that the number of genuinely reachable masternodes is sufficient to form overlapping quorums without saturating the same nodes.
Already in the codebase
| Component | Function |
|---|---|
| LLMQ BLS quorums + DKG | Deterministic signing quorums formed by masternodes |
| ChainLocks | Quorum-signed finality of the first-seen block |
| DIP-3 deterministic MN list | On-chain, verifiable registry of operators |
| Governance / treasury | Masternode proposals and voting |
| InstantSend | Fast transaction confirmation |
Activation of LLMQ and ChainLocks is a network operation, not a development task. It is sequenced in the funded plan after the consensus-validation and migration phases.
Anchoring to Bitcoin
The mechanism runs at close to zero operating cost, because OpenTimestamps aggregates the requests of many users into a single Bitcoin transaction.
Periodic aggregation
All proofs recorded in a time window are collected into a Merkle tree.
Root submission
The root is submitted to an OpenTimestamps calendar server, which includes it in a Bitcoin transaction together with other roots.
Attestation completion
The .ots attestation file is completed with the Bitcoin transaction reference and delivered alongside the certificate.
Independent verification
A single document is verified through its Merkle path — without needing to trust LKSCOIN or the service.
Recommended cadence: one to six anchors per day.
Why anchoring is the right periodic checkpoint
Anchoring performs the function one might be tempted to assign to a periodically signed checkpoint: establishing fixed, non-rewritable points at regular intervals.
The difference is decisive — there is no privileged key. Anyone can verify that on a given date the chain was in a given state, without trusting the project or the Foundation.
It also provides automatic detection: a node observing a chain that diverges from a published Bitcoin anchor knows with certainty that it is on a divergent branch. Anchoring does not enforce anything — it is an objective detector that no single party controls.
From passive network component to service provider
The active masternode network is the project's central infrastructure asset. The objective is to evolve its role rather than merely preserve it.
Validation and consensus
The baseline role, unchanged.
LLMQ participation
Membership in signing quorums and ChainLock signatures.
Notarial quorums
Quorum signatures for notarisation and attestation services.
Governance and treasury
Proposals, voting and budget allocation.
Decentralised API services
A later architecture in which service endpoints are themselves distributed.
Oracle and storage support
Optional roles evaluated once the core services are stable.
Economic changes are governance events, not engineering decisions
Modifying the reward model on a live network of independent operators is a political act. Any economic change is discussed publicly and in advance, with an operator working group, before it is proposed. Operators who perceive dilution or uncertainty simply switch their nodes off — and the network is exactly the asset being presented to the market.
LKS Identity — keys, credentials, attestations
The second evolutionary layer: a decentralised identity bound to public keys and verifiable attestations.
The recommendation here is explicitly not to define a proprietary schema. The standards to adopt are W3C Decentralized Identifiers (DID) and W3C Verifiable Credentials (VC), with attention to the evolution of the European EUDI Wallet, which will become the reference for digital identity across the Union. A proprietary format today is an integration debt tomorrow.
The system can support document signing and verification, designed with a clear separation between the ledger proof and any legal requirements applicable to electronic signatures.
LKS Identity (DID) ├─ public key / key rotation ├─ identifier (did:lks:…) ├─ signatures ├─ verifiable credentials └─ attestations / revocations
LKS Oracle
A service to validate externally sourced data: IoT and industrial sensors, weather data, prices, event status and data coming from enterprise systems. The LLMQ infrastructure already present in the codebase provides the signing-quorum mechanism on which to build it.
Already in the codebase
The governance and treasury system does not need designing — it needs activating, once the network is stable and the community is active enough to produce quality proposals.
proposal │ masternode voting ├─ YES ├─ NO └─ ABSTAIN │ decision / treasury / upgrade
What we build on
Identifiers, credentials and canonicalisation follow recognised specifications. Otherwise enterprise integration becomes impractical and verification breaks at the first update.
GS1 Digital Link
Product and lot identification, QR resolution
W3C DID / VC
Decentralised identifiers and verifiable credentials
C2PA
Content credentials for media and AI-generated material
RFC 8785 (JCS)
Deterministic JSON canonicalisation before hashing
OpenTimestamps
Bitcoin anchoring and portable .ots attestations
RFC 3161
Qualified timestamping in the hybrid configuration
eIDAS / eIDAS 2.0
European framework for trust services and identity
ESPR / DPP
EU Digital Product Passport as the traceability driver
Read the code, not the claims
Public repository, continuous integration and reproducible builds for Linux and Windows.