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.

Notes on Lit3 — Part 8: The Lit3 Metadata Standard