The network kept running. Now it has to move.
The hardest gate in this project is not the code — it is coordination. Activating quorum finality requires operators to migrate. This page is where everything an operator needs will live: builds, guides, testnet, status and honest updates.
Current status
The most feared gate — “the code no longer builds or can be maintained” — has been cleared. The codebase has been brought up to a current, maintainable baseline; builds work on Linux and Windows; updated nodes are synchronised with the rest of the network.
Codebase modernised
Conflicts resolved manually, working builds on Linux and Windows, updated nodes synchronised with the network.
Consensus validation
Proving the updated binary is a transparent replacement under the consensus rules currently in force, before anything is rolled out.
Public testnet & census
Open testnet, migration guide, LLMQ parameter sizing and a count of how many operators are actually reachable.
No activation date will be announced before the census closes
Announcing a deadline and missing it, after four years of inactivity, costs more than not announcing one. Dates appear here only once the underlying number is known.
LKSCOIN Core
Reproducible builds and continuous integration are part of the funded plan: the point is not just that binaries exist, but that anyone can rebuild them and get the same artefact.
Current build
LKSCOIN Core 5.18.2.1 — the current maintained release. It changes no consensus rules and activates no fork: 5.18, 4.17 and 3.x nodes interoperate on the same network, so operators can upgrade at their own pace.
Check the package before installing it. On the downloaded file:
sha256sum LKSCoinCore_5.18.2.1.deb 59ae7deda88e330ce76282ce0d75a0a9f3a65a2872f8343d67d5ae408bc6b465
Masternode operators: the first
start after the upgrade migrates the LLMQ databases and can take up to an hour on a
single-CPU VPS, during which the RPC answers error code: -28 and the node
looks stuck. Do not interrupt it — an interrupted migration forces a full reindex. Later
restarts are back to seconds. See the
upgrade guide.
Source & build pipeline
The repository, the CI configuration and the build instructions are published so the binaries can be independently reproduced.
Desktop wallet
The LKSCOIN GUI wallet is a cross-platform client that downloads the full chain and lets you inspect your own transactions locally.
Web wallet
A client-side online wallet: wallet data stays on your device and our servers are used only to synchronise with the network. Fully interoperable with the desktop version.
What a masternode does here
A masternode is a full node that keeps a complete, real-time copy of the ledger. Beyond validation, masternodes provide fast transaction confirmation, participate in governance and consensus, and enable the budget and treasury system.
As with full nodes on any network, anyone can run one. A collateral requirement acts as the barrier to entry that keeps the system from being cheaply captured.
In the 2.0 direction their role expands: from a passive component of the network to a provider of decentralised services — LLMQ membership, ChainLock signatures, and quorums for notarial and attestation services.
Setup instructionsOperator working group
We are looking for 5 to 10 operators who kept their nodes running through these years. They bring expertise, volunteer effort and legitimacy — without them any relaunch is perceived as an outside operation.
Members get early access to testnet parameters, review of migration tooling before it ships, and a direct channel on any proposed economic change.
Join the working groupOperator census
How many of the active masternodes correspond to a genuinely reachable operator, and how many distinct operators exist? That figure determines whether migration is feasible at all — and it is being collected before any date is announced.
DIP-3 migration
The deterministic masternode list requires every operator to submit a registration transaction to migrate from the legacy system. Operators who do not, drop out of the network. Across hundreds of nodes — many run by people who have not followed project channels since 2021 — this is the dominant risk, and it is organisational rather than technical.
How we intend to handle it
- A long migration window, with a grace period declared in advance.
- Activation only once an adoption threshold on registered collateral is reached — indicatively 70%.
- Active support channels: a written guide, assisted migration scripts, and staffed presence on chat and forums.
- Direct, repeated contact with every operator identified during the census.
- A documented rollback plan in case adoption is insufficient.
Before you conclude anything about rewards
If a merge raises the protocol version beyond the minimum accepted by legacy nodes, those nodes discard messages from updated masternodes. The node silently disappears from the list seen by the majority and stops being paid, with no obvious error.
It looks like a rewards bug; it is a version gate. Sentinel compatibility is checked in the same way, to avoid expired-watchdog states. Both are verified before any rollout.
Block explorer
Public exploration of blocks, transactions and the masternode list. The explorer and public APIs are being realigned to the new codebase.
Open explorer →Public testnet
Open to operators, with a step-by-step migration guide. This is where LLMQ parameters are sized against the real scale of the network and the DKG completion rate is measured.
Testnet & guide →Technical updates
A public update every two weeks — short is fine, negative results included. Regularity is what distinguishes a live project from one that publishes a document and disappears.
Read updates →How we test before touching the live network
With a handful of updated nodes against hundreds of legacy ones, the updated minority is overwhelmingly outnumbered: any validation divergence would detach those nodes from the network. So the tests are designed to catch divergence, not to confirm a hoped-for result.
- Tip alignment. Continuous comparison of the best block hash between updated and legacy nodes. Any persistent divergence indicates a consensus incompatibility. Automated, with alerting.
- Masternode list and expected payments consistency between old and new binaries.
- Log analysis for block-connection failures and peer misbehaviour — if legacy nodes penalise updated ones, the problem is at the P2P layer, not in rewards.
- Sporks unchanged. Nothing new is activated during this phase.
Payment test design
The criterion is not “did it get paid, yes or no” — it is the observed rate against the expected one. At this network size the expected interval is on the order of hundreds of block times: an intermittent defect shows up as a halved frequency, not as a total absence, and without a baseline it is undetectable.
- Keep a control group of our own masternodes on the legacy binary, in the same time window.
- Compare the two rates over at least three or four complete payment cycles before drawing conclusions.
- Use project-owned test nodes, so restarts and restores need no third-party authorisation.
- Back up data directories and previous binaries; keep collateral on a separate wallet, never exposed on test nodes.
Non-negotiable tests
- Full sync from block 0 with the new binary on a clean machine — the only proof that historical consensus rules still hold at old heights.
- Full reindex on an already-synchronised node.
- Verification of activation heights and version bits against the real history of the chain.
- Verification of payload capacity and relayability for transactions carrying arbitrary data.
Running a node? We want to hear from you.
The census is the number that determines what is realistically possible. If you operate a masternode, one message from you is worth more than a month of announcements.