Literary works exist in a fragmented ecosystem. A writer might publish on Medium, archive on GitHub, store locally, and share across social platforms. Establishing a canonical record of "what was written when" becomes difficult. Traditional approaches rely on centralized platforms that can change, disappear, or revise history.

Blockchain offers a solution: immutable, timestamped records maintained by a decentralized network. However, most blockchain implementations treat data as monolithic—once written, it cannot be updated, corrected, or versioned.

For literary curation, this is insufficient. Writers make corrections. Editors revise passages. New editions emerge. A system needs to:

1. Allow updates without destroying the original record

2. Track which version is current

3. Maintain complete history for audit purposes

4. Optionally verify content authenticity

5. Integrate with emerging digital economies (NFTs)

The new version of our Lit3 Ledger addresses these requirements while maintaining simplicity for non-technical users.

The initial prototype, PlexusArchive, provided basic functionality:

struct Shard {
    string shardTag;
    string echoSource;
    string earthTime;
    string lankaTime;
    string archivistLog;
}

This worked for append-only archives but lacked sophisticated curation tools. Once archived, an entry could not be updated—errors required creating duplicate entries or redeploying contracts.

• Immutability-only approach: Entries were frozen upon creation

• Limited metadata: No versioning, no content verification, no external integrations

• Narrative-centric terminology: Field names like "echoSource" and "archivistLog" were evocative but domain-specific, limiting discoverability

Our latest version of the Lit3Ledger extends the original with four critical additions:

struct Entry {
    // ... previous fields ...
    bool deprecated;
    uint256 versionIndex;
}

When a curator creates an updated entry using archiveUpdatedEntry():

• The old entry is marked deprecated = true

• The new entry receives versionIndex = old_version + 1

• All previous versions remain on-chain for audit

• Off-chain systems can easily query the current version: where { deprecated: false }

This allows corrections without destroying history. If a curator notices a typo or error, they archive an updated entry, and the system automatically tracks the lineage.

bytes32 contentHash;  // SHA-256 hash of canonical text

Users can optionally hash their content using strict normalization rules:

• Unicode NFC normalization (composed characters)

• Standardized line endings (LF)

• Consistent indentation (4 spaces)

• Removal of trailing whitespace

• Collapsing of excessive blank lines

This ensures that the same canonical text always produces the same hash. Readers can independently verify that archived text matches the on-chain hash, establishing cryptographic proof of authenticity.

address nftAddress;   // Optional NFT contract
uint256 nftId;        // Optional token ID

Rather than forcing NFT integration, Lit3Ledger.sol makes it optional. A curator can link entries to digital collectibles, enabling:

• Tiered access based on token ownership

• Collectible chapters

• Cross-protocol composition (entries + NFT markets)

The zero address (0x0) signals "no NFT"—a clear, standard convention.

The original used narrative-centric field names:

• shardTag → title

• echoSource → source

• earthTime → timestamp1

• lankaTime → timestamp2

• archivistLog → curatorNote

This transition serves two purposes:

• Discoverability: Generic terms like "title" and "source" appear in searches; "echo source" does not

• Accessibility: Developers unfamiliar with The Plexus (the literary project that inspired the original) can immediately understand the schema

Lit3Ledger.sol implements role-based access control (curator-only) and event-driven architecture:

function archiveEntry(...) public onlyCurator {
    entries.push(Entry(...));
    emit EntryArchived(...);
}

function archiveUpdatedEntry(..., uint256 deprecateIndex) public onlyCurator {
    entries[deprecateIndex].deprecated = true;
    entries.push(Entry(...));
    emit EntryDeprecated(...);
}

Events enable off-chain indexing. The Graph's subgraph service monitors these events and maintains a queryable GraphQL endpoint, enabling frontend applications to fetch data without scanning the blockchain directly.

Deployment scripts automate:

• Contract compilation via Foundry

• Deployment to Base (Sepolia testnet and mainnet)

• Automatic source code verification on BaseScan

• Environment configuration updates

The hashing process enforces strict normalization via Node.js:

// 1. Remove BOM (Byte Order Mark)
// 2. Normalize Unicode to NFC
// 3. Convert line endings to LF
// 4. Remove trailing whitespace per line
// 5. Standardize tabs to 4 spaces
// 6. Remove leading/trailing blank lines
// 7. Collapse multiple blank lines
// 8. Ensure single trailing newline

This deterministic process ensures reproducibility. Two curators with the same source text will generate identical hashes, proving content equivalence.

The contract includes comprehensive tests:

• Deployment and initialization

• Entry archiving with various inputs

• Versioning chains (v1 → v2 → v3)

• Prevention of double-deprecation

• Batch operations and pagination

• Event emission verification

• Fuzz testing for edge cases

Tests are run via Foundry and achieve high coverage, promoting reliability across mainnet deployment.

1. Archive new narrative entries with optional metadata

2. Update entries while preserving version history

3. Verify content authenticity by comparing local hash to on-chain hash

4. Integrate with NFT platforms for collectible chapters

5. Query complete history via GraphQL for analytics and verification

1. Access canonical versions (non-deprecated entries)

2. Examine version history to understand editorial changes

3. Verify authenticity of original texts

4. Discover NFT integrations if present

5. Audit metadata (timestamps, sources, curator notes)

1. Standard GraphQL API for data querying

2. Neutral terminology enabling easy integration with other systems

3. Open-source implementation allowing customization

4. Testable contracts with comprehensive examples

5. Multi-network support (testnet and mainnet)

./archive-entry.sh base-sepolia "Chapter One" "Author's Archive" "2025-10-11" "2025-10-12" "First publication" none 0 chapter-one.md

Result: Entry at index 0, version 1, content hash stored on-chain

The curator notices a typo. Rather than accepting the error or creating a duplicate:

./archive-updated-entry.sh base-sepolia 0 "Chapter One" "Author's Archive" "2025-10-11" "2025-10-12" "Corrected typo: 'recieved' → 'received'" none 0 chapter-one-fixed.md

Result: Original entry marked deprecated; new entry at index 1, version 2

The curator decides to mint this chapter as an NFT collectible:

./archive-updated-entry.sh base-sepolia 1 "Chapter One (Collector's Edition)" "Author's Archive" "2025-10-11" "2025-10-12" "Collector's edition with bonus notes" 0x1234...abcd 1 chapter-one-collectors.md

Result: Entry at index 2, version 3, linked to NFT contract

Via the GraphQL API:

• Query latest version: entries(where: { title: "Chapter One", deprecated: false }) → Returns index 2, version 3

• View history: entries(where: { title: "Chapter One" }) → Shows indices 0, 1, 2 with version progression

• Verify authenticity: Compare local file hash against contentHash on-chain

Rather than immutable rebasing or content replacement, Lit3Ledger uses append-only versioning. Each update creates a new entry.

Pros:

• Complete audit trail

• Simple contract logic

• Clear version ordering

Cons:

• More storage per update

• Query complexity when finding "current version"

This trade-off favors transparency and simplicity.

NFT integration and content hashing are entirely optional. Zero addresses and zero hashes signal "not applicable."

Rationale:

• Simplifies for users who don't need these features

• Reduces gas costs when features aren't used

• Allows graceful feature adoption over time

The shift from domain-specific to generic terms reflects a maturation from prototype to platform. The Plexus narrative context is preserved in documentation and project history, but the contract itself should serve any literary archive.

Lit3Ledger's design anticipates future enhancements:

1. Multi-language support via updated schema

2. Community verification through external attestation contracts

3. Royalty tracking via NFT integration

4. Cross-chain bridging to other blockchain networks

5. Structured metadata (genre, author, themes) via extended schemas

The core contract remains stable while enabling these extensions through composition rather than modification.

Lit3Ledger.sol represents a step forward in blockchain-based literary archiving. By introducing versioning, content verification, and optional NFT integration while maintaining simplicity and accessibility, it addresses the real needs of writers, curators, and researchers.

The transition from PlexusArchive.sol to Lit3Ledger.sol demonstrates a fundamental principle: as tools mature from prototype to platform, they must embrace broader terminology and use cases while preserving the creative vision that motivated their creation.

The result is a framework that maintains literary integrity, enables creative commerce, and provides verifiable provenance—all while remaining accessible to developers unfamiliar with blockchain technology.

Thank you for reading — see you in Lanka Prime.