Two lists, kept strictly separate
What is funded, dated and committed, and what is strategic direction. Mixing the two is how roadmaps stop meaning anything. Everything in the first list has budget coverage and a publicly verifiable deliverable.
The funded plan
Four phases, each with a deliverable that can be checked from outside the project. Phase D runs in parallel with Phase C, because it does not touch consensus and produces something demonstrable while the migration proceeds.
Phase A — Consensus validation
Under wayProve that the updated binary is a transparent replacement under the consensus rules currently in force. Continuous tip comparison against legacy nodes with automated alerting, masternode list and payment consistency, log analysis, full sync from genesis and full reindex. Sporks remain untouched.
Public deliverable: test report and monitoring scripts.
Phase B — Public testnet and operator census
NextPublication of the repository, the CI and reproducible builds for Linux and Windows. A public testnet open to operators with a step-by-step migration guide. Sizing and testing of LLMQ parameters at the real scale of the network, with measurement of the DKG completion rate. And the number that governs everything else: how many operators are actually reachable, and how many distinct operators exist.
Public deliverable: testnet, documentation, and the measured operator count.
Phase C — DIP-3 migration
ThenSupporting operators through the transition to the deterministic masternode list, with a long migration window, a declared grace period, assisted migration tooling, staffed support channels and direct contact with every operator identified in the census. Activation only once the adoption threshold is reached.
Public deliverable: migrated network with ChainLocks active.
Phase D — LKS Notary MVP
In parallel with Phase CThe notarize and verify endpoints with idempotency and JCS canonicalisation; certificate IDs and a public verification page; QR codes; Merkle aggregation and OpenTimestamps anchoring to Bitcoin, with the .ots file distributed alongside the certificate; and an independent verifier allowing a third party to validate a certificate without depending on our servers.
Public deliverable: a working, independently verifiable service.
Budget allocation
| Phase | Share |
|---|---|
| A — Consensus validation | 15% |
| B — Testnet, builds, migration guide, census | 25% |
| C — DIP-3 migration support and activation | 25% |
| D — Notary MVP, anchoring, verification page | 25% |
| Contingency reserve | 10% |
Allocation constraint
Zero budget is allocated to marketing, site restyling or graphic materials. At this funding level, every euro not spent on code and infrastructure is a euro spent badly.
Visibility is earned by publishing real progress — a public repository, green CI, reproducible builds and a technical note every two weeks, including the ones reporting that something did not work.
Beyond the funded plan
The phases below describe where the project is heading. They have neither budget coverage nor dates, and they are stated as direction rather than as commitment. They will move into the funded list only when both exist.
Phase E — LKS Trace MVP
DirectionA GS1-aligned lot and event model; CREATE / UPDATE / TRANSFORM / SPLIT / MERGE / SHIP / RECEIVE events; chain of custody; REST API; lot QR codes; verification dashboard. To be started alongside a real industrial pilot, not after one.
Phase F — Identity & Proof
DirectionDID-based identity, verifiable credentials, signatures, attestations, content versioning and anchoring of C2PA manifests.
Phase G — Ecosystem
DirectionSDKs for Python, JavaScript and PHP; ERP and MES integrations; optional decentralised storage; oracle services; opening of governance.
The indicators we hold ourselves to
Technical activity metrics are the easy ones. They are paired here with migration and business indicators, because those are the ones that determine whether the project survives.
Network & migration
- Share of masternodes migrated to DIP-3, by collateral
- Distinct operators reached and responsive
- Successful DKG rate and quorums formed
- Tip divergences between updated and legacy nodes — target: zero
- Observed vs expected payment rate on updated nodes
- Share of blocks covered by a valid ChainLock
Product
- Number of notarisations and public verifications
- Average time to confirmation and to anchoring
- Service availability of the API
- Verifications performed with the independent verifier
Business
- Paying organisations and recurring revenue
- Average onboarding time for a new client
- 12-month retention
- Cost per certification vs the qualified alternative
- Donations raised and share publicly accounted for
Demand from usage, not from speculation
The economic objective is not to increase speculative demand for the token. It is to create demand tied to actual use of the services: notarisations, certificates, verifications, supply-chain events, API calls and enterprise contracts.
B2B services are priced and invoiced in euro, under an ordinary commercial contract. No corporate purchasing function is going to buy and hold a token in order to notarise a delivery note; requiring it loses the client during procurement, before the technical evaluation even begins.
The token remains relevant as an internal settlement instrument and as the incentive for masternode operators: the service acquires LKS on the market to cover network fees, which generates real demand proportional to usage. The economic link exists — it is simply not the client's problem.
Regulatory perimeter
If a token is promoted or distributed with a narrative tying its value to the adoption of the services, it may fall within the perimeter of the European regulation on crypto-assets, with associated documentation and notification obligations.
That determination is made and legally verified before commercial launch, not after. Pricing in euro is part of that decision, not a marketing preference.
Nothing on this page is an offer to sell, or a solicitation to purchase, any asset — nor is it investment advice. Descriptions of unreleased functionality are statements of intent, not of current capability.
Immediate next steps
- Complete Phase A on the updated masternodes, with a control group and automated tip monitoring.
- Run a full sync from genesis and a full reindex with the new binary.
- Verify protocol version, Sentinel compatibility and arbitrary-payload capacity.
- Publish the repository, the CI and a technical note on the codebase modernisation.
- Open the operator census and form the technical working group.
- Publish the first treasury statement.
- Open the public testnet and size the LLMQ parameters.
- Build the Notary MVP with OpenTimestamps anchoring.
- Ship the independent verifier alongside it.
- Identify a candidate for the industrial pilot, to run in parallel with Phase E.
Every two weeks, whatever the result
Regularity is the signal. If a phase slips, that gets published too.