We would like feedback on ERC-8326 — Canonical Document Bundle Anchor, a draft ERC for deriving and anchoring a deterministic commitment to a bundle of off-chain documents.
Update — July 09, 2026: ERC number has been allocated. The ERC remains in Draft status and may change based on review.
Formal ERC PR: ethereum/ERCs#1854
Spec file: ERCS/erc-8326.md
Applications frequently commit to agreements, certifications, evidence, amendments, and supporting records. Hashing each file is not enough to make a bundle interoperable: implementations can still disagree about entry fields, ordering, normalization identifiers, version separation, duplicate handling, and replacement history.
ERC-8326 separates two layers:
- A normalization profile transforms a raw document into canonical bytes.
- A manifest describes, orders, and hashes commitments to those bytes.
Each manifest entry contains five fixed-width fields:
struct DocumentEntry {
bytes32 contentHash;
bytes32 role;
bytes32 mimeTypeHash;
bytes32 filenameHash;
bytes32 normProfileId;
}
Entries are ordered lexicographically by role, filenameHash, contentHash, mimeTypeHash, and normProfileId. Equal entries remain duplicated, so the bundle is a multiset rather than a set. Each entry is hashed, and the ordered leaves are committed under a versioned schema identifier to produce one bytes32 bundle hash.
The base profiles cover raw bytes, RFC 8785 JSON canonicalization, and Canonical XML 1.1 without comments. JSON and XML normalization occurs off-chain; the Solidity library hashes supplied entry fields and cannot prove that a caller correctly applied a profile. PDF and image documents typically use the raw-bytes profile (PROFILE_RAW) unless deployers agree on a custom normalization profile.
The on-chain interface anchors a bundle in a (subjectId, role) slot. A slot has at most one active bundle, while supersession preserves the previous record and a forward pointer to its replacement. An optional recovery extension allows an administrator to reassign a contested slot principal without rewriting anchored history.
Scope boundaries
ERC-8326 standardizes manifest construction, bundle-hash derivation, and anchor lifecycle. It does not prove:
- document authenticity, provenance, legal effect, or correctness;
- correct application of a normalization profile;
- continued availability of the committed documents or metadata URI; or
- membership proofs for individual documents without reproducing the manifest.
The construction commits to the complete ordered manifest. It intentionally does not prescribe a Merkle tree.
Questions for review
- Are the manifest fields and five-field total order sufficient to eliminate hidden ordering ambiguity?
- Should the JSON and XML normalization profiles remain normative in ERC-8326, or should profiles live in independently versioned companion documents?
- Is retaining duplicate entries the right default, or should exact duplicates be rejected?
- Is
(subjectId, role)an appropriate namespace for one active bundle and an append-only supersession history? - Should slot-principal reassignment remain an optional recovery extension?
- Is a complete-manifest hash preferable as the base primitive, leaving Merkle membership proofs to a separate extension?
Implementation status
A Solidity reference implementation, hashing library, and test suite is available in the reference repository.
An example UI suite is also available for non-normative exploration of the interface and its role in the broader titled-asset standards family.
The audited reference commit is caa9b05. It includes unit, fuzz, and Medusa property tests. The implementation has also been reviewed in an independent Verichains audit.
ERC-8326 is independently deployable. It was introduced alongside five other standalone draft ERCs in the architecture discussion, but it does not depend on an asset registry or any other draft in that family.
Authorship
Chris Turner, David Hay (LinkedIn), Reagan Simpson, and Collins Musyimi.
Developed at Kula, which builds infrastructure for regulated virtual-asset and titled-asset use cases. Reference implementations are open-source; we are proposing ecosystem interfaces, not a Kula-only stack. We are open to additional co-authorship and community contribution beyond Kula.
