Skip to content

Latest commit

 

History

History
287 lines (204 loc) · 11.7 KB

File metadata and controls

287 lines (204 loc) · 11.7 KB

Literary Protocol Specification

The 2,500 Donkeys — Sovereign Publishing Protocol Version: 1.0 Author: Kidd James Contract: 0x97f456300817eaE3B40E235857b856dfFE8bba90 (Polygon Mainnet) Status: Operational


1. Purpose

This document formalizes the 2,500 Donkeys protocol — a sovereign literary publishing system that provides cryptographic proof-of-origin, immutable content anchoring, and author-controlled versioning without intermediaries.

This is not a token standard. This is not a financial instrument. This is an infrastructure pattern for publishing literary works with verifiable provenance.


2. Asset Definitions

2.1 Asset Types

Asset Location Mutable Canonical
Manuscript blocks manuscript/*.md Yes (pre-anchor) Source of truth
Compiled manuscript dist/final-manuscript.md Derived Build output
SHA-256 hash web3/metadata/genesis.json Derived Integrity fingerprint
IPFS CID IPFS network No Content locator
On-chain edition LiteraryAnchor contract No Timestamp + proof
Build order build/order.json Yes (pre-anchor) Compilation sequence
Manifest dist/manifest.json Derived Per-file integrity map

2.2 Canonical vs. Derived

Canonical assets are source-of-truth files authored directly. They can be modified before an edition is anchored. Once anchored, the corresponding IPFS snapshot becomes the immutable record.

Derived assets are deterministically generated by the build pipeline. They must be reproducible from canonical inputs. If the same inputs produce different outputs, the pipeline is broken.

2.3 Mutability Rules

When Manuscript Build Output IPFS On-Chain
Before anchor ✅ Mutable ✅ Regenerated N/A N/A
After anchor ✅ Mutable (next edition) ✅ Regenerated ❌ Immutable ❌ Immutable

The manuscript source remains editable. Each edition anchor creates a permanent checkpoint. Previous checkpoints cannot be altered.


3. State Machine

Every edition progresses through a linear state sequence. No state can be skipped. No state can be reversed.

DRAFT → COMPILED → HASHED → PINNED → ANCHORED → PUBLISHED

3.1 State Definitions

State Description Artifacts
DRAFT Manuscript blocks are being written or edited manuscript/*.md
COMPILED Build pipeline has concatenated all blocks into a single manuscript dist/final-manuscript.md
HASHED SHA-256 fingerprint has been generated from the compiled output web3/metadata/genesis.json
PINNED Compiled output has been uploaded to IPFS and a CID assigned IPFS CID
ANCHORED CID + SHA-256 have been written to the on-chain contract Polygon transaction
PUBLISHED Edition is publicly accessible and verifiable Site, IPFS gateway, Polygonscan

3.2 State Transitions

Transition Trigger Actor Validation
DRAFT → COMPILED node build/compile.js Author / CI All blocks in order.json exist
COMPILED → HASHED node build/hash.js Author / CI dist/final-manuscript.md exists
HASHED → PINNED ipfs add -r dist/ Author IPFS daemon running
PINNED → ANCHORED anchorEdition(CID, SHA, note) Author wallet only Valid CID, valid SHA, onlyAuthor
ANCHORED → PUBLISHED Site deploy + verification Author Contract confirmed, site live

3.3 Transition Rules

  1. Forward only. States cannot be reversed. A compiled manuscript cannot be "un-compiled."
  2. Idempotent. Running a transition twice with the same inputs produces the same outputs (e.g., compile.js with identical source produces identical final-manuscript.md).
  3. Author-gated. The PINNED → ANCHORED transition requires the author wallet's private key. No other address can anchor editions.
  4. Version increment. Each complete cycle through all states creates a new edition. The previous edition's on-chain record remains unchanged.

4. Edition Lifecycle

4.1 Edition Structure (On-Chain)

struct Edition {
    string ipfsCID;       // Content locator (IPFS)
    string sha256Hash;    // Content fingerprint
    uint256 timestamp;    // Block timestamp (Polygon)
    string title;         // Work title
    string note;          // Edition description
}

4.2 Edition Rules

Rule Description
Genesis is immutable editions[0] is set in the constructor and cannot be modified
Editions are append-only New editions push to the array; no deletion or overwrite
Author-only anchoring The onlyAuthor modifier restricts anchorEdition() to the deployer
No empty editions CID and SHA-256 must be non-empty strings
Sequential indexing Edition indices are sequential (0, 1, 2, ...)

4.3 Edition History

LiteraryAnchor (0x97f4...b890)

Index Edition CID Status
0 Genesis (novel) QmVQ79NM3qxAsBpftTG4YhD4KV9sUEmM3WwFrc5vs5g8vK Immutable
1–3 Edition 2 — novel (nonce recovery duplicates) QmPXtEsRwiWuaKmKNA569XAqFNVySN8pwTdGQrvcdpgtMa Immutable
4 Edition 3 — placeholder (pending-ipfs-pin) pending-ipfs-pin Immutable (superseded)
5 Edition 4 — Private Placement Puppetry QmahPEAZuWz3dFa55BsNgBEkjBzvWm5M3xbGaRYwm581LV Immutable

PublishingKernelV2 (0xca9F...C037)

ID Edition Manuscript Root Status
0 Novel (canonical) dd95d121... Canonical
1 Placeholder (pending-ipfs-pin) pending-ipfs-pin Superseded
2 Private Placement Puppetry a73efc2a... Frozen

5. Roles

5.1 Protocol Roles

Role Identity Permissions
Author 0xC91668184736BF75C4ecE37473D694efb2A43978 Write manuscript, run build, anchor editions, deploy site
Reader Any address Read on-chain data, verify CIDs, fetch from IPFS
Verifier Any address Compare SHA-256 against IPFS content, audit on-chain state
Contract 0x97f456300817eaE3B40E235857b856dfFE8bba90 Store editions, enforce onlyAuthor, emit events

5.2 Role Boundaries

  • Only the Author can anchor editions on-chain.
  • Only the Author can modify manuscript source files.
  • Anyone can verify the integrity chain (SHA-256 ↔ IPFS ↔ contract).
  • No one can modify an anchored edition.
  • No one can transfer authorship (the author address is immutable).

6. Build Pipeline

6.1 Pipeline Stages

manuscript/*.md + artifacts/*.md
        │
        ▼
   compile.js (order.json)
        │
        ▼
  dist/final-manuscript.md
        │
        ▼
     hash.js
        │
        ▼
  web3/metadata/genesis.json (SHA-256 + MD5)
        │
        ▼
   manifest.js
        │
        ▼
  dist/manifest.json (per-file hashes)

6.2 Determinism Guarantee

The build pipeline is deterministic: identical source files, in identical order, produce byte-identical output. This is verified by:

  1. compile.js reads from order.json — explicit, ordered file list
  2. hash.js computes SHA-256 of the compiled output — any byte change invalidates the hash
  3. manifest.js computes per-file hashes — detects individual file mutations

6.3 Verification Procedure

To verify any edition:

# 1. Fetch from IPFS
ipfs get <CID>

# 2. Compute SHA-256
sha256sum dist/final-manuscript.md

# 3. Compare against on-chain hash
# Read from: editions[n].sha256Hash on Polygonscan

# 4. If match → content is authentic and unmodified
# If mismatch → content has been tampered with or CID is wrong

7. Failure Modes

Failure Impact Mitigation
IPFS pin dropped Content inaccessible (but hash still on-chain) Re-pin from local copy; CID is deterministic
Polygon RPC down Cannot read/write contract Multi-RPC fallback (ankr, publicnode, 1rpc, llamarpc)
Private key compromise Unauthorized editions could be anchored Verify edition authenticity via SHA-256 of known content
Build pipeline mutation Different hash for same content Source-control the pipeline; hash.js validates against genesis.json
Git history rewrite Authorship timeline disputed On-chain timestamps are independent of git
Domain expiry Site inaccessible Content still on IPFS + on-chain; site is convenience layer

7.1 Recovery Procedures

Lost IPFS pin: The CID is derived from content. If you have the original files, ipfs add -r dist/ will produce the same CID. Re-pin to any IPFS node.

Wrong edition anchored: Editions are append-only. Anchor the correct edition as the next entry. Add a note explaining the correction. Previous entries cannot be deleted but the latest() view function returns the most recent.

Contract compromise: Authorship is immutable (address public immutable author). No function exists to transfer ownership. The only risk is private key exposure allowing unauthorized anchorEdition calls. Mitigate by verifying SHA-256 matches known content.


8. Governance

8.1 Upgrade Strategy

The LiteraryAnchor contract is not upgradeable. This is intentional. The contract's simplicity is its security — there are no admin functions, no proxy patterns, no delegate calls.

If the protocol requires new functionality (e.g., NFT editions, access control), new contracts are deployed alongside the anchor. The anchor remains the canonical proof-of-origin.

8.2 Versioning Policy

Component Versioning Breaking Changes
Manuscript Edition numbers (1, 2, 3...) New edition = new anchor
Protocol spec Semantic (1.0, 1.1, 2.0) Major = state machine change
Build pipeline Tracked in git Same inputs must produce same outputs
Smart contract Immutable (no versioning) Deploy new contract if needed
Site Continuous deployment No versioning required

8.3 Decision Authority

All protocol decisions are made by the Author. There is no DAO, no governance token, no committee. This is sovereign publishing — one author, one wallet, one contract.


9. Security Considerations

9.1 Threat Model

Threat Vector Protection
Content plagiarism Copy manuscript On-chain timestamp proves priority
Hash collision Forge content with same SHA-256 Computationally infeasible (2^256)
IPFS content poisoning Serve wrong content for CID Impossible — CID is content hash
Contract takeover Call anchorEdition as non-author onlyAuthor modifier + immutable author
Front-running Anchor someone else's content first Author controls private key; content is private until published

9.2 What This Protocol Does Not Protect Against

  • Loss of the author's private key (no recovery mechanism)
  • Legal disputes over real-world copyright (blockchain is evidence, not adjudication)
  • Content quality (the protocol anchors content; it does not evaluate it)
  • IPFS availability (content-addressed, but requires at least one pin)

10. Economic Disclaimers

This protocol produces no tokens, no yield, no revenue sharing, and no investment returns.

  • Editions are literary records, not financial instruments.
  • Any future NFTs are collectibles — art and literature, not securities.
  • The protocol is open infrastructure; adoption does not create obligations.
  • No individual or entity is promised financial returns from this system.

Protocol formalized: February 2026 Contract deployed: Block 83,002,198 (Polygon) Author: Kidd James