The Plexus Archive exists. It's deployed on Base Mainnet, storing metadata for every From the Plexus shard. But here's the problem: blockchain data isn't designed for easy reading.

Imagine trying to enjoy a novel by querying a database. You'd need to know the exact table structures, write SQL queries, parse raw responses, and handle connection failures. Even if you had the technical skills, it would destroy any sense of immersion.

This is a challenge most Lit3 project will faces: how do you make blockchain data feel accessible without compromising its verifiability?

Our solution involved The Graph Protocol—a decentralized indexing service that translates blockchain events into queryable data. But more importantly, it required thinking carefully about what readers actually need versus what's technically possible.

When our smart contract archives a shard, it emits an event:

emit ShardArchived(
    shardIndex,
    "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."
);

This event gets recorded in the blockchain's transaction logs. Technically, anyone can access it—but "technically accessible" and "actually usable" are very different things.

Direct blockchain queries require:

• Running or paying for RPC node access

• Writing complex filtering logic

• Handling pagination manually

• Managing connection reliability

• Understanding blockchain data structures

For a reader who just wants to see the Archivist's log about a particular shard, this is absurd. It's like requiring chemistry knowledge to read a book printed on paper.

The Graph Protocol solves this by continuously monitoring blockchain events and organizing them into a structured, queryable database. Think of it as creating a library catalog for blockchain data—the books (smart contract events) remain immutable, but now there's an index that makes finding information straightforward.

For our implementation, this meant:

Defining what data matters: Not everything on the blockchain is relevant. We created a schema that captures exactly what readers might want to query—shard metadata, timestamps, transaction hashes for verification.

Creating the index: We wrote event handlers that process each ShardArchived event and store it in The Graph's database with proper structure and relationships.

Exposing a query interface: The Graph automatically generates a GraphQL API endpoint where anyone can query our data without needing blockchain expertise.

The result? Instead of complex blockchain queries, readers (or our website) can ask simple questions:

"Show me the 10 most recent shards" "Find all shards from the Ahamkara District" "Get the Archivist's log for shard #5"

Here's why this architecture matters beyond just technical convenience:

Separation of concerns: The blockchain handles verification (proving data authenticity), while The Graph handles accessibility (making data readable). Each system does what it's best at.

Persistence without maintenance: Once our subgraph is deployed, it continues indexing our contract events automatically. If we stopped maintaining our website entirely, the data would remain queryable.

Openness to interpretation: Other developers could build entirely different interfaces to our Archive. Someone could create a visualization tool, a mobile app, or even integrate our shards into their own Lit3 project—all querying the same verified data source.

Reader independence: Readers don't need to trust our website. They can verify any shard's authenticity by checking the blockchain directly using the transaction hash we provide.

This is fundamentally different from traditional publishing where the publisher controls not just the content but also its entire distribution infrastructure.

Theory is clean. Practice is messy.

What took longer than expected: Writing the event handlers in AssemblyScript (The Graph's required language) meant learning yet another technology stack. Every additional tool adds friction.

What surprised us: The Graph Studio's deployment process is remarkably smooth—easier than deploying smart contracts. And the subgraph takes under a minute to sync after deployment, which made testing iterations fast.

What we'd do differently: We should have designed our smart contract events with The Graph in mind from the start. For example, indexed events get converted from string to bytes, which then makes The Graph return distorted values for those string logs. The easiest solution was to only use indexed for the uint256 shardIndex field.

What worked well: Having separate subgraphs for English and Spanish contracts means each language's Archive operates independently while using identical infrastructure.

Here's what this looks like from a reader's perspective:

They're reading a From the Plexus shard—a micro-story about a character in Lanka Prime. At the end, they see a button: "Reveal Logs."

Clicking it shows them:

• Where this transmission originated (Echo Source)

• When we intercepted it (Earth Time)

• When it occurred in the story universe (Lanka Time)

• The Archivist's observations about this shard

This entire experience—from button click to data display—happens in milliseconds. No wallet connection required. No blockchain knowledge needed. No sense that you're interacting with a "decentralized database."

But if you want to verify, a "Scan Shard" button links to the BaseScan explorer. Click it, and you see the raw blockchain record proving this data hasn't been altered since archiving.

The technology is invisible until you want it visible.

We framed this entire process through our lore: The Graph isn't just an indexing protocol, it's our way of "decoding transmissions from the Plexus."

The Archivist operates in a realm outside normal space-time. Their inscriptions aren't immediately readable to us—they require translation. The Graph Protocol becomes that translation layer, making the mystical Archive accessible to mortal readers.

Is this metaphor layer necessary? No. But it maintains narrative coherence while teaching readers about blockchain infrastructure without them realizing they're learning.

This is the advantage of building Lit3 projects with integrated world-building: technical implementations can serve dual purposes—functional and narrative.

The Archive is now both permanent and accessible. Readers can query shard data, verify its authenticity, and explore metadata that enhances their understanding of the story world.

But querying an API from code is still different from reading a story. In Part 5, we'll explore how we integrated this blockchain data into the actual reading experience—embedding Archive access directly in our MDX stories without breaking immersion.

The goal: make interacting with on-chain data feel as natural as clicking a footnote in a digital book.

Thank you for reading — see you in Lanka Prime.