# Making From Many, as One — Part 8: Updating Our Prototype

**Published by:** [Lokapal](https://paragraph.com/@lokapal/)
**Published on:** 2025-11-06
**Categories:** web3, lit3, literature, fiction, serial
**URL:** https://paragraph.com/@lokapal/making-from-many-as-one-part-8-updating-our-prototype

## Content

The Problem: Narrative Provenance in the Digital AgeLiterary 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:Allow updates without destroying the original recordTrack which version is currentMaintain complete history for audit purposesOptionally verify content authenticityIntegrate with emerging digital economies (NFTs)The new version of our Lit3 Ledger addresses these requirements while maintaining simplicity for non-technical users.The Original Implementation (PlexusArchive)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.Design Constraints of the OriginalImmutability-only approach: Entries were frozen upon creationLimited metadata: No versioning, no content verification, no external integrationsNarrative-centric terminology: Field names like "echoSource" and "archivistLog" were evocative but domain-specific, limiting discoverabilityIntroducing the New Lit3LedgerOur latest version of the Lit3Ledger extends the original with four critical additions:1. Versioning with Automatic Deprecationstruct Entry { // ... previous fields ... bool deprecated; uint256 versionIndex; } When a curator creates an updated entry using archiveUpdatedEntry():The old entry is marked deprecated = trueThe new entry receives versionIndex = old_version + 1All previous versions remain on-chain for auditOff-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.2. Content Verification via Cryptographic Hashingbytes32 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 whitespaceCollapsing of excessive blank linesThis 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.3. NFT Integration Pointsaddress 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 ownershipCollectible chaptersCross-protocol composition (entries + NFT markets)The zero address (0x0) signals "no NFT"—a clear, standard convention.4. Neutral, Accessible TerminologyThe original used narrative-centric field names:shardTag → titleechoSource → sourceearthTime → timestamp1lankaTime → timestamp2archivistLog → curatorNoteThis transition serves two purposes:Discoverability: Generic terms like "title" and "source" appear in searches; "echo source" does notAccessibility: Developers unfamiliar with The Plexus (the literary project that inspired the original) can immediately understand the schemaMethodology: Implementation and TestingSmart Contract DesignLit3Ledger.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 and VerificationDeployment scripts automate:Contract compilation via FoundryDeployment to Base (Sepolia testnet and mainnet)Automatic source code verification on BaseScanEnvironment configuration updatesText Normalization PipelineThe 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.Testing and Quality AssuranceThe contract includes comprehensive tests:Deployment and initializationEntry archiving with various inputsVersioning chains (v1 → v2 → v3)Prevention of double-deprecationBatch operations and paginationEvent emission verificationFuzz testing for edge casesTests are run via Foundry and achieve high coverage, promoting reliability across mainnet deployment.Resulting FunctionalityFor Writers and CuratorsArchive new narrative entries with optional metadataUpdate entries while preserving version historyVerify content authenticity by comparing local hash to on-chain hashIntegrate with NFT platforms for collectible chaptersQuery complete history via GraphQL for analytics and verificationFor Readers and ResearchersAccess canonical versions (non-deprecated entries)Examine version history to understand editorial changesVerify authenticity of original textsDiscover NFT integrations if presentAudit metadata (timestamps, sources, curator notes)For DevelopersStandard GraphQL API for data queryingNeutral terminology enabling easy integration with other systemsOpen-source implementation allowing customizationTestable contracts with comprehensive examplesMulti-network support (testnet and mainnet)Practical Example: A Publishing WorkflowDay 1: Initial Archive./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-chainDay 5: Discovered ErrorThe 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 2Day 30: NFT SaleThe 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 contractReaders' ViewVia the GraphQL API:Query latest version: entries(where: { title: "Chapter One", deprecated: false }) → Returns index 2, version 3View history: entries(where: { title: "Chapter One" }) → Shows indices 0, 1, 2 with version progressionVerify authenticity: Compare local file hash against contentHash on-chainDesign Decisions and Trade-offsVersioning ModelRather than immutable rebasing or content replacement, Lit3Ledger uses append-only versioning. Each update creates a new entry. Pros:Complete audit trailSimple contract logicClear version orderingCons:More storage per updateQuery complexity when finding "current version"This trade-off favors transparency and simplicity.Optional FieldsNFT integration and content hashing are entirely optional. Zero addresses and zero hashes signal "not applicable." Rationale:Simplifies for users who don't need these featuresReduces gas costs when features aren't usedAllows graceful feature adoption over timeNeutral TerminologyThe 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.Future ExtensibilityLit3Ledger's design anticipates future enhancements:Multi-language support via updated schemaCommunity verification through external attestation contractsRoyalty tracking via NFT integrationCross-chain bridging to other blockchain networksStructured metadata (genre, author, themes) via extended schemasThe core contract remains stable while enabling these extensions through composition rather than modification.Final ThoughtsLit3Ledger.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.

## Publication Information

- [Lokapal](https://paragraph.com/@lokapal/): Publication homepage
- [All Posts](https://paragraph.com/@lokapal/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@lokapal): Subscribe to updates
- [Twitter](https://twitter.com/lokapalxyz): Follow on Twitter
- [Farcaster](https://farcaster.xyz/lokapal): Follow on Farcaster