LPS-1 · OPEN STANDARD FOR DETERMINISTIC PROVENANCELIVE STATEVERIFYINSIGHTSMACHINE-READABLEEVIDENCE LEDGEROperated by UnyKorn LLC
UNYKORNCLIPS · SATIRE · SPORTS · OFFERS · LAUNCH

XXXIII

Open Standard for Deterministic Digital Provenance

Deployed live on Polygon Mainnet. Independently verifiable. MIT licensed.

SHA-256 content hashing at word, paragraph, and chapter level.

Merkle tree commitments per edition with on-chain root anchoring.

Forward-only lifecycle. Zero upgradeability. Client-side verification.

View Protocol Enter Library Verify in 90s

2026 · Polygon Mainnet · Chain ID 137

SPECIFICATION REFERENCE IMPLEMENTATION
Solidity 0.8.19 Hardhat OpenZeppelin Deterministic Build MIT
unavailable Editions Anchored on-chain
7 Contracts Verified
6 Merkle Trees
293Suite tests (self-reported)
58Ref. impl. tests passing
unavailable Blocks Since Genesis on-chain
L5 Compliance Level
📄LPS-1 Spec Compliance L0–L5 Governance 🗺Roadmap 📢Announcement 🏛Funding Brief

Why This Is a Standard

XII

On-Chain State

Direct read-only RPC observation of deployed contracts. No intermediary services.

Chain state could not be read at the edge just now. This is a transport failure, not a change in on-chain state; verify directly on Polygonscan.

Polygon Mainnet Chain ID 137 Block — RPC: read at the edge with failover
Literary Anchor
Editionsunavailable
Latest Hashunavailable
Latest CIDunavailable
Anchor Timeunavailable
Publishing Kernel V2
Editionsunavailable
Canonicalunavailable
Frozenunavailable
Edition Rootunavailable
Author Identity
Nameunavailable
Pseudonymunavailable
Worksunavailable
Linked Contractsunavailable
NFT Layer
EditionNFT Supplyunavailable
StoryNFT Supplyunavailable
Royalty Routerunavailable

Recent On-Chain Events

Loading events…
XVIII

Compliance Levels

Progressive implementation tiers for protocol conformance.

0 Anchor Only SHA-256 hash stored on any public blockchain
1 Deterministic Build CRLF normalisation + reproducible canonical hash
2 Merkle Provenance Per-content-type Merkle trees + combined edition root
3 On-Chain Anchoring Immutable blockchain record binding edition root to block timestamp
4 Signed Canonical Root ECDSA identity binding + on-chain author registry
5 Fully Observable Cross-chain timestamp + client-side verification
LPS-1 Level 5 — Fully Observable

XXXIII reference implementation. 7 verified contracts. Cross-chain anchoring via Polygon + Bitcoin (OpenTimestamps). Client-side on-chain state verification. 293 tests passing.

View Compliance Matrix
XIV

Verify It Yourself

Drop compiled-manuscript.md

SHA-256 computed locally. Nothing leaves your machine.

Clone. Run. Confirm.

git clone https://github.com/FTHTrading/LPS-1-Reference-Implementation.git
cd LPS-1-Reference-Implementation && npm install
node verifier/cli.js --path example-work

58 checks across 2 suites. All must pass.

This is not trust. This is reproducibility.

Public Reference Implementation

Clone · Test · Deploy locally · Verify independently

git clone https://github.com/FTHTrading/LPS-1-Reference-Implementation.git
cd LPS-1-Reference-Implementation
npm install
npm run demo
node verifier/cli.js --path example-work
58 Tests Passing (npx hardhat test, 2026-09-09) Deterministic Build Verified
View on GitHub
VI

LPS Protocol Stack

Six layers. Each independently specified, implementable, and verifiable.

VIObservabilityClient-side chain reads, event timeline, status indicators
VComplianceLevel 0–5 conformance matrix, self-assessment, certification
IVDistributionEditionNFT, StoryNFT, RoyaltyRouter (ERC-721 + ERC-2981)
IIIAudio LayerIAPL-1 — Immutable Audio Publishing Layer
IICore ProtocolLPS-1 — SHA-256, Merkle trees, edition lifecycle, on-chain anchor
IInfrastructurePolygon Mainnet, IPFS, OpenTimestamps, Git provenance
LPS-NFTToken distribution layer (ERC-721 + ERC-2981)
VII

Cinematic Media Vault & 3D Assets

4K desert donkey drama storyboard captures, hyperreal 3D crypto currency models, and cryptographic manuscript plates anchored to Polygon Mainnet.

Level 5 Observable Proof 11 4K Cinema Clips 7 3D Token Models 16 Manuscript Plates
4K MP4

The Desert Caravan

2,500 donkeys moving through the desert corridor carrying gold bars while paperwork certifies delivery.

✓ Block 04 Genesis View 4K →
Storyboard

Desert Drama Storyboard

Cinematic motion study of the desert crossing under burning sun. The trail thins as attrition rises.

✓ Block 05b View 4K →
3D Bitcoin Asset

Bitcoin 3D Asset

UNREAL / OCTANE 3D MODEL

Hyperreal precision-milled gold coin forged as game-grade 3D engine asset for the Crypto War Room.

Crypto War Room Listen Track #48 →
3D Solana Asset

Solana High-Velocity

3D MODEL · METALLIC LUSTER

Electric gradient reflection with milled edges, representing ultra-fast high-frequency settlement liquidity.

Crypto War Room Listen Track #55 →
3D USDF Dollar Asset

USDF self-governing Dollar

BANK-GRADE INFRASTRUCTURE

Machined circular steel & gold self-governing digital dollar engineered for institutional custodial settlement.

Institutional RWA Listen Track #58 →
Master Cover

The 2,500 Donkeys

Canonical front cover artwork by Kidd James. Frozen Merkle tree root anchored on Polygon Mainnet.

✓ DOI Zenodo Read Book →
Enter Full Media Vault (34 Assets) →
X

Reference Implementations

Each edition is a protocol test vector — a complete, frozen deployment of the LPS-1 standard.

Reference Implementation A

The 2,500 Donkeys

Edition II FROZEN
31 chapters 75,000+ words 36 audio files 6 Merkle trees 293 suite tests (self-reported)58 ref. impl. tests passing
Edition6719ed7f...594e
Manuscriptdd95d121...67d3
Artifact9c653a2e...2c56
Image0e45331c...c638
Prompt32bed9e5...f32c
Audioe57bb947...30fa
Audio Ed.514c2db5...501e
Reference Implementation B

Private Placement Programs

Edition I FROZEN
14 stories 17 audio files 3 transactions 3 Merkle roots
Manuscript43c24c29...90c6
Audiob57afe2a...0151
Audio Ed.a6c597fc...ab62
Combinedf5f0358b...df0f
Reference Implementation C

Crypto War Room

Volume III FROZEN
15 stories AI audio 15 chain blocks Polygon anchored
Genesis Hash3a9e2270...4412
Block 01de3a8f99...1891
Audio Root8f1bca77...1822
XVII

Protocol Stewardship

Authorship, stated once. The on-chain AuthorIdentity contract (0xB9ffa688…323170, getIdentity()) records real name Kevan Burns and pseudonym Kidd James. The DOI, ORCID and citation carry the real name; the works and the on-chain record carry the pseudonym. They are the same person, and a verifier can read both fields from the contract without trusting this page.

Protocol Author Kidd James (pseudonym of Kevan Burns)
Specification Steward XXXIII Working Group
Reference Implementation FTHTrading
Security Review Internal review; no external audit (as of 2026-09-09)
XXIII

Implementation Roadmap

Six phases from deterministic anchor to multi-implementation adoption.

I Deterministic Anchor SHA-256 hashing, Merkle trees, Polygon anchoring, LPS-1 specification. Complete.
II Multi-Author Support Co-author identity binding, shared edition governance, delegation support.
III Ethereum L1 Mirror Cross-chain anchor standard (LPS-2), settlement-layer finality.
IV zk-Proof Inclusion Zero-knowledge Merkle inclusion proofs for privacy-preserving verification.
V Institutional API REST verification endpoints for libraries, archives, and publishers.
VI Multi-Implementation Three+ independent implementations, governance transition to working group.

Become an Implementor

LPS-1 is designed for multi-implementation adoption. Level 0 requires a single SHA-256 anchor. Level 5 provides full observability.

1 Choose Compliance Level

Select L0 (anchor only) through L5 (fully observable) based on your requirements.

View Compliance Matrix →
2 Clone Reference Implementation

Fork the public repo. All contracts, tests, and pipeline code are MIT-licensed.

GitHub Repository →
3 Run the Verifier

Execute the 58-test verification suite against your deployment to confirm determinism.

npx hardhat test
4 Deploy Your Anchor

Deploy your own LiteraryAnchor contract to any EVM chain. Minimal Hardhat config included.

npx hardhat run scripts/deploy.js --network polygon
5 Submit Conformance Statement

Open a GitHub issue with your deployment address, chain ID, and compliance level achieved.

Submit Statement →

Implementation Registry

XXXIII Level 5 — Fully Observable Polygon Mainnet Production
Your Implementation Any Level (L0–L5) Any EVM Chain Open Slot

LPS-1 satisfies eligibility criteria for public goods funding through:

Open-source MIT licensing Deterministic reproducibility Cross-chain timestamping Independent verifiability Governance transition criteria

The reference implementation is production-deployed and independently verifiable today.

Deep Protocol

Technical specification, architecture, and formal definitions.

I

Abstract

This document describes a deterministic literary publishing protocol that establishes cryptographic proof-of-origin, content integrity, and immutable anchoring across decentralized storage and public blockchains.

The protocol formalizes a forward-only edition lifecycle, Merkle-based provenance commitments, and independently verifiable build determinism.

Reference implementation deployed on Polygon Mainnet.

II

Definitions

Canonical Manuscript
The CRLF-normalized, UTF-8 encoded source file whose SHA-256 hash constitutes the authoritative content fingerprint.
Edition
A frozen, versioned snapshot of a literary work comprising manuscript, artifacts, images, and prompt logs, identified by a unique edition root.
Edition Root
SHA-256 hash derived from the concatenation of four independent Merkle roots: manuscriptRoot + artifactRoot + imageRoot + promptRoot.
Anchor
An immutable on-chain record binding an edition root and IPFS CID to a specific block number and timestamp on a public blockchain.
Terminal State
A state from which no further forward transitions are possible. Terminal states preserve all historical data. Defined states: SUPERSEDED, RETRACTED.
Determinism
The property that identical inputs always produce identical outputs. Achieved through canonical ordering, CRLF normalization, and fixed concatenation sequences.
Supersession
The process by which a newer edition replaces an older edition as canonical. The superseded edition remains on-chain but is marked non-canonical.
III

Not DRM.

This system does not restrict access.
It proves origin.

Anyone may read.
Anyone may verify.

No intermediary. No trust required. Just math.

IV

Core Guarantees

G1

Origin Guarantee

SHA-256 canonical hash establishes authorship at byte-level precision.

Canonical 9d062421b52d35aa23b73bfc8f66574db78bad9726e45c43a12d0109cdd57d84
G2

Integrity Guarantee

IV independent Merkle trees combine into a single Edition Root.

Edition Root 6719ed7f9e142a39a4a7db533895562bdf5379cf7f9816ed7cbe045ca359594e
Audio Root 514c2db5b9cd914b96a0a8b50d9dd6981a454c74cab7d717dc38f5fe9fa0501e
G3

Permanence Guarantee

IPFS content addressing + Polygon on-chain anchor. Immutable by design.

Edition II CID QmPXtEsRwiWuaKmKNA569XAqFNVySN8pwTdGQrvcdpgtMa
Genesis CID QmVQ79NM3qxAsBpftTG4YhD4KV9sUEmM3WwFrc5vs5g8vK
V

The Protocol Layer

A five-layer provenance stack. Each layer independently verifiable.

IFilesystemSource files, canonical ordering, version control
IIGitCommit history, authorship timestamps, diffs
IIISHA-256FIPS 180-4 cryptographic fingerprint, CRLF-normalized
IVMerkle TreesFour independent roots combined into edition root
VIPFSContent-addressed decentralized storage
VIPolygonImmutable on-chain anchor, block-level timestamp
VII

The Pipeline

A deterministic sequence from manuscript to chain.

I Manuscript 293,368 bytes
II SHA-256 Deterministic hash
III Merkle IV Independent roots
IV Edition Root Combined root hash
V IPFS Content-addressed
VI Polygon On-chain anchor
Filecompiled-manuscript.md
Size293,368 bytes
AlgorithmSHA-256
Hash9d062421...cdd57d84
Manuscriptdd95d121...487467d3
Artifact9c653a2e...24202c56
Image0e45331c...c56c638
Prompt32bed9e5...6674f32c
Edition Root6719ed7f...ca359594e
Audio Edition514c2db5...9fa0501e
NetworkPolygon Mainnet — Chain ID 137

No randomness. No mutable state. Reproducible by anyone.

VIII

Merkle Architecture

Four independent trees converge into a single edition root.

Manuscript dd95d121...67d3
Artifact 9c653a2e...2c56
Image 0e45331c...c638
Prompt 32bed9e5...f32c
Edition Root 6719ed7f...594e

editionRoot = SHA-256( manuscriptRoot + artifactRoot + imageRoot + promptRoot )

IX

Edition State Machine

The edition lifecycle is modeled as a monotonic finite-state machine. All transitions are irreversible. All terminal states preserve historical data.

DRAFT
COMPILED
HASHED
MERKLE_BUILT
PINNED
ANCHORED
PUBLISHED
From PUBLISHED
SUPERSEDED
Non-canonical. Replaced by newer edition.
From PUBLISHED
RETRACTED
Author-initiated withdrawal. 48h timelock.

State transitions are irreversible. Data is preserved in all terminal states.

XI

The Contract Architecture

7 contracts deployed. Source verified.

Literary Anchor

Block83,002,198
Gas1,116,006
StatusVerified

Publishing Kernel V2

Block83,010,944
Gas4,804,013
StatusVerified · Ed#0 FROZEN · Ed#1 FROZEN

Publishing Kernel

Block83,008,833
StatusVerified

Royalty Router

StatusVerified · Revenue Test PASS

Author Identity

Block83,011,553
StatusVerified · Kidd James · FTH Trading

Edition NFT

Block83,110,065
Gas2,526,271
StatusVerified · DONKEY · 3 Tiers · ERC-721 + ERC-2981

Story NFT

Block83,110,129
Gas3,059,578
StatusVerified · STORY · 14 Stories · ERC-721 + ERC-2981
XIII

System Invariants

Verifiable guarantees that hold at every layer of the protocol.

Content Invariants

Identical source files always produce identical SHA-256 hashes. CRLF normalization eliminates platform-dependent line endings. UTF-8 with no BOM. Canonical file ordering via order.json.

Contract Invariants

Non-upgradeable. Author-only anchoring. Append-only edition history. Frozen editions are permanently sealed. No admin backdoors. Pull-based withdrawals.

Pipeline Invariants

Deterministic file ordering. Odd-leaf duplication for balanced Merkle trees. Fixed concatenation order for edition root. No randomness. No mutable state.

Provenance Alignment

Every on-chain record maps to exactly one IPFS CID and one edition root. Every edition root maps to exactly four Merkle roots. Every root maps to a deterministic file hash tree.

XV

Cross-Chain Anchoring

Polygon ✓ Active 7 contracts deployed, source verified
Bitcoin ✓ OpenTimestamps Merkle root timestamped via BTC
Ethereum Planned L1 anchor under evaluation
XVI

Why This Matters

Prevent silent revision

Once anchored, no party can alter content without detection. Every byte is hashed and tree-committed.

Eliminate provenance disputes

Block-level timestamps and ECDSA signatures establish authorship with cryptographic certainty.

Enable AI disclosure verification

Prompt logs are Merkle-rooted alongside manuscripts, creating verifiable AI usage records.

Support independent verification

Any third party can reconstruct hashes, trees, and roots from source files alone. No platform dependency.

Reduce institutional trust dependency

Verification is mathematical, not reputational. The protocol replaces trust with reproducibility.

XIX

Related Work

XX

Security Considerations

Hash Collision Resistance

All content fingerprinting uses SHA-256 (FIPS 180-4). The protocol's integrity guarantees depend on SHA-256's collision resistance. No known practical collision attack exists against SHA-256 as of this writing.

Author Key Custody

All anchoring and minting operations require the author's private key. Key compromise permits unauthorized anchoring. Key loss is non-recoverable. The trust model is self-self-governing: no recovery mechanism exists by design.

IPFS Availability

IPFS provides content addressing, not availability guarantees. Content must be actively pinned. CID immutability ensures integrity independent of availability. Loss of all pin providers does not affect on-chain anchor validity.

RPC Observation Integrity

Client-side chain reads depend on public RPC endpoint honesty. Verification across multiple independent RPC providers mitigates eclipse attacks. All displayed state is independently reproducible via Polygonscan.

Non-Upgradeable Contracts

No proxy pattern. No admin keys. No governance multisig. Contract behavior is fixed at deployment. This eliminates upgrade-path attacks at the cost of post-deployment mutability. This is an intentional design constraint.

XXI

Limitations

Does not protect accrued royalties from key loss. RoyaltyRouter uses pull-based withdrawals by the author key; if that key is lost, funds already accrued in the router are permanently stranded, in addition to future anchoring being impossible.

Does not prevent copyright disputes. The protocol proves temporal priority of anchoring, not legal ownership.

Does not guarantee IPFS availability. Content addressing ensures integrity but not persistence without active pinning.

Does not prevent private key loss. Self-self-governing identity has no recovery mechanism by design.

Does not enforce content quality. The protocol is agnostic to the literary merit of anchored works.

Does not provide offline verification. On-chain state observation requires network access to an RPC endpoint.

XXII

Implementation Status

Specification StatusInformational
Reference ImplementationProduction — GitHub
NetworkPolygon Mainnet (Chain ID 137)
Contracts VerifiedYes — 7 / 7
UpgradeabilityNone
Test Coverage293 tests across 7 suites
Ref. Impl. Tests58 tests (37 contract + 21 pipeline)
Conformance LevelLevel 5 — Fully Observable
LicenseMIT (infrastructure) · CC BY 4.0 (paper)
XXV

Insights

Why deterministic provenance matters, and how to check every claim on this page yourself. Read in place, or open each piece.

Why provenance has to be deterministic

Every published text now travels through a dozen hands and programs before a reader sees it. Somewhere on that path a sentence changes, and nobody can say when. When a dispute arrives, the only evidence is a screenshot and a memory.

LPS-1 answers this with a procedure, not a promise. The work is canonicalised so that line endings, invisible marks and file order cannot change its fingerprint. Every file is hashed with SHA-256. The hashes are organised into Merkle trees by content type, and the four roots are combined into one edition root. That root is written to a public chain with a block timestamp and cross-stamped to Bitcoin through OpenTimestamps.

The word that matters is deterministic. Two honest people on two different computers must get the same root from the same files, or the whole idea collapses into argument. The reference implementation ships the normalisation rules and the tests that prove them, and this site reads the anchored roots straight from the chain so you can compare.

What it does not do is just as important. It does not decide who owns a work; it proves who anchored it first and that it has not changed since. It does not keep a file available; it makes any copy checkable. It does not stop copying; it makes plagiarism provable.

Open this insight with its questions and citations

How to verify an LPS-1 edition without trusting anyone

The thirty-second way: open the JSON at /api/state. Every value carries the command that produced it. Paste the command into a terminal and you are asking Polygon directly, not us.

The two-minute way: open Polygonscan at any of the seven contract addresses, choose Read Contract, and call editionCount, latest and getIdentity. Polygonscan is independent of this site. If its answers match the page, the page is honest.

The five-minute way: clone FTHTrading/LPS-1-Reference-Implementation, run npm install, then node verifier/cli.js --path example-work. The verifier rebuilds the hashes and Merkle roots from the files and compares them with the chain. On 2026-09-09 the contract suite passed 58 tests and the pipeline suite 21 on our machine; the commands are in the evidence ledger.

There is also a free endpoint: GET /v1/verify/{editionRoot|sha256|cid}. It reads KernelV2.isAnchored and walks the kernel's editions to tell you whether your hash, root or CID is anchored, which edition it belongs to, and when.

Open this insight with its questions and citations

What key loss means on a non-upgradeable contract

The seven LPS-1 contracts are not upgradeable. There is no proxy and no administrator who can swap the code. That is why the rules cannot change after the fact, and why a mistake cannot be patched after the fact either.

Key loss is therefore final. The security section of the standard says so for anchoring: lose the author key and no further editions can be anchored. There is a second consequence that a buyer of an edition token should see. RoyaltyRouter pays out by pull-based withdrawal: funds accrue in the contract until the author key withdraws them. If that key is lost, whatever has accrued is permanently stranded. The router has received and withdrawn 0.01 POL to date and holds a zero balance, so the exposure today is small, and the page now states the consequence in its Limitations.

What the design gives in return is a record nobody can quietly edit, including the people who wrote it. For a provenance standard, that trade is the point.

Open this insight with its questions and citations

AI disclosure you can check: prompt logs as Merkle leaves

Publishers are being asked whether a model was involved in a work and how. The usual answer is a line of front matter. LPS-1 gives a better one: when a model is used, the prompts are hashed into their own Merkle tree, and that prompt root is one of the four roots inside the edition root. The edition also records the model name and a hash of the prompt set.

The disclosure becomes a commitment. If someone later claims the prompts were different, or that no model was used, the root will not match. A human-only edition has an empty prompt tree and says so. A model-assisted edition has a prompt tree and says so. Either way, a reader can know, and can check.

This is the same discipline UnyKorn applies to its own reporting: every figure in the annual report family resolves to a ledger row with the command that produced it. A disclosure you cannot check is a sentence. A disclosure you can check is evidence.

Open this insight with its questions and citations

Who operates this site

OperatorUnyKorn LLC, a Wyoming limited liability company, formed 2026-07-01, filing 2026-002019968 (Wyoming Secretary of State business filing search). Managing Member: Kevan Burns.
AddressRegistered in Wyoming, United States. A verified office and mailing address is published the moment the founder confirms it; until then none is printed.
TrustEvery figure on this site resolves to a row in the public evidence ledger; the chain reads carry their commands; security.txt, llms.txt and lps1.json are published; our commitments.
PerimeterUnyKorn LLC is a technology and administration service provider. It is not a bank, broker-dealer, exchange, custodian, trustee, transfer agent, appraiser, auditor, investment adviser, money transmitter, or issuer.
XXIV

Citation

Deterministic Literary Publishing:
A Multi-Layer Provenance Model for Verifiable Manuscripts

Working Paper · Published February 15, 2026 · Version 1.0 · Open Access

APA
Burns, K. (2026). Deterministic Literary Publishing:
A Multi-Layer Provenance Model for Verifiable
Manuscripts (1.0). Zenodo.
https://doi.org/10.5281/zenodo.18646886
BibTeX
@techreport{burns2026deterministic,
  title     = {Deterministic Literary Publishing: A Multi-Layer
               Provenance Model for Verifiable Manuscripts},
  author    = {Burns, Kevan},
  year      = {2026},
  month     = feb,
  publisher = {Zenodo},
  version   = {1.0},
  doi       = {10.5281/zenodo.18646886},
  url       = {https://doi.org/10.5281/zenodo.18646886},
  license   = {CC-BY-4.0},
  note      = {Working paper. Reference implementation
               deployed on Polygon mainnet.}
}

Independent research. Indexed in OpenAIRE. Reference implementation deployed on Polygon mainnet.

digital provenance · deterministic publishing · Merkle trees · content integrity · reproducible pipelines · literary technology · on-chain anchoring · IPFS · smart contracts · cryptographic verification