00 / Start HereAssetPacks

AssetPacks, BTD, and the Bitcode activity ledger

Learn the value model first: Bitcode measures technical source into AssetPacks, BTD scalar volume and rights, and BTC-settled delivery.

This guide is for first-time readers who read the simple model before using the product routes: source supply comes in, demand is measured, fit and proofs decide what can move, and settlement makes attribution readable.

After reading

You can describe an AssetPack, identify what gets measured, and understand why proof-backed BTC settlement and BTD rights matter.

AssetPacks

01

What Bitcode measures and what it withholds

Bitcode turns permitted technical source into tradable, measured intelligence — not inert file attachments and not unprotected source dumps.

Code, files, designs, data, notes, and repository context enter as supply. Bitcode synthesizes AssetPacks, scores needs-fits, and exposes measurements and proof roots on the market path. Protected IP stays behind obfuscation and rights gates until settlement unlocks delivery. Seller view: permitted source, obfuscations, synthesized pack. Buyer view: measurements, needs-fits scores, knowledge volume.

Why this matters

An AssetPack is only credible when source posture, demand measurement, proof, BTD volume/rights, and BTC settlement can be reread together without leaking unpaid source.

  • Supply is deposited as measured, listed IP you approve.
  • Demand is a Reading that becomes needs-fits scores and quotes.
  • Settlement finality and BTD rights decide whether pack contents may deliver.

Packs

02

Packs

Inspect network AssetPack activity: measurements, needs-fits, settlement, compensation, delivery, and repair — without exposing unpaid source.

Open /packs when you need the master-detail ledger of deposited and settled AssetPacks. Search and filter source-safe activity; expand a row for proof roots, BTD volume/rights, BTC posture, and delivery state. Protected source stays withheld until paid rights unlock delivery.

Why this matters

The Packs ledger introduces network activity without forcing a first-time reader into raw proof artifacts.

  • Master table of source-safe pack activity across the network
  • Detail panels for proofs, settlement, compensation, delivery, and repair
  • Never serializes protected IP before settlement and rights transfer

Value flow

03

Deposit → Read → Fit → Prove → Settle → Deliver

For a new reader the market path is linear: list supply, measure need, compare fits, produce proofs, settle in BTC, transfer BTD rights, deliver knowledge.

/deposits, /reads, and /packs each expose stages of that chain so operators can see both the write that changes state and the read surface that proves what happened next. Interfaces must preserve the same chain.

Why this matters

The linear path is the teaching model. The underlying system is richer, but every advanced interface still has to honor this order of truth.

  • Deposit writes searchable, source-safe supply.
  • Read writes measured demand and settlement for delivery.
  • Packs rereads proof-backed BTC finality, BTD rights, compensation, and delivery posture.

Disclosure limits

04

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.

Product specimen

AssetPack status card

This mirrors the compact status cards used on product routes: supply, Read, fit, and proof as related signals.

Supply

Repository-backed

Read

Measured and reviewable

Settlement

BTC + BTD rights staged