00 / Start HereStart here

What Bitcode is

Begin with the map: what AssetPacks are, how BTD volume and rights work, why Bitcoin settles value, and where Packs, Deposit, Read, Protocol, and interfaces fit.

This is the first page for readers who know nothing about Bitcode. It keeps the model plain before /deposits, /reads, /packs, proof, and interface pages.

After reading

You can explain Bitcode as a market for measured technical knowledge and name the major product surfaces without reading implementation history.

Plain model

01

Bitcode is a market for measured technical knowledge

An AssetPack is not a raw file upload, a tokenized repository, or a free-form AI answer. It is a measured, source-safe knowledge commodity that can satisfy a reviewed Need under auditable proof and settlement rules.

Bitcode starts with permitted source: code, files, designs, data, notes, commits, and metadata. Product routes synthesize that source into AssetPack supply, score needs-fits, hold protected IP behind obfuscation and measurement surfaces, then prove settlement on a fully open-source, decentralized, and auditable ledger. Buyers pay with Bitcoin; BTD records volume and rights — not a second payment currency.

Why this matters

First-time readers should leave with the market object (the AssetPack) and the safety rule (measurements visible; IP not) before learning any control surface.

  • Deposit lists AssetPacks synthesized from source you approve — not unrestricted repo dumps.
  • Read measures demand, compares needs-fits scores, and settles for knowledge delivery.
  • Packs rereads network activity: proofs, BTD volume/rights, BTC finality, delivery, and repair.

Product map

02

/deposits, /reads, and /packs are one system — interfaces ride the same law

Deposit prepares supply, Read expresses demand and receives paid delivery, and Packs is the durable activity ledger. Protocol is the rulebook. MCP, ChatGPT App, Bitcode Chat, GitHub, and webhooks are admitted ways to read or write that same state.

No interface is a separate product. Every write must leave source-safe activity that /packs can reread. Every delivery of protected contents depends on settlement finality and BTD rights transfer, not on which surface initiated the work.

Why this matters

Without one map, routes and integrations look like separate apps. With one map, operators know where to write, where to buy, and where to audit.

  • /packs owns searchable activity and expandable proof, settlement, compensation, delivery, and repair detail.
  • /deposits and /reads are the shortest seller and buyer paths.
  • Protocol owns semantics, proof families, fail-closed rules, and promotion truth.

Operator path

03

Deposit → Read → Fit → Prove → Settle → Deliver

Treat Bitcode as a short commercial chain: attach permitted source, synthesize packs, measure need and needs-fits, produce proofs, settle in BTC, transfer BTD rights, deliver knowledge.

Each product surface exposes one part of the chain. You write only when a bounded state change is intended, then reread /packs (or the route’s own proof panel) before trusting fit, settlement, or delivery.

Why this matters

Learning is faster when every control is part of the value path rather than miscellaneous chrome.

  1. 01Start with AssetPacks so the market object is clear.
  2. 02Open /deposits, /reads, and /packs so the three product loops are familiar.
  3. 03Use the action and read guides before treating live writes as final.
  4. 04Open proof, settlement, and interface chapters when operating against real integrations.

Commercial testnet

04

Testnet BTC is free; protocol state is not simulated

Launch uses Bitcoin testnet amounts so operators can rehearse settlement without value-bearing mainnet risk. Measurements, quotes, ordering, BTD rights, compensation, and delivery follow production-intended protocol law.

Testnet does not weaken identity, source safety, or delivery boundaries. Source-bearing AssetPack contents stay withheld until testnet finality and rights transfer. Value-bearing mainnet settlement remains blocked until a promoted version authorizes it.

Why this matters

Buyers and depositors must know which part is rehearsal money and which part is real protocol state.

  • BTC amounts are testnet; identity, proofs, and rights rules are not “demo mode.”
  • Quotes, finality, BTD rights, and delivery follow production protocol law.
  • Proof readback — not a success toast — decides commercial state.

Disclosure limits

05

Public docs expose guidance and proof posture, not protected source

Public Bitcode docs derive from the active Protocol, package-owned catalogs, route contracts, and source-safe generated artifacts. They can explain usage, measurements, event ids, proof roots, docs links, runbook links, redaction posture, testnet rollout readiness, fee boundaries, and settlement posture.

They must not reveal protected source payloads, raw protected prompts, secret values, provider tokens, wallet private material, or unpaid AssetPack source. Source-bearing AssetPack contents cross to the reader only after settlement and rights transfer.

Why this matters

This keeps the public product understandable while preserving the boundary that makes AssetPacks economically and operationally safe.

  • Allowed: usage guidance, route links, state labels, source-safe measurements, proof roots, dashboard/runbook ids, redacted incident posture, testnet rollout readiness, LocalStagingTelemetryDocumentationRehearsal evidence, and fee/right boundaries.
  • Interface docs may surface event ids, proof roots, docs links, runbook links, and redaction posture from TelemetryDocumentationInterfaceIntegration without revealing source-bearing payloads.
  • Local and staging-testnet rehearsal docs may surface documentation discovery, telemetry event emission, dashboard/runbook lookup, docs QA, incident drill, source-safe proof-root review, and blocked value-bearing mainnet posture.
  • Blocked: secrets, provider tokens, wallet private material, raw protected prompts, protected source payloads, and unpaid AssetPack source.
  • Docs QA fails closed when public docs, internal docs, route docs, interface docs, generated artifacts, proof posture, or workflow checks drift.
  • Compatibility boundaries stay explicit: /exchange redirects to /packs and does not create a parallel current product surface.

Interface preview

Learn with the same UI grammar used in the product

These embedded specimens reuse product card and explainer patterns so docs readers become familiar with Packs, Deposit, and Read before they operate against them.

Component vocabulary

/deposits, /reads, /packs, Protocol, interfaces

The docs use the same card and explainer pattern as the product routes so the mental model transfers into the commercial surfaces.

Packs

Activity and proof readback

Read/Deposit

User paths

Protocol

Rules and proofs

01 / Deposit

Source enters with provenance and repository context.

02 / Read

Demand becomes measurable before fit or settlement.

03 / Read

Every write must produce a proof-readable result.