Skip to main content

Protocol: Overview

This is the normative specification of the DIG Protocol, defined as seven layers, bottom-up. Each layer names its canonical crate/file as the normative reference.

This is the authoritative protocol reference

This section is the source of truth for what the network does. It documents the protocol as it actually runs, with file:line citations to the canonical implementation.

The fundamental unit: the capsule​

One concept runs through every layer: the capsule = (store_id, root_hash), canonically storeId:rootHash. A store is an ordered sequence of capsules (oldest→newest), one per commit; its identity store_id is a CHIP-0035 DataLayer singleton launcher id on Chia. Identity, compilation, pricing, retrieval, caching, and provenance are all defined per capsule.

The thesis: blind host, client-side verify, chain-anchored root​

  • Blind host. A host holds only opaque ciphertext keyed by hashes. It holds no URN and no key, relays the capsule's own output verbatim, and cannot tell a hit from a miss. There is no decoy field on the wire and no CDN — content is served only through the dig RPC.
  • Client-side verify. Every byte is checked on the reader's device against an on-chain root with a per-resource merkle inclusion proof, then authenticated-decrypted. Trust never rests on the serving origin.
  • Chain-anchored root. The trusted root comes only from the CHIP-0035 singleton on Chia (resolved via coinset.org), never from the served "latest".

The seven layers​

#LayerWhat it definesCanonical reference
0Identity & namingstore, capsule, generation; store_id = launcher iddigstore-core::capsule, ::urn
0URN & addressingurn:dig:chia:… grammar; rootless retrieval_keydigstore-core::urn, lib.rs
1CryptographyHKDF KDF; AES-256-GCM-SIV sealdigstore-core::crypto
1Merkle inclusion proofsD5 per-resource leaf; NODE_TAG folddigstore-core::merkle
1BLS signatures & DSTsChia AugScheme; five role DSTsdigstore-crypto::bls
2Capsule formatthe DIGS data section (BINDING D1)digstore-core::datasection
2The self-defending modulefixed-size obfuscation; the serving guestdigstore-compiler, digstore-guest
4On-chain anchoringstore = singleton; capsule = root-advancechip35_dl_coin, digstore-chain
4DIG CAT payment & pricingper-capsule, dynamic, USD-peggedchip35_dl_coin::dig
6The dig RPCthe machine interface (JSON-RPC 2.0)hub retrieval, dig-node
5§21 transport & pushdig:// locator, REST, push v1digstore-remote
7DIG Node peer networkmTLS peer identity, NAT traversal, STUN, introducer, relay wire, peer RPCdig-gossip, dig-relay, dig-nat, dig-node
6Verification & provenancethe four ordered integrity gatesdigstore-core::merkle, dig-node
6The blind host modelprovider-blindness; resolver; /v1 control planehub retrieval/resolver/api
—Conformance & paritythe cross-impl parity disciplinefrozen goldens, OpenRPC diff

(Layers 3 and the §21 transport interleave with the read path; the table groups them where a reader meets them. The full layer numbering is given on each page.)

How a capsule flows through the layers​

A publisher chunks + encrypts (L1) content into a capsule format (L2) that self-serves (L3), anchors it on-chain (L4), and pushes it over §21 transport (L5). Any client reads it through the dig RPC and verifies it against the chain-anchored root entirely client-side (L6). Every cryptographic constant has one definition shared across producer, host, and verifier — the C8 parity invariant.

Terminology​

  • chia:// — the network content address (what a browser opens).
  • dig:// — the §21 transport locator (CLI/peer plane) and the DIG Browser's internal page scheme — two distinct uses, never the content address.
  • urn:dig: — the URN namespace both derive from.
  • store / capsule — the identity and its immutable generation.
  • $DIG — the CAT paid per capsule; dig-store — the store format.