We've built the Archive. We've made it queryable. But here's the moment that actually matters: a reader is enjoying one of our micro-stories and wants to see the Archivist's observations.

Can they do it without:

• Connecting a wallet?

• Understanding blockchain?

• Leaving the reading experience?

• Waiting for slow loading times?

This is where theory meets practice. Where blockchain infrastructure either enhances storytelling or becomes an obstacle to it.

This article explores how we integrated on-chain data into the actual reading experience using Apollo Client—and more importantly, what that integration reveals about designing Lit3 projects that prioritize readers over technology.

Our micro-stories are written in MDX—a format that blends Markdown prose with React components. This gives us flexibility: narrative text flows naturally, but we can embed interactive elements where they serve the story.

The challenge was making blockchain data feel like a natural extension of this environment.

What we didn't want:

• A separate "Archive" page disconnected from the stories

• Obvious "web3" branding that breaks immersion

• Loading spinners that interrupt reading flow

• Technical jargon in the interface

What we needed:

• Seamless integration into story pages

• Fast, reliable data access

• Optional engagement (readers can ignore it if they want)

• Clear verification paths for readers who care about authenticity

The solution was treating blockchain data like enhanced footnotes—there if you want them, invisible if you don't.

Apollo Client is a library that connects our React components to The Graph's GraphQL API. But more importantly, it handles all the complexity we don't want readers to experience:

Caching: Once data is fetched, it's stored locally. Subsequent requests happen instantly.

Automatic updates: We configure polling intervals (30 seconds for our use case) so new shards appear without manual refreshing.

Error handling: Network issues, API downtime, or malformed queries are caught and handled gracefully.

Loading states: Components know whether data is still being fetched and can show appropriate UI.

From the reader's perspective, these technical challenges simply don't exist. The data is just there when they need it.

Here's what the reader sees at the end of each shard:

[Reveal Logs] [Scan Shard]

Two buttons. Simple interface. But behind the scenes:

Reveal Logs: Opens a modal displaying all five meta-narrative elements (Shard Tag, Echo Source, Earth Time, Lanka Time, Archivist Log) fetched from The Graph using Apollo Client.

Scan Shard: Opens BaseScan showing the raw blockchain transaction, proving the data's authenticity.

The component queries our indexed data by shard number:

const { data, loading, error } = useShardByIndex(shardIndex);

This single line handles:

• Fetching data from The Graph

• Caching results for future requests

• Providing loading and error states

• Updating automatically when new data arrives

We wrapped this in a custom hook, so it's reusable across all shard pages with identical functionality.

Here's where the technical implementation pays off creatively:

Dual narration: The off-chain story shows events from one perspective. The Archivist's on-chain log provides meta-commentary from an omniscient observer. Readers can experience the story without the commentary, then return later to see what the Archivist noticed.

Layered worldbuilding: Lanka Time uses hexadecimal values and Sanskrit terminology—a detail that would be distracting in the main story text but becomes an interesting discovery for engaged readers exploring the metadata.

Verifiable canon: In collaborative storytelling projects, disputes about "what really happened" can arise. With our Archive, there's an authoritative record. The Archivist's inscription is permanent and verifiable.

Cross-story references: As we archive more shards, readers might notice the Archivist mentioning connections between seemingly unrelated stories. This creates narrative depth impossible to achieve with traditional publishing.

None of these effects require readers to understand blockchain. They just read, click "Reveal Logs" if curious, and see additional context.

One complication: we publish in both English and Spanish, with separate smart contracts for each language. This required language-aware Apollo configuration:

const client = language === 'es' 
  ? spanishApolloClient 
  : englishApolloClient;

Each client points to a different subgraph endpoint, querying the appropriate contract. But from the reader's perspective, they just see content in their language. The infrastructure adapts invisibly.

This pattern is useful for any Lit3 project operating across languages or audiences—you can maintain separate on-chain records while presenting a unified interface.

The pattern we've established—smart contract → The Graph → Apollo Client → React components—is reusable for any Lit3 project that needs to surface blockchain data in reading experiences.

But the key insight isn't technical: readers shouldn't need to care about blockchain unless they want to.

Your on-chain data can enable powerful features:

• Community voting on story progression

• Provable ownership of contributed lore

• Verifiable authorship in collaborative projects

• Transparent canon management for shared universes

But the reader interface should feel natural, fast, and optional. Web3 infrastructure should be a foundation that enables better stories, not a barrier that prevents reading them.

What becomes possible when other projects can query our Archive?

Cross-story connections: Another Lit3 author could reference our Lanka Prime universe, proving the connection by querying our verified Archive.

Community tools: Fans could build visualization dashboards showing Echo Source locations on a map, or timelines of shard publications.

Derivative works: Fan fiction writers could create stories that explicitly acknowledge our canon by referencing specific shard indices.

Educational use: Writing instructors could use our Archive as a case study in transmedia storytelling and blockchain integration.

None of this requires our permission or involvement. The Archive is permanent, public infrastructure that anyone can build upon.

And this is just the start. We designed one of the simplest Lit3 implementations possible: a single click delivers more lore. This was intended to demonstrate that a functional and useful approach to Lit3 is possible, and not mere speculation. But the possibilities are endless! As long as we build robust applications and don't forget the reader along the way, we can expand as much as our stories need.

Thank you for reading — see you in Lanka Prime.