Parameters
Parameters affect the blocks a writer produces (and therefore refs); readers MUST accept any structurally valid value regardless of the writing parameters.
| parameter | default | constraints | what it affects |
|---|---|---|---|
| hash | sha2-256 (code 0x12) | registered multihash function (§3.4, §10.4); output length [20, 64]; fixed per store | every ref |
inlineThreshold | 1024 | integer ≥ 0 | file entries (inline vs raw) |
pageThreshold | 262144 | integer ≥ 4096 | directory nodes (flat vs paged, packing) |
maxChunkRefs | 2048 | integer ≥ 2 | "f" tree fan-out |
chunker | "fastcdc" | names a §9.2 chunker; "fastcdc" is §9.4 under the three bounds below | which algorithm cuts leaf chunks |
chunkMin | 8192 | integer, 1 ≤ chunkMin ≤ chunkAvg | fastcdc minimum chunk length |
chunkAvg | 32768 | integer, a power of two in [16, 2^29], chunkMin ≤ chunkAvg ≤ chunkMax | fastcdc cut widths (§9.4) |
chunkMax | 98304 | integer, chunkAvg ≤ chunkMax | fastcdc maximum chunk length |
chunkMin, chunkAvg and chunkMax are the min, avg and max bounds
of the fastcdc chunker (§9.4); they are ordinary parameters, carried
as three flat integers so that a store's chunking is fully expressible in
its metadata rather than hidden behind the chunker name.
Two writers interoperate at the ref level (produce identical refs for
identical logical content) if and only if they agree on all of these. The
GEAR table and cut rule (§9.4) and the segment-boundary predicate with
SEG_MASK (§8.2) are not parameters — they are format constants. So are
the CID constituents (§4): CID version 1, codec raw for chunks and
dag-cbor for nodes (§13.1).
Note that IPLD at large has no canonical CID for given content: the same bytes acquire different CIDs across CID versions, codecs, hash functions, chunkers, and DAG layouts, and generic tooling promises none. Within this format, canonicality is precisely this profile — the parameters above plus the canonical rules of §5–§9 and §13.1 — which is what makes "same content + same parameters ⇒ same CID" hold.
Changing parameters on a live store is read-safe but forks ref identity. Readers accept blocks written under any parameters, so existing data stays readable — but the same logical content, re-written under different parameters, yields different refs. Deduplication — and the determinism contract "same content ⇒ same ref" (§13.1) — therefore holds only within one parameter set. Every parameter above is expressible and recorded in the store metadata key (§10.3). Writers SHOULD read them and match them rather than assume defaults. Two stores whose chunking differs therefore differ in their recorded metadata — a store's refs are never explained by a parameter it could not state.