Developers

Use the network without touching the blockchain

Adoption has to be possible without direct ledger access. The service API handles authentication, rate limiting, transaction preparation, certificate issuance and verification — so your integration is an HTTP call, not a node deployment.

Endpoints Try the verifier Design requirements

Status: the API described on this page is the design specification for the LKS Notary MVP, currently in development under the funded plan. Endpoints and payloads are published early so that integrators can review and challenge them before they are frozen. They are not yet a production interface. See delivery status →

Service API

Endpoints

Notarisation Live

Base URL https://notary.lkschain.io. Writes need an X-API-Key; reads are public, because a proof only you can check is not a proof.

POST/api/v1/notarizeQueue a proof of existence for a hash — returns 202 and a certificate id
GET/api/v1/verify/{certificate}Full proof: canonical record, Merkle path, chain reference, Bitcoin attestation
GET/api/v1/lookup/{sha256}Every certificate issued for a document hash
GET/api/v1/batch/{batch}/otsDownload the OpenTimestamps attestation file
GET/healthService status

Identity & signatures Planned

POST/api/v1/identityCreate or update a decentralised identifier
POST/api/v1/signProduce a signature bound to an identity
POST/api/v1/attestationIssue a verifiable attestation

Traceability Planned

POST/api/v1/trace/lotRecord a lot event (create, transform, split, merge, ship, receive)
GET/api/v1/trace/lot/{lot_id}Retrieve lot state and chain of custody
Non-negotiable from day one

Four requirements that are not optional

These are not nice-to-haves scheduled for a later version. Each one, if deferred, silently breaks verification or duplicates cost in production.

Idempotency

Every write request accepts an idempotency key; repeating the same request never produces a second transaction. Without it, a network retry generates duplicate notarisations and duplicate fees.

POST /api/v1/notarize
Idempotency-Key: po-2026-00417

Deterministic canonicalisation

Structured data is normalised according to JCS (RFC 8785) before hashing. Otherwise a simple reordering of JSON keys makes verification impossible — and the failure only surfaces months later, in front of the party disputing the proof.

Declared, versioned hash algorithm

SHA-256 as the default, with a version field in the certificate so that future migrations do not invalidate proofs that already exist.

Immutable service-side audit log

Required to answer disputes about the behaviour of the service itself, and deliberately kept distinct from the on-chain proof. The two answer different questions.

End-to-end

A complete integration

The intended flow for an ERP recording a production lot, from creation to public verification.

The company creates lot LOT-2026-001 in its ERP

No change to existing business processes.

The ERP sends canonicalised data with an idempotency key

Only the canonicalised hash and minimal metadata leave the company's systems.

LKS computes the proof and prepares the transaction

Fees are handled by the service; the client is billed in euro.

The network validates; the ChainLock fixes finality

Once L2 is active, irreversibility is established within seconds.

TXID and timestamp are returned; the periodic root is anchored to Bitcoin

The .ots attestation is attached to the certificate when the anchor completes.

Transformations generate linked events

LOT-2026-001-A and -B each carry a proof pointing back to their parent.

Shipping and receipt are recorded

SHIP and RECEIVE events close the chain of custody.

The QR code exposes public verification

Only publishable fields are shown. In case of a recall, the genealogy identifies exactly which lots are affected.

# canonicalise (RFC 8785) then hash
POST /api/v1/trace/lot
Idempotency-Key: lot-2026-001-create
{
  "event": "CREATE",
  "lot_id": "01/09512345678901/10/2026-001",
  "product_code": "PRD-4417",
  "production_date": "2026-08-05T06:30:00Z",
  "quantity": 1200,
  "unit": "kg",
  "facility": "PLANT-02",
  "organization": "did:lks:8f2a…",
  "metadata_hash": "c41e…77b0"
}

# → response
{
  "certificate_id": "LKS-T-2026-1C77A0",
  "txid": "a19f…4d20",
  "chainlock": true,
  "anchor_ref": "lks-2026-08-05-04.ots",
  "verify_url": "https://…/v/LKS-T-2026-1C77A0"
}
Trust minimisation

The independent verifier

A tool that lets a third party validate a certificate without depending on the project's servers. It is the element that makes the entire architecture credible — and it is an explicit deliverable, not an aspiration.

  • Recomputes the content hash from the file you hold.
  • Walks the Merkle path from the leaf to the published root.
  • Checks the ledger reference and the ChainLock status.
  • Validates the .ots attestation against the Bitcoin blockchain.

If our servers disappeared tomorrow, every certificate already issued would still verify.

Planned SDKs

Client libraries for Python, JavaScript and PHP, plus ERP and MES integration adapters, belong to the extended roadmap and are labelled as strategic direction rather than a dated commitment.

The REST API and the independent verifier come first, because they are what make everything else replaceable.

Open items being worked through

Transaction format and payload capacity for proofs · timestamp handling and event ordering under ChainLocks · replay protection · enterprise authentication and key management · on-chain / off-chain separation · rate limiting and anti-spam · network fee coverage · explorer and public APIs realigned to the new codebase.

Challenge the design before it is frozen

If you integrate systems like this for a living, the most useful thing you can do right now is tell us where this specification breaks.

Send feedback Source & builds