
Making Literature Legible to Web3
The four Lit3 frameworks—Token, Governance, Ledger, and Permanence—provide the infrastructure for literature in Web3. Creators can mint book tokens, archive chapters on-chain, store canonical hashes, and preserve texts on decentralized storage. The technical foundation exists.
Yet a practical problem remains: How do readers, marketplaces, and tools recognize that a token represents literature rather than art, a game item, or a financial instrument?
ERC-721 and ERC-1155 tokens use JSON metadata to describe what they represent. A typical NFT metadata file includes fields like name, description, image, and attributes. These standards work well for visual art and collectibles, but they weren't designed with literary works in mind. There's no conventional way to signal that a token connects to a Lit3 Ledger contract, references a canonical text hash, or implements specific literary frameworks.
The Lit3 Metadata Standard addresses this gap by introducing a dedicated lit3 object within token metadata—a namespace that makes literature legible to the broader Web3 ecosystem.
The lit3 object serves three essential functions:
The frameworks array explicitly declares which Lit3 frameworks a project implements:
"lit3": {
"frameworks": ["Token", "Ledger", "Permanence"]
}
This simple declaration tells readers, tools, and marketplaces:
This is a literary token, not a generic NFT
It uses specific Lit3 infrastructure
Certain capabilities and guarantees are available
Without this signal, a lit3 token is indistinguishable from any other token. With it, specialized interfaces can recognize and respond to literary works appropriately.
The lit3 object provides direct references to the core components of the Permanence Framework:
"lit3": {
"frameworks": ["Token", "Permanence"],
"canonical_text": {
"normalization_protocol": "HNP-1",
"hash_algorithm": "SHA-256",
"hash": "abc123..."
},
"storage": {
"primary": "https://example.com/book",
"ipfs": "ipfs://QmHash",
"arweave": "ar://TxId"
},
"license": "CC BY-NC-SA 4.0"
}
These fields answer fundamental questions readers have about literary works:
Is this text authentic? (Check the canonical hash)
Where can I read it? (Follow the storage links)
What are my usage rights? (Consult the license)
By embedding this information in token metadata, creators ensure that permanence guarantees are immediately discoverable—no separate documentation or off-chain records required.
For projects using the Ledger Framework, the lit3 object provides on-chain contract references:
"lit3": {
"frameworks": ["Token", "Ledger"],
"ledger_contract": "0x1234...",
"ledger_network": "Base"
}
This creates a bidirectional link:
Token → Ledger: "This book token connects to these on-chain records"
Ledger → Token: "These chapter entries belong to this token collection"
Tools can traverse these connections to build complete literary archives, trace narrative histories, or verify that claimed metadata matches on-chain records.
The Lit3 Metadata Standard introduces a top-level lit3 object alongside the standard ERC-721/1155 fields:
{
"name": "Book Title",
"description": "Token description",
"image": "ipfs://...",
"external_url": "https://...",
"attributes": [...],
"lit3": {
"frameworks": ["Token", "Ledger", "Permanence"],
"ledger_contract": "0x...",
"ledger_network": "Base",
"canonical_text": {
"normalization_protocol": "HNP-1",
"hash_algorithm": "SHA-256",
"hash": "..."
},
"storage": {
"primary": "https://...",
"ipfs": "ipfs://...",
"arweave": "ar://..."
},
"license": "CC BY-NC-SA 4.0",
"license_url": "https://creativecommons.org/licenses/by-nc-sa/4.0/"
}
}
frameworks
Declares which Lit3 frameworks the project implements
Valid values: "Token", "Governance", "Ledger", "Permanence"
Enables tools to provide framework-specific features
ledger_contract
Ethereum address of the Lit3 Ledger contract
Only relevant for projects using the Ledger Framework
Enables verification that token metadata matches on-chain records
ledger_network
Blockchain network where the ledger contract is deployed
Examples: "Ethereum", "Base", "Polygon", "Arbitrum"
Necessary because the same address can exist on multiple networks
canonical_text
Contains the cryptographic hash of the normalized text
Subfields:
normalization_protocol: The text preparation standard (e.g., "HNP-1")
hash_algorithm: The hashing method (e.g., "SHA-256")
hash: The actual hash value
storage
Provides references to where the full text can be accessed
Subfields:
primary: Main access point (often the author's website)
ipfs: IPFS content identifier
arweave: Arweave transaction ID
Additional protocols can be added as needed
license
The canonical usage terms for the text
Common formats: Creative Commons identifiers, copyright declarations, public domain statements
Creates an immutable record of creator intent
license_url
Direct link to the full license text
Useful for custom licenses or detailed terms
Not every project uses all four frameworks. The lit3 object adapts to the specific combination implemented:
"lit3": {
"frameworks": ["Token"],
"license": "All Rights Reserved"
}
Use case: A novelist minting limited edition first chapters as collectible tokens, but not implementing on-chain metadata management or permanent storage.
"lit3": {
"frameworks": ["Token", "Permanence"],
"canonical_text": {
"normalization_protocol": "HNP-1",
"hash_algorithm": "SHA-256",
"hash": "abc123..."
},
"storage": {
"ipfs": "ipfs://QmHash",
"arweave": "ar://TxId"
},
"license": "CC0 1.0"
}
Use case: A poet releasing a completed collection with cryptographic verification and decentralized storage, but without on-chain chapter metadata or governance mechanisms.
"lit3": {
"frameworks": ["Token", "Ledger", "Permanence"],
"ledger_contract": "0x1234...",
"ledger_network": "Base",
"canonical_text": {
"normalization_protocol": "HNP-1",
"hash_algorithm": "SHA-256",
"hash": "abc123..."
},
"storage": {
"primary": "https://example.com/book",
"ipfs": "ipfs://QmHash",
"arweave": "ar://TxId"
},
"license": "CC BY-NC-SA 4.0",
"license_url": "https://creativecommons.org/licenses/by-nc-sa/4.0/"
}
Use case: A serialized web novel implementing tokenized book support, on-chain chapter archives, and permanent text preservation.
"lit3": {
"frameworks": ["Token", "Governance", "Ledger", "Permanence"],
"ledger_contract": "0x1234...",
"ledger_network": "Base",
"governance": {
"voting_contract": "0x5678...",
"voting_network": "Base",
"mechanism": "Token-Weighted Voting",
"participation_token": "0x1234...",
"proposal_threshold": 1000,
"description": "Token holders vote on major plot decisions at Parley milestones"
},
"canonical_text": {
"normalization_protocol": "HNP-1",
"hash_algorithm": "SHA-256",
"hash": "abc123..."
},
"storage": {
"primary": "https://example.com/book",
"ipfs": "ipfs://QmHash",
"arweave": "ar://TxId"
},
"license": "CC BY-NC-SA 4.0",
"license_url": "https://creativecommons.org/licenses/by-nc-sa/4.0/"
}
Use case: A serialized web novel implementing the complete Lit3 stack—tokenized community support, reader governance over narrative direction, on-chain chapter archives, and permanent text preservation. Readers who hold book tokens can participate in governance votes that influence the story's development, with all decisions recorded on-chain alongside the canonical text and metadata.
For works in progress—particularly serialized fiction—not all Permanence Framework components are available immediately. The "pending" convention provides a way to signal intent without misrepresenting current status:
"lit3": {
"frameworks": ["Token", "Ledger", "Permanence"],
"ledger_contract": "0x1234...",
"ledger_network": "Base",
"canonical_text": "pending",
"storage": {
"primary": "https://example.com/book",
"ipfs": "pending",
"arweave": "pending"
},
"license": "CC BY-NC-SA 4.0"
}
This structure communicates:
The project implements the Permanence Framework
Permanent storage and canonical hashing are planned
The work is not yet complete, but infrastructure is being built
Readers can check back later for the canonical hash and decentralized storage links
Three-state system:
Field with data → Implemented
Field with "pending" → Planned but not yet done
Field absent → Not applicable for this work
This approach avoids confusion. If canonical_text were simply omitted, readers wouldn't know whether the creator forgot, chose not to implement it, or plans to add it later. The "pending" value makes intent explicit.
The Lit3 Metadata Standard is deliberately minimal—it defines the essential fields needed today while remaining flexible for tomorrow's needs. As more creators adopt Lit3, several natural expansions emerge:
Multi-Format Archives: As new decentralized storage protocols emerge, the storage object can expand:
"storage": {
"primary": "https://example.com/book",
"ipfs": "ipfs://QmHash",
"arweave": "ar://TxId",
"filecoin": "filecoin://...",
"storj": "storj://...",
"future_protocol": "protocol://..."
}
The standard accommodates technological evolution without requiring specification updates.
Translation and Edition Tracking: For works with multiple editions or translations, creators can extend the metadata:
"lit3": {
"frameworks": ["Token", "Permanence"],
"editions": [
{
"language": "English",
"version": "First Edition",
"hash": "abc123...",
"storage": {"ipfs": "ipfs://QmHash1"}
},
{
"language": "Spanish",
"version": "Traducción Primera",
"hash": "def456...",
"storage": {"ipfs": "ipfs://QmHash2"}
}
]
}
Literary-Specific Interfaces: Marketplaces can detect the lit3 object and provide specialized features:
Display canonical hash verification tools
Show direct "Read Now" links from storage fields
Highlight license terms prominently
Link to Lit3 Ledger contract for chapter browsing
Filter tokens by implemented frameworks
Cross-Project Discovery: A marketplace could build a "Lit3 Library" view that aggregates all tokens with "frameworks": ["Token", ...], creating a dedicated space for literary NFTs distinct from art, music, or gaming collectibles.
Verification Services: Marketplaces could offer "Verified Lit3 Project" badges by:
Confirming the ledger_contract address is valid
Verifying storage links are accessible
Checking that the canonical hash matches the retrievable text
Validating license declarations against standard formats
Personal Literary Archives: Wallet applications could detect Lit3 tokens and create automatic "library" views, pulling metadata from the lit3 object to organize holdings by series, author, or framework implementation.
Reading Applications: A dedicated Lit3 reader application could:
Parse the storage object to fetch the full text from IPFS, Arweave, or the primary URL
Verify authenticity by comparing the local file's hash to canonical_text.hash
Display license information before allowing exports or sharing
Surface on-chain chapter metadata from the linked Lit3 Ledger contract
Academic and Archival Research: Scholars studying Web3 literature could query blockchain data to find all tokens with "frameworks": ["Permanence"], then analyze which storage protocols are most commonly used, how licenses have evolved over time, or which networks host the most literary archives.
The Lit3 Metadata Standard is not a rigid specification enforced by a central authority. It's an emergent convention—a pattern that creators adopt because it makes their work more discoverable, their claims more verifiable, and their infrastructure more composable.
Without a standard, every Lit3 project would structure its metadata differently. A tool built to work with one book token wouldn't work with another. Readers would have no reliable way to find the canonical text or verify its authenticity. Marketplaces couldn't provide literary-specific features because they wouldn't know which tokens represent books.
The lit3 object solves this by creating a shared language. When a creator includes "frameworks": ["Token", "Permanence"], they're not just documenting their technical choices—they're joining a community, signaling to readers and tools that their work participates in a broader literary ecosystem.
This is how standards emerge in open ecosystems: not by decree, but by consensus. Enough creators find the pattern useful, enough tools support it, enough readers recognize it, and suddenly it's not a proposal—it's infrastructure.
The Lit3 Metadata Standard completes the bridge between Web3 infrastructure and literary content. The frameworks provide the capabilities—ownership, governance, archival, permanence—but the lit3 object makes those capabilities legible.
It answers the essential questions:
What is this token?
What guarantees does it provide?
Where can I find the actual story?
How can I verify it's authentic?
What am I allowed to do with it?
By embedding these answers directly in token metadata, the standard ensures that literature in Web3 is not just technically possible but practically accessible. Readers don't need to understand smart contracts or blockchain explorers. They just need to look at the metadata, and everything they need to know—where to read, how to verify, what rights they have—is right there.
For creators, the standard provides a clear template. You don't have to invent your own metadata structure or wonder whether marketplaces will understand your project. You include a lit3 object, declare your frameworks, and the ecosystem knows what to do with it.
For the ecosystem as a whole, the standard enables composability at the application layer. Wallets, readers, marketplaces, and archival tools can all recognize and interact with Lit3 tokens, creating a rich infrastructure around literary works without requiring coordination between every participant.
The Lit3 frameworks built the foundation. The Lit3 Metadata Standard opens the door.
Share Dialog
Lokapal
No comments yet