Our smart contract, PlexusArchive.sol, does something deceptively simple: it stores five pieces of metadata for each shard.

struct Shard {
    string shardTag;        // The Archivist's label
    string echoSource;      // Where the transmission originated
    string earthTime;       // When we intercepted it (UTC)
    string lankaTime;       // When it occurred in Lanka Prime
    string archivistLog;    // The Archivist's observations
}

But the way it stores this data matters enormously:

Access Control: Only one wallet—the Archivist's—can archive new shards. This isn't just security; it's canon. The Archivist is a singular entity in our lore. One wallet, one being.

Immutability: Once archived, shards cannot be edited or deleted. What the Archivist records becomes permanent truth. This mirrors the narrative function of the Archive as the authoritative record of transmissions.

Event Emission: Every archiving action emits a ShardArchived event containing all metadata. These events become the foundation for querying—but more on that in Part 4 of Making From Many, as One.

Permanent Indexing: Each shard gets a sequential index and records the block number at archiving time. The Akashic Imprint became our term for this — a nod to the concept of Akashic records, which are believed by theosophists to be encoded in a non-physical plane of existence known as the mental plane.

The technical choices reinforce the world-building. We're not just storing data; we're inscribing transmissions into a mystical archive.

Note: The Plexus Archive code is completely open source, licensed under the MIT License, and readily accessible in our Github repository. Feel free to clone it and modify it.

Here's something we learned the hard way: most writers aren't going to learn Solidity, compile contracts, and manually deploy to blockchain networks. If Lit3 is going to be a movement, the technical barrier needs to be dramatically lower.

Our solution was building deployment scripts that handle complexity behind simple commands. Our current script allows the user to deploy to either Base Sepolia or Base Mainnet. But because the code is open source, it can be changed to access any other EVM network:

./deploy-archive.sh base-sepolia

That single command:

1. Compiles the smart contract

2. Deploys it to either Base Sepolia testnet

3. Verifies the source code on BaseScan

4. Saves the contract address to configuration files

5. Provides direct links to view the contract

But here's what makes this approach useful for other Lit3 projects: the scripts are readable by non-developers. Open deploy-archive.sh and you'll see plain bash commands with comments explaining what each section does. A writer comfortable with terminal commands can modify these scripts for their own projects without understanding Solidity internals.

We made similar scripts for archiving shards:

./archive-shard.sh base-sepolia \
  "Lighting a Cigar" \
  "Lobha Exchange Train Network" \
  "2025-09-28 14:47:53 UTC" \
  "Varsam 7E9, Dinam 10F, Kala 455" \
  "Honor is not fitting in a fool"

The script prompts for confirmation, shows gas estimates, and provides transaction links. It makes blockchain interaction feel more like publishing a blog post than executing smart contract functions.

Foundry (our smart contract framework) runs scripts in a sandboxed environment where file operations can cause transaction reversals. If you try to write deployment data to disk during the deployment transaction, blockchain nodes rightfully reject it.

The solution was separating concerns: the Solidity script handles blockchain operations, bash scripts handle file operations. Not elegant, but pragmatic. This shows an important lesson: working with blockchain requires accepting its constraints rather than fighting them.

This is relevant for Lit3 projects because it's a pattern you'll encounter repeatedly: the blockchain does certain things exceptionally well (immutable storage, verification, ownership) and other things poorly (file I/O, complex computation, mutable state). Design your system around blockchain's strengths, and handle everything else off-chain.

With our smart contract deployed and scripts written, we can now:

Archive shards permanently: Each From the Plexus micro-story gets recorded on Base Mainnet with its metadata. This record cannot be altered, cannot be deleted, and will persist as long as Base exists.

Prove authenticity: Anyone can verify that a shard labeled "official" actually came from the Archivist's wallet. No central authority needed.

Build on the foundation: Other developers could potentially query our Archive and build tools, visualizations, or even derivative stories using our canonical data.

Maintain narrative coherence: Because only one wallet can archive, there's no ambiguity about what's canon. The Archivist's word is law—both technically and narratively.

But here's what we couldn't do yet: make this data easily accessible to readers. The Archive existed, but it was like a book locked in a vault. You could verify it was there, but you couldn't read it without significant technical knowledge.

That's where Part 4 comes in.

Start with the simplest possible implementation: Our first contract draft had complex features we thought we'd need. We cut 60% of it. Start simple, add complexity only when necessary.

Gas costs matter less on L2s: Base (an Ethereum Layer 2) has cheap transactions. Don't over-optimize gas usage at the expense of code clarity.

Write for your future self: Six months from now, you may need to modify this contract. Write comments explaining why you made design decisions, not just what the code does.

Testnet first, always: We deployed to Base Sepolia multiple times, caught bugs, refined our process. Never experiment on mainnet.

Blockchain development is slower than you think: Even simple contracts require extensive testing, deployment scripts, and verification processes. Budget accordingly.

The Plexus Archive now exists on-chain, permanently storing our story metadata. But blockchain data isn't designed for human consumption—it's optimized for consensus and verification.

In Part 4, we'll explore how we made the Archive queryable: using The Graph Protocol to index our smart contract events and expose them through a GraphQL API. This is where the technical infrastructure starts becoming invisible, and readers can finally interact with the Archive without needing to understand how it works.

The goal isn't just making blockchain data accessible—it's making it feel like a natural extension of the reading experience.

Thank you for reading — see you in Lanka Prime.

Making From Many, as One — Part 3: Building a Lit3 Ledger

Share Dialog