Crumpet Media - Narrative Overview

What this page is: a single, polished narrative that ties the whole system together—technology, economics, and governance—without assuming you’re a protocol engineer. If you read this end‑to‑end, you should understand how Crumpet works, why it’s designed this way, and how the parts fit.

---

1) The One‑Minute Picture

Crumpet is an open, censorship‑resistant publishing and search protocol for articles. It has:

• Authors who publish articles as tamper‑evident bundles on IPFS.

• Readers who search, read, and react on‑chain with a single action per article.

• Nodes (independent servers) that verify content, index it per language, and serve queries.

• A simple token, CRUMBS, that powers upvotes/tips, downvotes, flags, and publish bonds.

• A Vault where protocol fees go, which funds Node Rewards weekly.

• A DAO‑owned Config (with a timelock) that sets the public rules and parameters.

Multiple independent frontends can exist; they all plug into the same open data and compare multiple nodes so no single server controls what you see.

---

2) Core Objects & Rules (the “physics” of Crumpet)

2.1 Articles are sealed boxes (AOM)

Each article is an AOM package: a directory with

• body.md (Markdown),

• images under /media/…,

• a deterministic preview.html,

• a manifest (crumpet.json) with hashes of every file.

Hard limits (v0/v0.1):

• Max package size 4 MB,

• ≤ 10 images,

• max 2560 px long edge per image,

• alt text required.

This makes verification fast and keeps UIs snappy.

2.2 Single action per wallet per article

A wallet can do exactly one of the following on any article:

• Upvote (you choose an amount of CRUMBS),

• Dislike (fixed 25 CRUMBS),

• DownVote (fixed 50 CRUMBS), or

• Flag (fixed 25 CRUMBS to open a dispute case with others).

You can’t upvote and downvote, or vote and flag, etc. One action total. This keeps signals clean and reduces gaming.

2.3 Linear scores, transparent math

An article’s score = (sum of counted upvotes) − (sum of dislikes & downvotes).

• Upvote amounts: minimum 10 CRUMBS; up to 100 CRUMBS count toward score. If you pay more than 100, the extra is a tip (doesn’t change the score).

• Dislike: 25 CRUMBS (subtracts 25 from score).

• DownVote: 50 CRUMBS (subtracts 50 from score).

2.4 Who gets paid when you upvote?

• Of the counted portion (up to 100): 20% goes to the Vault, 80% to the Author.

• Any tip above 100 goes 100% to the Author.

• Dislikes and DownVotes go 100% to the Vault.

2.5 Flags & disputes (calm escalation)

• Flag costs 25 CRUMBS (refundable if action is taken).

• A case opens after 3 flags.

• There’s a grace period ~10 days after publish before strong actions are considered.

• If the DAO decides action is needed, the Author’s publish bond (default 100 CRUMBS) is slashed to the Vault and flag fees are refunded.

• If the DAO decides no action, flag fees stay in the Vault.

• Over time, disputes evolve toward Community Notes‑style context (attach notes approved by the DAO flow).

2.6 Governance knobs (DAO‑timelocked)

The DAO controls parameters in a Config contract with a public timelock:

• MIN_UP=10, MAX_UP_WEIGHT=100, DISLIKE=25, DOWNVOTE=50,

• PUBLISH_BOND=100, FLAG_FEE=25, FLAGS_TO_OPEN=3, GRACE_SECONDS≈10 days,

• reward split caps, epoch length, etc.

Changes can’t be surprise moves—there’s a delay and on‑chain logs. Nodes stamp a paramsHash in their snapshot metadata so users know which rules were in force.

---

3) Publishing, Searching, and Disputing—End‑to‑End

3.1 Publishing flow (Author experience)

1. Compose in the Authoring App (Markdown + live deterministic preview).

2. Validate AOM rules (size, images, alt text, etc.).

3. Pin to IPFS via the Pinning Orchestrator. It pushes to multiple providers and waits for a 3‑of‑N quorum of “pinned” acks, then gives you a signed receipt.

4. Publish on‑chain (ArticlesRegistry). A 100 CRUMBS bond is escrows. The article is identified forever by its CID (IPFS content address).

Edits are new editions linked to the previous edition (lineage is public).

3.2 Search & read (Reader experience)

• Frontends call multiple CIN nodes (Crumpet Indexer Nodes) in parallel.

• Each node:

  • watches on‑chain events,

  • fetches the AOM from IPFS,

  • verifies hashes & sanitizes,

  • indexes per language (e.g., English, Spanish, Japanese),

  • periodically publishes a signed snapshot with a Merkle root of its catalog.

Frontends seek quorum (e.g., 2 nodes agree on the same results/metadata). If nodes disagree, the UI shows the difference—no silent hiding.

3.3 React & dispute (Reader/community)

• Your action (upvote, dislike, downvote, or flag) is a direct on‑chain transaction using CRUMBS.

• Flags are refundable if a case leads to action; otherwise they’re kept (which discourages frivolous flags).

• The DAO can attach notes or take actions after the grace window.

---

4) Incentives & Money Flows (simple but principled)

4.1 Where money comes from

• Counted upvotes: 20% → Vault; 80% → Author.

• Tips (above 100): 100% → Author.

• Dislikes/DownVotes: 100% → Vault.

• Slashed bonds/flags: → Vault (only when action is taken).

• Refunded flags/bonds: back to payer.

4.2 Who gets paid from the Vault (Node Rewards)

Once per epoch (weekly by default), a portion of the week’s net inflow (up to 40%, capped) funds Node Rewards across three buckets:

• Uptime (e.g., 40%) — was your node reachable and fresh?

• Build (e.g., 40%) — did you publish and announce valid snapshots?

• Serve (e.g., 20%, optional) — did you actually serve traffic well?

Independent Watchers (referees) probe nodes and sign attestations used to compute these payouts. If a language has only one builder, Watchers provide committee attestations of that node’s snapshot root.

---

5) The Trust & Safety Model (why it holds up)

1. Content authenticity via AOM hashes and deterministic rendering. If the bytes don’t match, it’s rejected.

2. Availability via multi‑pin (3‑of‑N) before on‑chain publish.

3. Search integrity via:

   • Multiple nodes serving results,

   • Snapshots (Merkle roots) so nodes can’t quietly alter their corpus without detection,

   • Quorum in the client to compare nodes and surface disagreements,

   • Watchers providing neutral measurements and attestations.

4. Economic alignment via Vault flows and weekly rewards—good behavior earns CRUMBS; bad behavior earns nothing and is visible.

5. Governance hygiene via DAO‑timelocked Config and a public paramsHash in snapshots.

No single server or company can control what’s visible. Many frontends can exist; they choose their preferred nodes and show users the provenance (which nodes agreed, which snapshot root, under what parameters).

---

6) The Networking & Performance Story (in human terms)

• Nodes are written in Rust for speed and safety.

• They talk over modern transports:

  • HTTP/2 for JSON APIs,

  • WebSockets for live updates (scores, disputes, snapshot rotations),

  • gRPC (HTTP/2) for node‑to‑node control,

  • QUIC/HTTP/3 and libp2p for fast snapshot sharing & gossip.

• Indexing is per language so we can scale horizontally. A small node can handle a few languages on modest hardware.

• The UI is a Next.js reference app, but anyone can build their own. The SDK provides ready‑made calls, including the quorum comparison logic.

---

7) A Concrete Walkthrough (numbers included)

1. Author publishes: pins to 3 IPFS peers, gets a receipt, posts the article on‑chain with a 100 CRUMBS bond.

2. Nodes verify and add the article to their language indexes, then publish a snapshot (Merkle root).

3. Readers search: the UI queries 3 nodes; 2 respond with matching results (same paramsHash, same top‑K fingerprint)—UI shows a quorum badge.

4. Reader upvotes 75:

   • Counted = 75 (≤ 100).

   • To Vault (20%) = 15; to Author = 60.

   • Score +75.

5. Another reader taps Dislike:

   • 25 goes to Vault, score −25.

6. Net score now +50.

7. If 3 flags appear within the grace window, a case opens. If the DAO later takes action, flaggers get 25 back each, and the Author’s 100 bond is slashed to the Vault.

---

8) Extensibility & Local Control

• Frontends: Anyone can launch a localized frontend (language, theme, curation guidelines) and still be fully compatible—because the protocol and SDK are open and minimal.

• Node choice: Communities can recommend node sets; power users can pick their own.

• Future upgrades (non‑breaking): new ranking options, per‑query proofs, additional languages, or even optional NFTs for badges/passes—without changing the core author/reader contract.

---

9) FAQs (straight answers)

Q: Why cap counted upvotes at 100 CRUMBS? To limit influence per wallet per article. You can tip above 100 to reward the author, but it doesn’t inflate the scoreboard.

Q: Doesn’t “one action per wallet” make Sybils easy? Splitting into many wallets isn’t a free win: each wallet’s counted upvote is capped; flags cost money and are only refunded if action is taken; disagreements across nodes and watcher data expose manipulation patterns to the community.

Q: Who decides disputes? The DAO. Economics enforce fairness (refunds vs. slashes), and decisions are public. Over time, approved notes (context) can be attached to articles.

Q: What if a node hides content? It won’t match other nodes’ snapshots. Clients compare nodes and show that mismatch. Watchers and rewards further pressure nodes to be honest.

Q: What if a pinning provider disappears? We required 3‑of‑N pins before publishing; others remain. Nodes and users can still fetch the content from alternative peers.

Q: Can rules change suddenly? No. All tunables live in Config under a timelock. Snapshots include a paramsHash, so you always see which settings were active.

---

10) Quick Reference (v0 / v0.1 defaults)

• Upvote: min 10, counted up to 100; counted share 20% → Vault, 80% → Author; tips (above 100) 100% → Author

• Dislike: 25 (→ Vault)

• DownVote: 50 (→ Vault)

• Flag: 25 (refundable if action taken)

• Publish bond: 100 (slashed if action taken; else refunded)

• Dispute threshold: 3 flags to open, ~10 days grace

• AOM caps: 4 MB, ≤10 images, ≤2560 px long edge

• Pinning quorum: 3‑of‑N

• Node rewards: up to 40% of weekly net → rewards; suggested split 40% uptime / 40% build / 20% serve

• Client behavior: query ≥2 nodes; show quorum and snapshot/params metadata

---

11) Why Crumpet is practical

• Fast UX: Small, deterministic packages + language‑segmented indexes + modern transports.

• Clear incentives: Authors get paid; readers’ negative signals fund the network; nodes earn weekly for real work.

• Operationally sane: Time‑based windows (not block‑based assumptions), open APIs, and off‑the‑shelf infra.

• Socially resilient: Many frontends, many nodes, public proofs and parameters.

---

Final Thought

Crumpet’s promise is clarity: clear content integrity, clear economics, clear governance, and clear ways for communities to fork the frontend—not the truth. If you understand content hashes, one‑action voting, multi‑pinning, and weekly rewards, you understand Crumpet.

For implementation details, see the technical pages on AOM, Actions, Disputes, Vault & Node Rewards, CIN Node, Client SDKs, Authoring App, DevOps, APIs, and more.