Catalog Provenance Registry (CPR)

Public Description and Whitepaper

Working title: Catalog Provenance Registry (CPR)
Working URL: catalog.org/cpr/
Last updated: 2026-05-18
Author: Roberto Bourgonjen
Copyright: © 2026 Roberto Bourgonjen. All rights reserved.
Project: Catalog CPR
Supersedes: Catalog Asset Registry Whitepaper (2026-05-08)

1. Overview

The Catalog Provenance Registry (CPR) is a long-term digital provenance service for registering signed claims about digital files. CPR is designed to provide durable proof that a claim existed at or before a certain time, while keeping the cost per operation low enough for routine use in creative and archival workflows.

CPR is operated by a federated network of Operator nodes. Each node maintains its own block chain, accepts claims independently, and anchors its own blocks to the XRP Ledger (XRPL). Nodes replicate blocks and claims from peers, so that any node can verify any claim regardless of where it originated. This combines low-cost storage and structured retrieval with independent public timestamping and resilient federated preservation.

CPR is one module of Catalog, an integrated suite of applications for creatives and other intellectual-property producers — operating alongside Catalog.ID (identity), Bitcash (payments), mail, chat, metadata management (Catalog Management System, CMS), and file storage and delivery (Encrypted Filestorage) — but it can also be used on its own. CPR doubles as the suite's rights-management substrate: because every AssetID is bound to an owner key (the current owner of its licence; see §8.2.0) and may be further bound to additional roles via attribution claims, downstream modules use those bindings as authorization signals (§6.1). Catalog was created by Roberto Bourgonjen, who brings over twenty years of professional experience as an application developer for major institutional archives in the Netherlands. Catalog was engineered from the ground up — after his retirement from business, as a private undertaking — for massive, global scale, built on archival practice proven at national scale, while its usability and feature set were shaped around the founder's own needs as an active photographer, musician, and software developer managing a lifetime of work.

CPR is intended for use cases such as:

• photography and tethered capture workflows
• video production and post-production
• music and audio production
• digital publishing
• archival preservation
• provenance registration for creative works
• timestamped authorship and participation claims
• derivative-file lineage tracking
• large-scale archive onboarding via batch import
• registry anchoring: timestamping external registry state (e.g., Catalog.ID claim operations)
• per-claimant claim chaining for sequential completeness proofs

CPR records claims. It does not by itself adjudicate truth, legal title, or authenticity in a final legal sense.

1.1 Blockchain agnosticism

CPR is itself blockchain agnostic. It maintains its own block chain internally and links this to an external blockchain for independent public timestamping. The criteria for selecting an external anchoring ledger are:

• Transaction cost: transactions must be cheap (sub-cent) so that routine block anchoring remains economically viable at scale.
• Validation redundancy: third-party libraries and services to validate a transaction should be redundantly available and not dependent on a single party.
• Local node feasibility: it must be economically possible to run a full-history local node, for optimal query response times and to avoid dependence on third parties or the continuity of the blockchain for future validations.
• Project continuity: the continuity of the blockchain project should be backed by organizations that are well funded and have a clear incentive for continuation of the blockchain.

Currently these factors have led to use of XRPL as the timestamping ledger, but at a later time other blockchains may be added for redundancy. The CPR project is not affiliated with or funded by Ripple; XRPL was selected solely on the technical and economic merits listed above.

2. Post-Quantum Security

CPR is designed to be post-quantum secure at the claim and archive layer.

2.1 What this means

• Client claim signatures must use a post-quantum signature scheme.
• Internal block signing and archival attestations should use post-quantum signatures.
• Encrypted optional payloads, if supported in a future version, must use a post-quantum key encapsulation mechanism (KEM).
• The system must be crypto-agile so algorithms can be upgraded over time.

In August 2024, NIST approved FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) as post-quantum cryptography standards.

2.2 Recommended default algorithms

For CPR v1:

• Claim signatures: ML-DSA-65 (FIPS 204)
• Conservative archival signatures: SLH-DSA-128s or similar profile (FIPS 205)
• Optional confidential payload encryption: ML-KEM-1024 (FIPS 203)
• Hashing: SHA-512 for file and object digests

These choices may be revised in future CPR protocol versions.

2.3 XRPL anchoring caveat

XRPL currently supports Ed25519 and secp256k1 key types for ledger transaction signing. These are not post-quantum signature schemes. CPR therefore treats XRPL as an external timestamping and publication anchor, not as the post-quantum trust root for claim signatures.

In practice:

• The claim itself is post-quantum signed.
• The hourly block can also be post-quantum signed off-chain by CPR operators.
• The XRPL transaction provides an additional public timestamp anchor, but is not itself the post-quantum security primitive.

3. Design Goals

CPR is designed to satisfy the following goals:

1. Proof of existence
   A signed claim should be provably shown to have existed no later than the time at which its containing block was anchored.

2. Long-term durability
   Claims and block manifests should remain reproducible, portable, and verifiable for decades.

3. Low operational cost
   Read and write operations should be cheap enough for large-scale routine usage.

4. Structured provenance
   CPR should support master files, derivative files, lineage, and successive claims over time.

5. Minimal immutable data
   The immutable claim format should avoid arbitrary free text and unnecessary personal data.

6. Independent verification
   Third parties should be able to verify a file, a claim, a manifest, and a block independently.

4. Core Concepts

4.1 AssetID, Catalog Asset Licence, and asset

An AssetID is the unique identifier of a Catalog Asset Licence: a 12-character alphanumeric string in the format four lowercase letters, four digits, four lowercase letters (e.g., qjrm4821xwpa). The AssetID is the name of a licence; it is not itself the object of ownership and it does not designate any specific work or object in the world.

A Catalog Asset Licence (CAL) is a permanent, freely assignable contractual right, issued by a CPR operator to a buyer in exchange for a fixed fee (1 BIT per CAL; see §8.2.2). It grants its owner the right to:

• submit registration, attribution, structural, and ownership-rebinding claims against the AssetID through the CPR registry;
• associate files, metadata, descriptions, and other content with the AssetID through Catalog modules (Encrypted Filestorage, CMS) that consult the registry for owner resolution;
• issue and revoke content licences through the Licensing Agent on encrypted material registered against the AssetID;
• register, detach, and re-register Catalog Physical Object Markers (POMs) against the AssetID (see §18);
• reassign the CAL to any other party at any time by signing an ownership-rebinding registration claim (see §6.2).

The full terms of a CAL are set out in the CPR Terms. The owner of a CAL is the key holder named in the home operator's internal record (see §8.2.0); ownership changes through ownership rebinding (§6.2).

An asset is the logical work or provenance family that a CAL owner chooses to associate with one AssetID through claims, files, and metadata. An asset may include one master file and many derivative files; may correspond to a born-digital work, a digitised physical original, an abstract collection, or an entirely empty CAL with no content yet. CPR has no opinion about whether an AssetID corresponds to any specific real-world or conceptual object; the connection is constructed by the CAL owner through deliberate acts (claims, file submissions, attribution, attachment of a physical POM), not enforced by the registry.

The relationship between an AssetID and any real-world object is therefore optional and one-directional: an AssetID can exist without any real-world counterpart; a real-world object can exist without any AssetID; when a real-world object is associated with an AssetID through file submissions or a POM, the association is a record-keeping act by the CAL owner. Real-world objects may be physically anchored to an AssetID through a Catalog Physical Object Marker (POM, §18), the network's tamper-evident physical label.

AssetID lifecycle states

An AssetID has two distinct lifecycle states, and the difference between them is operationally significant for downstream Catalog services:

• Purchased. The home operator (§8.2.0) has issued a license receipt (§8.2.3) binding the AssetID — or a contiguous range of AssetIDs — to a licensee's public key (the AssetID licence's initial owner key). The receipt is held privately by the licensee. The home operator's CPR node has already recorded the licensee internally and can answer ownership queries for the AssetID immediately, before any registration claim has been submitted. Other federation nodes do not yet hold a registration for the AssetID and cannot answer federated verification queries about it. In this state the licensee may embed the AssetID into local files and metadata as part of offline preparation — tagging captured images, drafting descriptive metadata, editing derivative files — and downstream Catalog modules (Encrypted Filestorage, CMS) that route ownership queries to the home operator (§6.1, §8.2.0) may accept submissions signed by the licensee's owner key.
• Registered. The licensee has submitted any claim against the AssetID — a registration, an attribution, a pom_registered, a structural claim, or any other accepted claim type — and a node has accepted it into a block (§4.6). The AssetID is now visible in the federation's records: any node can serve verification queries about it, anchors propagate via XRPL, and external citers can refer to the AssetID with a stable, network-known meaning. The transition is independent of whether any files have been registered against the AssetID: a CAL whose first on-chain event is a pom_registered claim anchoring a physical object (CPR §18.5) is "Registered" from that block forward, even with no registration claim and no file state. The ownership decision path for downstream modules continues to resolve through the home operator (§8.2.0). Subsequent ownership rebindings (§6.2) update the home operator's view immediately and propagate to peer nodes for federated verification.

The distinction means a purchased AssetID is owner-bound and operable through downstream modules that consult the home operator, but it is not yet federation-visible. A registered AssetID is owner-bound, operable, and visible to federated verification queries against any node. AssetID licences are issued in batches (§8.2.2) precisely so that offline-prep work — capture, tagging, drafting — can proceed long before any network call is made; the registration call submits a batch of finished assets at once when connectivity is available.

4.2 File

A file is one exact binary object, identified by its digest and its file UUID.

4.3 Claim

A claim is a signed statement submitted to CPR, identified by its claim_id — a composite string in the format {asset_id}.{operator_id}.{sequence} (see §8.1.2). CPR defines six claim types:

• Registration: records that a work exists and what files belong to it. A registration describes the files, their technical properties, and derivation relationships. It does not include attributions — those are recorded separately (see §4.8). A registration is always a complete snapshot of the asset's file state. Subsequent registrations on the same asset supersede previous ones. A registration may be signed by any key — the submitter does not need to prove membership of the Catalog.ID network; only payment is required. Registration claims require either a license receipt establishing the submitting key as the AssetID's initial owner key (for the first registration; see §8.2.3) or that the submitting key match the AssetID's current owner key as resolved by the home operator (for subsequent claims, after ownership rebinding; see §6.2).
• Attribution: records that a person participated in a work in one or more roles. Each attribution is a separate signed claim referencing the asset. Attributions must be signed with a published (non‑anonymous) CPR signing key that is registered to a Catalog.ID account (see §16.2a). The CPR node verifies at submission time that the signing key is a published, non‑revoked cpr_signing_key claim on the claimant's account. See §4.8.
• Revocation: withdraws a prior claim. A revocation is a negative assertion: "I retract my previous statement." It carries no files and no parties. A revocation must reference the claim being revoked, and the signing key must match the signing key of the revoked claim.
• Registry anchor: allows external registries to timestamp their state by submitting a Merkle root to CPR. This type has a different structure: no files, no parties, no file creation time (see §17).
• POM registered (pom_registered): binds a previously unregistered Catalog Physical Object Marker serial to an AssetID. Signed by the AssetID's current CAL owner key. See §18.5.
• POM detached (pom_detached): releases the binding so the POM serial returns to "registrable" state and may later be registered against a different AssetID. Signed by the AssetID's current CAL owner key. See §18.8.

The claim type describes the event being recorded. A registration with a supersedes_claim relation is a correction. A registration with a child_of relation places the asset under a parent in the asset hierarchy (see §4.11). Roles are expressed through separate attribution claims (see §4.8), not embedded in the registration.

4.4 Manifest

A claim manifest is the canonical structured object signed by the client and submitted to CPR. For registrations, the manifest describes the asset, files, timestamps, and relationships — and may be signed by any key. For attributions, it describes one party and their roles on an asset — and must be signed with a published CPR signing key registered to a Catalog.ID account (see §16.2a). Each manifest type is independently signed, included in blocks, and anchored.

4.5 Node

A node is one CPR federation member operating its own instance of the service. Each node has a unique identity: a 4-character opaque Operator ID from a reduced charset excluding visually confusing characters (e.g. b4np) that maps to a subdomain (e.g. b4np.catalog.org), a jurisdiction (ISO 3166-1 country code), its own operator key pair, and its own block chain. A node accepts claims directly from claimants and replicates blocks and claims from peer nodes. Since claims are replicated, any node can serve verification for any claim in the network.

4.6 Block

Each node groups its accepted claims into time-bounded blocks, for example hourly blocks. Each block includes the digest of the previous block, forming a per-node append-only chain. A block is globally unique by the combination of node identity and block number.

4.7 Anchor

Each node anchors its own block digests to the XRP Ledger. The XRPL transaction provides an independent public timestamp and an external integrity reference.

4.8 Attribution Model

The party of an attribution is the person or entity being attributed, identified by their Catalog.ID username. Parties are not embedded in registration claims. Instead, each party is recorded in a separate attribution claim — a full signed transaction that is included in blocks, anchored to XRPL, and replicated across the federation.

Each attribution specifies:

• catalog_id: the party's Catalog.ID username (e.g. khu3758iop)
• roles: one or more roles from a defined industry-specific enum (e.g. photographer, rights_holder, composer, publisher_entity)

The Catalog.ID username is a 10-character pseudonymous identifier in the format abc1234efg. It is not chosen by the member — it is a deterministic encoding of an internal sequence number, analogous to a telephone number assigned by a carrier. The encoded form carries no semantic content about the person; the mapping to personal data exists only within the encrypted Catalog.ID system (see §7.2 for data protection classification).

Attribution signing requirement. Attribution claims must be signed with a published (non‑anonymous) CPR signing key registered to a Catalog.ID account. The CPR node verifies at submission time that the signing key matches a published, non‑revoked cpr_signing_key public claim on the claimant's Catalog.ID account. This provides a cryptographically verified link between the attribution and the claimant's Catalog.ID username. Claims signed with anonymous keys, unregistered keys, or revoked keys are rejected.

Registration signing is unrestricted. Registration claims (file manifests) may be signed by any key — the submitter does not need to prove Catalog.ID membership. The submitter can use a published CPR signing key, an anonymous CPR signing key registered to a Catalog.ID account, or any other key entirely. Only payment is required. This makes CPR accessible to non‑Catalog.ID users (applications, institutions, archival systems) and supports anonymous file registration.

CPR defines a comprehensive set of roles covering photography, film and video production, music and audio, publishing, visual arts, graphic design, architecture, fashion, games, software, journalism, advertising, academic research, and production and business roles. See the Claim Manifest Specification for the complete role enum.

4.9 Two‑Sided Attribution

Attribution claims can be signed by different parties, creating a spectrum of attribution strength:

• Claimant‑asserted: The original claimant (e.g. the photographer who registered the files) submits an attribution for another person. The party has not yet confirmed.
• Self‑asserted: The party submits their own attribution claim, asserting their own role. The original claimant has not confirmed this assertion.
• Mutual: Both the claimant and the party have submitted attribution claims for the same party with matching roles. This is the strongest form of attribution.
• Divergent: The claimant and party have submitted attributions with different roles. This is a soft disagreement that is visible in the record without requiring a formal dispute.

This model replaces the previous lightweight attestation mechanism. Because each attribution is a full signed transaction included in blocks, it provides stronger timestamping and verifiability than attestations, which were metadata stored alongside claims but not included in blocks.

The binding between a CPR signing key and a Catalog.ID username is verifiable because attribution keys must be published as public claims on the member's Catalog.ID profile, validated through key control proof (see §16.4 and Catalog.ID Whitepaper §7.6).

4.10 Snapshot and Incremental Models

Registration claims follow a snapshot model for files: each registration is a complete snapshot of the asset's file state. To change the file set — add a file, remove a file, update file metadata — the claimant submits a new registration with a supersedes_claim relation containing the full updated file state.

Attributions follow an incremental model: each attribution is an independent claim that can be added, superseded, or revoked without affecting the file registration or other parties' attributions. The current parties for an asset are determined by aggregating all non-revoked attributions.

The current file state of an asset is the latest non-revoked registration in each signer's chain. If multiple signers have registered claims on the same asset, those are independent (potentially competing) claims — which is exactly what CPR is designed to record. Attributions from different signers coexist independently.

4.11 Asset Hierarchy

Some works are composite. An encyclopedia contains volumes; each volume contains page scans. An album contains tracks. A fonds contains series, sub-series, and items. CPR models this through a single hierarchy primitive, the child_of claim relation, deliberately kept minimal and free of archival or domain vocabulary. Descriptive vocabulary such as fonds, series, album, track, or page lives in the CMS where it can be revised. CPR records only the structural fact of parent/child membership and the rules necessary to make licence ownership and its transfer well-defined across the hierarchy.

Single parent, no cycles. A child AssetID has at most one active parent at any time. Multi-parent membership (for example, a track that appears on a master album release and on a separately released compilation) is a Catalog-layer concern. Such membership is recorded as a non-cascading member_of_collection relation in Catalog metadata and is not modelled in CPR. CPR rejects a child_of claim whose acceptance would create a cycle, and rejects a second child_of on an AssetID that already has one active.

Mutual exclusion of root and child states. A registered AssetID is in exactly one of two states at any time:

• Root. The AssetID has an explicit owner key and no parent. Its registration and subsequent rebinding claims directly establish and update the owner key.
• Child. The AssetID has a parent and no explicit owner key of its own. Its effective owner is resolved by walking to the root and reading the root's current owner key.

The assets row carries owner_key_fingerprint (the owner key fingerprint of the AssetID licence) exactly when the AssetID is a root, and parent_asset_id exactly when the AssetID is a child. Both fields are never populated simultaneously, and an AssetID never holds neither outside the atomic detach-with-new-owner claim described below.

Shared-owner invariant at attachment. A child_of claim is accepted only when the registration is signed by a key that is also the parent's current effective owner. This invariant is enforced at submission time on the initial registration of a child, on re-attachment after detachment, and on any operation that would otherwise produce a hierarchy with mixed ownership. CPR therefore guarantees, structurally, that every node in a connected hierarchy resolves to the same effective owner. The receipt-named licensee key on a child AssetID must equal the parent's effective owner at the moment of initial registration. After that gate, the receipt has done its job; the child's ongoing ownership tracks the root.

Cascading ownership rebinding. Because effective ownership is resolved from the root, a single rebinding claim on the root transfers the licences of every descendant in the same block, with no per-descendant claim and no per-descendant fee. The cost of transferring a hierarchy is independent of subtree size. Descendants are not rewritten by the rebinding; the rebinding updates the root's owner key, and subsequent effective-owner reads on any descendant return the new key from that block forward. The new owner key becomes the effective owner for every CPR-side authorization check (further rebinding, further child_of additions, license-issuance authority via the Licensing Agent) on every node in the subtree, effective from block acceptance forward.

Re-parenting and detachment. A registration claim on a child AssetID can take one of two legitimate forms that change its hierarchy state, plus a third that is rejected:

• Re-parent. The claim supersedes the prior registration and replaces the child_of target with a new parent. The AssetID stays in the child state throughout. The signer is the child's current effective owner, which (per the shared-owner invariant) must also equal the new parent's effective owner. Because no ownership change occurs, no detach step is required, regardless of how deep in the hierarchy the move occurs. The new parent may belong to the same connected hierarchy as the old parent (for example, moving a page scan from one volume to another within the same encyclopedia), or to a different hierarchy under the same owner key (for example, moving a track from one album to another, both held by the same label).
• Detach. The claim supersedes the prior registration, omits the child_of relation, and specifies a new explicit owner key in the registration body. The AssetID transitions from child state to root state in a single atomic claim signed by the current effective owner. The atomicity prevents a child from ever being observable in an unparented, unbound state, and prevents the silent failure mode where ownership of an orphan defaults to a stale value cached at the moment of initial attachment.
• In-place owner change (rejected). CPR rejects any claim that attempts to set a new owner key on an AssetID while leaving its child_of relation intact. The owner key bound to a child can change only through a rebinding of the root (cascading through the subtree) or through detachment.

Re-attaching a previously detached AssetID under a new parent follows the standard attachment rule: the AssetID's current explicit owner key must equal the new parent's effective owner at the time of the attachment claim.

Scope: structural only. The hierarchy primitive records structural parent/child membership and nothing else. Archival level vocabulary (fonds, series, sub-series, file, item), domain structural vocabulary (album, disc, track; encyclopedia, volume, chapter, page; franchise, series, season, episode), and ordinal sequence within a parent are CMS concerns. They are mapped to standards-specific projections (MDTO aggregation, RiC RecordSet and Instantiation, EAD hierarchy levels, CIDOC-CRM/Linked Art object groupings) at the CMS layer. CPR does not interpret or enforce these labels.

Limited editions and multiples. The hierarchy primitive is the recommended pattern for editions, print runs, pressings, castings, and other cases where a single conceptual work exists in N physical copies. The edition is a parent AssetID carrying descriptive metadata about the work (title, year, artist, total edition size); each physical copy is a child AssetID attached to the parent via child_of, optionally anchored to the physical copy through its own Catalog Physical Object Marker (POM, §18). Once all copies are minted, the parent CAL is typically locked (§8.2.5) so no further children can be attached, sealing the edition count at exactly N. Individual copies remain independently transferable: selling one copy is a detachment (§4.11 detach with new owner key) of that child AssetID; selling the entire edition is a rebinding of the parent (§6.2 cascading rebinding). Multiple POMs registered against a single AssetID (§18.9) are intended for composite single objects and redundant anchoring, not for editions; modelling an edition by stacking POMs on one AssetID is technically possible but is not the recommended pattern, because it conflates the copies into a single non-divisible CAL and forecloses independent per-copy transfer.

5. Trust Model

CPR does not ask the public to trust a single database operator blindly. Instead, it separates trust across layers:

• Client signature layer: the claimant signs the manifest
• Node operator layer: the accepting node signs the block with its operator key
• CPR block-chain layer: each node's blocks reference the previous block digest
• Replication layer: peer nodes independently verify and store replicated blocks and claims
• XRPL anchor layer: each node's block digests are externally timestamped on a public ledger

A verifier does not need to trust any one node or statement in isolation. The verifier can examine the signed claim, the origin node's block, the per-node chain of blocks, peer replicas, and the public ledger anchor.

6. What CPR Proves

CPR is designed to prove the following:

• a structured signed claim was submitted
• the signed claim was accepted into a specific CPR block
• that block existed no later than the time it was anchored to XRPL
• the referenced file digests were part of the submitted registration claim
• attributions were signed by identified parties at recorded times
• whether attributions are claimant-asserted, self-asserted, or mutual

CPR does not by itself prove:

• that the claimant was the true author
• that the claimant held lawful title
• that a file was first created at the asserted file creation time
• that no competing claimant exists
• that a claimant-asserted attribution is accurate (unless the party has submitted a matching self-asserted attribution)

CPR is therefore best understood as a registry of timestamped signed claims, not a court and not an oracle of absolute truth.

6.1 Authorization Signals for Downstream Services

CPR does not adjudicate rights, but the cryptographic primitives it maintains — license receipts binding AssetIDs to owner keys, attribution claims binding parties to roles — are used by other Catalog modules as authorization signals. This makes CPR the foundation of a federated rights-management substrate, even though the registry itself does not enforce or interpret access policy.

Registry control. Registry control means authority to submit future CPR claims for an AssetID. It does not by itself establish legal title in any work registered through the AssetID, copyright ownership, authorship, or exclusive rights in content. Those are matters of substantive intellectual property law, addressed by attribution claims (§4.8), agreements outside CPR, and applicable law.

Downstream modules act on three CPR signals:

• Owner key (write authorization). The current owner key for an AssetID is whichever key is currently named as the AssetID licence's owner by the home operator's internal record. This reflects the initial licence issuance (the public key named in the license receipt at purchase time) plus any subsequent ownership rebinding claim (§6.2). Encrypted Filestorage and the CMS require a write request signed by the current owner key. They do not consult receipts or registration claims themselves; they resolve current ownership by querying the AssetID's home operator's CPR node, or by verifying a short-lived signed ownership attestation issued by that operator. The home operator's resolution is the single, authoritative answer (§8.2.0).
• Role-bearing attribution claims (delegated authorization). Attribution claims (§4.8) bind Catalog.ID parties to roles on an asset. Some roles are operationally significant for downstream modules — e.g., rights_holder, publisher_entity, editor, or a delegate role designated by the owner — and may grant write access alongside the owner. Downstream modules learn about role-bearing attributions by querying the registry. The interpretation of which roles confer which permissions is the downstream module's policy choice; CPR simply records the claims and their signatures. Two-sided attribution (§4.9) lets the owner and the party each assert the role independently, raising the trust strength of the binding.
• Registration state (federation visibility). Registration is the signal that an AssetID has entered the federated record and is visible to verification queries network-wide. Downstream ownership decisions resolve through the home operator regardless of registration state (§8.2.0); registration is required for federation-wide presence, not for the home operator's ability to authorise writes.

CPR therefore acts as a rights-management primitive, not a rights-management system. The distinction matters:

• The registry records licence ownership and role bindings, durably and verifiably.
• The registry does not enforce access. EFS and AIM (and any future modules) interpret the records to gate their own operations; if those modules choose to grant write access on different criteria, CPR takes no position.
• The registry does not adjudicate disputes about licence ownership, assignment, or roles. Conflicting receipts or attribution claims surface as visible disagreements (§4.9) for human or institutional resolution.

This positioning intentionally separates binding (the registry's job) from enforcement (the downstream module's job), so that the same registry primitives can support multiple authorization policies — strict owner-only, owner-plus-delegates, role-derived ACLs, license-token derived from attribution — without re-engineering the registry layer.

6.2 Ownership Rebinding

The owner key bound to an AssetID is not fixed for the lifetime of the AssetID licence. The current owner can transfer the AssetID licence by signing a registration claim whose body names a new owner key. CPR treats this as a normal claim: the previous owner key signs it, the federation anchors it in a block, and from that block forward the registry accepts claims signed by the new owner key and rejects claims signed by the previous one for that AssetID. No new claim type and no novel mechanism are required; the existing claim-chain ordering carries it. Subsequent writes by the previous key are rejected on the standard current-owner check that gates every claim.

The licence follows the owner key. At the registry layer, CPR does not distinguish between two different real-world events that both produce a rebinding: (a) the same licensee rotating their own owner key (after compromise, device replacement, or recovery-kit reconstitution), and (b) the AssetID licence being assigned to a different party (sale through Asset Market, gift, inheritance, institutional accession, court-ordered reassignment). Both produce the same on-the-wire claim and the same registry effect: from the rebinding block forward, the named key holder is the AssetID licence's current owner and, by operation of the CPR Terms (§15), the current licensee. Rebinding does not by itself transfer any copyright, authorship, or substantive rights in works registered against the AssetID; it transfers registry control over the AssetID only. The CPR Terms permit the licensee to assign the licence freely by rebinding, without operator consent.

Implicit tandem transfer of associated real-world assets. Real-world assets — digital files, physical artworks, recordings, manuscripts, archives, scanned objects — are associated with an AssetID through claims and packages (registrations naming files in EFS, attribution claims naming roles, CMS metadata, custody records), but they are not themselves the AssetID. CPR transfers only the AssetID licence. In commercial practice, however, transfer of the AssetID licence frequently coincides with transfer of ownership in the associated real-world assets: a label that sells the master AssetID for an album typically also conveys the recording rights; a museum that accessions a digitised collection typically also receives the physical collection; an estate that inherits a photographer's archive typically inherits both the AssetIDs and the prints. This implicit tandem transfer is a matter of the external commercial or legal arrangement (the bill of sale, the deed of gift, the donor agreement, the will), not a CPR-layer rule. CPR records only the AssetID licence assignment; the corresponding real-world transfers, where they exist, are governed by, and evidenced through, instruments outside CPR. Parties to a substantial transfer should document the wider arrangement explicitly rather than rely on the rebinding alone.

When explicit acceptance from the new owner matters — for sales with attached obligations, transfers of regulated material, gifts to estates that may or may not yet be willing recipients, transfers of records subject to retention or compliance regimes — the two-sided attribution pattern (§4.9) applies in the same shape. The previous owner asserts the rebinding; the new owner countersigns over the same claim body. The bidirectional record carries non-repudiation on both sides. For unproblematic cases (a settled sale through Asset Market, a unilateral gift to a known recipient, a routine inheritance), the unilateral form is sufficient and the new owner's first signed claim against the AssetID is itself implicit acceptance.

Existing downstream state survives rebinding by default. Content licences issued before the rebinding remain valid: they are bilateral records signed under the previous owner's authority and the recipient's acceptance, and the rebinding does not invalidate either signature. Encrypted Filestorage continues to honour them through the Licensing Agent's standard verification flow. The new owner inherits the right to issue further content licences, to revoke or extend pre-existing licences going forward, and to make any further binding decisions. Catalog modules that consult CPR for the current owner see the new owner key from the rebinding block forward; they do not re-evaluate prior claims under the new owner's signature.

The mechanics are the same whether the rebinding is a sale, a gift, an inheritance, an institutional accession that includes IPR transfer, or a court-ordered reassignment. What differs across these cases is the policy and evidence layer captured in the CMS (AccessDecision, transfer agreement, donor instrument), not the CPR primitive.

Cascading rebinding through hierarchy. When the rebound AssetID has descendants under the AssetID hierarchy (§4.11), the new owner key becomes the effective owner of every descendant in the same block, by inheritance. No per-descendant claim and no per-descendant fee is required, and the cost of transferring a subtree is independent of its size. The mechanism is the same single rebinding claim used for a flat AssetID; only the resolution path differs, because descendants do not store their own owner key and resolve to the root on read. CPR rejects in-place ownership changes on a child AssetID (a claim that would name a new owner key while keeping child_of intact); to rebind a single child AssetID under a different owner key, the current effective owner submits a detachment claim that simultaneously clears child_of and names the new explicit owner key (§4.11). Moving a child AssetID between parents that share an effective owner is a re-parenting and not a rebinding; it requires no detach and no rebinding claim.

7. Privacy Posture

CPR is intentionally narrow in what it stores immutably.

The core immutable claim format should contain only structured identifiers, timestamps, digests, cryptographic material, and pseudonymous party identifiers. Arbitrary free text should be excluded from the immutable claim body.

7.1 Prohibited data

As a default policy, CPR must not store in immutable claims:

• filenames
• paths
• email addresses
• human names
• captions
• notes
• postal addresses
• phone numbers
• free-form metadata

Where additional metadata is needed operationally, it should be stored separately in mutable systems governed by separate policies.

7.2 Pseudonymous party identifiers and data protection classification

CPR claims may include Catalog.ID usernames (e.g. khu3758iop) as party identifiers. These are pseudonymous identifiers within the meaning of GDPR Article 4(5). This section sets out their data protection classification and CPR's lawful basis for processing them in the immutable layer.

7.2.1 Usernames as service infrastructure

A Catalog.ID username is a compact encoding of an internal sequence number produced by a deterministic encoding algorithm — analogous to a telephone number assigned by a telecommunications carrier. The username namespace — the set of all possible usernames, the format in which they are expressed (abc1234efg), and the algorithm that generates them — is a creative work authored by Roberto Bourgonjen ("the Developer"), the creator of the Catalog.ID system. The Developer's intellectual property in the namespace rests on copyright in the encoding algorithm and format design, EU sui generis database right in the namespace mapping, and contractual protection through the membership agreement. (For the full analysis, see Catalog.ID Whitepaper §3.1.)

The namespace is licensed from the Developer to the Operator, and sublicensed to individual members for the duration of their membership. The member does not own the username. When a member's account is terminated, the username is permanently retired — it is never reassigned to another member. CPR records that reference the username then reference an identifier that no longer resolves to any identity.

7.2.2 Data protection classification

The data protection status of a Catalog.ID username in CPR records depends on whether the username can be resolved to a natural person. Three scenarios apply:

Baseline (no public claims, no external disclosure): The username is pseudonymous data. CPR nodes have no access to Catalog.ID and no means to resolve the username. The Catalog.ID core server itself cannot decrypt member claims. Re-identification requires the member to actively share personal claims through the encrypted sharing protocol. The "additional information" needed for attribution (GDPR Article 4(5)) is encrypted in a system that CPR cannot access.

With public claims active: When a member publishes public claims through Catalog.ID (see Catalog.ID Whitepaper §4.5) — such as a display name, professional role, or website — the username becomes directly identifying. Anyone can query Catalog.ID's public profile API and resolve the username to a named person. Because CPR and Catalog.ID are described as complementary systems (§16) and are operated within the same organizational family, a data protection authority may reasonably treat the public resolution path as available to the controller. Under the CJEU's Breyer v. Bundesrepublik Deutschland reasoning, this is sufficient for the username to constitute personal data.

After account termination in Catalog.ID: When a member exercises their right to erasure or their account is terminated for any other reason, Catalog.ID destroys all account data including public claims (see Catalog.ID Whitepaper §9a.3). The username becomes a dead identifier — it no longer resolves to any person within Catalog.ID. CPR records referencing the username are effectively de-identified: the identifier persists in the immutable layer, but the resolution path no longer exists. The de-identification occurs solely through the destruction of the resolution path in Catalog.ID. Residual linkability through cached web pages or third-party archives is outside both CPR's and Catalog.ID's control and diminishes over time.

7.2.3 Lawful basis for processing

CPR processes party usernames in the immutable layer under the following lawful bases:

1. Legitimate interest (GDPR Article 6(1)(f)): Maintaining an immutable, publicly verifiable record of creative provenance serves the legitimate interests of authors, rights holders, and the creative industries. Pseudonymous attribution in a provenance registry is proportionate to this purpose — the data processed is limited to a service identifier, and the member's full identity remains under their own control within Catalog.ID.
2. Consent: Members who submit CPR claims attributing parties, or who agree to be attributed as parties, do so voluntarily and with knowledge that the claims are immutable.
3. Archiving in the public interest (GDPR Article 89(1)): CPR serves an archival function — preserving timestamped provenance records for creative works over decades. The safeguards described in this section (pseudonymous identifiers, effective de-identification upon erasure, separation of identity and provenance layers) satisfy the requirements of Article 89(1).

These bases apply regardless of whether the member has active public claims. The public claims scenario does not change CPR's lawful basis — it changes the classification of the identifier from pseudonymous to directly identifying, but the processing purpose and safeguards remain the same.

7.3 De-anonymization scenarios and the right to erasure

7.3.1 How usernames become identifying

A Catalog.ID username may become linkable to a natural person through two paths:

1. Public claims (system-internal): The member publishes public claims through Catalog.ID (§4.5 of the Catalog.ID Whitepaper), creating an Operator-validated public profile. Anyone can query the Catalog.ID API and resolve the username to a name, role, and other published attributes. This is a system-hosted resolution path within the same organizational ecosystem as CPR.
2. External disclosure: The member publishes the association on a personal website, social media, or professional portfolio — outside the Catalog.ID system.

Both paths are expected behavior for professional creatives who want public attribution for their work. The system anticipates this as the common case, not the exception.

The distinction matters for controllership analysis: in the external disclosure case, CPR has no involvement in creating or hosting the identity link. In the public claims case, the link is hosted by Catalog.ID — a complementary system within the same organizational family (§16). A data protection authority may view the combined system as a single processing context in which the username is personal data.

7.3.2 Controllership and joint processing

CPR and Catalog.ID are designed as complementary systems operated by related Operators. When a member has active public claims, the combined effect is that CPR stores a username in its immutable layer and Catalog.ID resolves that username to a named person via a public API. A data protection authority applying the CJEU's joint controller framework (GDPR Article 26, Fashion ID and Wirtschaftsakademie case law) may conclude that the two systems jointly determine the purposes and means of processing the member's identity in the provenance context.

The project does not rely on denying this relationship. Instead, CPR's data protection posture rests on two pillars:

1. Lawful basis: CPR processes party identifiers under legitimate interest, consent, and the archiving framework described in §7.2.3. These bases apply whether or not the username is currently resolvable to a person.
2. Effective erasure mechanism: The right to erasure is satisfied through de-identification of the username, not through modification of immutable records (§7.3.3).

Whether CPR and Catalog.ID are classified as independent controllers, joint controllers, or controller-processor depends on the specific operational and governance arrangements of each federation node. The data protection argument does not depend on the outcome of this classification — the lawful basis and erasure mechanism are sufficient under either framing.

7.3.3 The right to erasure and CPR's immutable layer

If a member exercises their right to erasure under GDPR Article 17:

1. Catalog.ID destroys all encrypted claims, public claims, keys, and certificates associated with the account. The public profile is removed. The username-to-person mapping ceases to exist within the Catalog.ID system. (See Catalog.ID Whitepaper §9a.3.)
2. The username becomes a dead identifier — it no longer resolves to any identity within Catalog.ID. CPR records referencing the username now reference a disconnected service identifier with no resolution path.
3. The username is effectively de-identified by the destruction of the resolution path in Catalog.ID. This constitutes erasure by de-identification — a recognized approach under GDPR where the personal-data quality of a record is eliminated by destroying the means of re-identification, rather than by deleting the record itself.

Additionally, CPR's immutable provenance records fall within the archiving exception of GDPR Article 17(3)(d) — the right to erasure does not apply where processing is necessary for archiving purposes in the public interest. Provenance records for creative works serve a recognized archival function: establishing who created what, and when. The safeguards required by Article 89(1) — pseudonymous identifiers, separation of identity and provenance layers, effective de-identification upon erasure — are integral to CPR's design.

This two-layered defense — erasure by de-identification as the primary mechanism, plus the archiving exception as a secondary basis — means that CPR's immutable layer is GDPR-compliant without requiring modification or deletion of historical provenance records.

7.3.4 Residual risk and proportionality

After account termination in Catalog.ID, a username that was previously de-anonymized — whether through public claims or external publication — may still be findable in cached web pages, search engine indexes, social media archives, or third-party databases. This residual linkability is:

• Not within CPR's or Catalog.ID's control — neither system created or hosts these cached records.
• Subject to the member's own erasure requests to the relevant external platforms (under GDPR Article 17 or equivalent).
• Diminishing over time — as caches expire and external publications are removed, the practical ability to re-identify the username decreases.

The residual risk is proportionate to the legitimate interest served by immutable provenance records. CPR does not attempt to guarantee absolute anonymity — it provides effective de-identification within the systems it controls, while acknowledging that cached external data is outside its controllership.

7.3.5 Operational hardening

The erasure-by-de-identification argument and the archiving exception provide the legal framework. The following operational measures harden this framework for enforcement scenarios — including jurisdictions with aggressive data protection authorities and future regulatory developments.

Auditable erasure protocol. Account termination in Catalog.ID follows a documented protocol that ensures the resolution path from username to person is destroyed (see Catalog.ID Whitepaper §9a.3). The Catalog.ID Operator maintains an internal audit trail of termination events that can be presented to data protection authorities.

Key isolation. CPR signing keys must be generated exclusively for CPR use and must not be reused in other cryptographic systems (PGP, code signing, other blockchains, etc.). This is critical because every signed claim embeds the signer's public key. If the same key appeared in an external key directory or certificate transparency log, the public key itself would become a cross-reference vector that survives erasure of the Catalog.ID resolution path. Key isolation ensures that after account termination, the public key in the immutable claim is a dead cryptographic identifier — verifiable for signature purposes but unresolvable to a person through any system. Key isolation is enforced by the Catalog software, which generates each per-machine CPR signing key pair exclusively for CPR use (see §16.2b and Catalog.ID Whitepaper §3.4.1a, §9a.5.1).

DPA engagement procedure. Each federation node operator must maintain a documented procedure for responding to data protection authority inquiries, including: (1) a designated contact point for regulatory correspondence, (2) a response timeline consistent with the applicable jurisdiction's requirements, (3) the ability to demonstrate the erasure-by-de-identification mechanism and the auditable erasure trail to a regulator, and (4) escalation paths to legal counsel. This procedure is an operational requirement for federation membership, not a whitepaper-level specification — but its existence is a prerequisite for the accountability obligation under GDPR Article 5(2).

Data protection impact assessment. As the network grows beyond proof-of-concept scale, processing pseudonymous identifiers in an immutable provenance registry is likely to trigger the DPIA requirement under GDPR Article 35, particularly given the impossibility of physical deletion and the long-term retention period. Federation node operators should complete a DPIA at the point where their node processes personal data at a scale or systematicity that triggers Article 35, assessing the necessity and proportionality of immutable storage, the effectiveness of erasure by de-identification, and the residual risks identified in §7.3.4. The DPIA is a per-node obligation — different jurisdictions may set different thresholds and require different assessments.

DPA-ordered suppression. If a data protection authority orders suppression of specific claims, the node operator can comply by muting those claims in the node's operational database (see §7.6). Muting excludes a claim from query responses without modifying the immutable layer — the block chain, XRPL anchors, and cryptographic verifiability are preserved for any party that independently holds a copy.

7.4 Username retirement after termination

When a Catalog.ID account is terminated, the username is permanently retired. It is never reassigned to another member. This eliminates any ambiguity about whether provenance claims or attributions associated with a username could be inherited by a future account holder.

CPR records that reference a retired username continue to exist in the immutable layer but reference an identifier that no longer resolves to any identity.

7.6 Publication muting

CPR distinguishes between registration — the immutable recording of signed claims in blocks anchored to XRPL — and publication — the act of returning recorded claims through query interfaces. The node operator, acting as publisher, has discretion over what it publishes.

A muted claim remains in the immutable layer — included in its block, covered by the block's Merkle root, anchored to XRPL, and replicated across the federation. Muting affects only publication: the claim is excluded from standard query responses. Any party that independently holds a copy of the original claim can still verify it against the block's Merkle root.

7.6.1 Muting mechanism

Muting is managed entirely in the node's operational database. It is not a blockchain transaction and has no effect on the immutable layer.

A claim may have multiple concurrent mute entries, each with an independent reason. Each mute entry records:

• why — a reason from a defined set: on_party_request, operator_discretion, legal_compliance, error_correction, key_unpublished

A claim is considered muted if it has one or more active mute entries. Removing a mute entry for one reason does not unmute the claim if entries for other reasons remain. For example, if an operator mutes a claim (operator_discretion) and the signing key is later unpublished (key_unpublished), republishing the key removes only the key_unpublished entry — the claim remains muted due to the operator's independent decision.

The mute annotations are visible in query responses so that consumers of the API can see that a claim exists and is muted, along with the applicable reason(s), without seeing its content.

7.6.2 Who can request muting

1. The node operator. The Operator, as publisher, may mute any claim or attribution for any reason it sees fit — including abuse, legal compliance, error correction, or editorial discretion.
2. An attributed party. A party referenced in an attribution claim may instruct the publisher not to display that record. The node operator mutes the attribution with reason on_party_request.

Neither case requires the original claimant's cooperation. The claimant's registration and the immutable record are unaffected — only the publication is suppressed.

7.6.3 Federation scope

Muting is a publication-layer decision managed in each node's local database. A node operator may independently mute any claim for its own reasons (abuse, legal compliance, editorial discretion) without affecting other nodes.

However, when the original claimant or an attributed party submits a request to stop further publication — identifying the record by its CPR identifier and submitted through the node that originally accepted the submission — that request is propagated to peer nodes in the CPR Network in accordance with the federation protocol. Each peer node operator is obligated to honor the request by excluding the specified record from its own publication interfaces. A node operator that fails to honor a properly propagated stop-publication request is in breach of the license granted to it under the CPR Terms (§15.3–15.4) with respect to publication of that record.

This obligation applies to publication only — it does not require deletion from the immutable data layer, and peer nodes may continue to store and replicate the claim for integrity, verification, and archival purposes.

7.6.4 Relationship to revocation

Muting and revocation are different mechanisms serving different purposes:

• Revocation (§4.3) is a registration-layer act: the original claimant signs a new claim retracting a previous statement. It is an immutable provenance event recorded in the blockchain.
• Muting is a publication-layer act: the node operator suppresses a claim from query responses. It has no effect on the blockchain.

A claimant who wants to retract a claim should submit a revocation. A party who wants to stop being displayed in an attribution should request muting from the publisher.

7.6.5 Automatic muting on key unpublication

When a member unpublishes their cpr_signing_key claim (returning it to anonymous status), all attribution claims signed by that key are automatically muted by each CPR node that holds them. The muting reason is key_unpublished.

This automatic muting follows from the attribution signing requirement (§16.2a): attribution claims must be signed by a published, non-revoked key. When the key is no longer published, the attribution no longer satisfies the publication requirement, and the node suppresses it from query responses.

Reversibility. If the member republishes the same cpr_signing_key claim, the automatic muting is reversed: attribution claims signed by that key are unmuted and returned to standard query responses. This makes key unpublication a non-destructive, reversible operation — unlike revocation, which is permanent.

Scope. Automatic muting applies only to attribution claims signed by the unpublished key. Registration claims signed by the same key are unaffected, since registrations have no signing key publication requirement.

Federation. Each node subscribes to a Catalog.ID event feed of cpr_signing_key publish and unpublish events. Because all nodes receive the same events, they converge on the same muting state without explicit cross-node coordination.

Termination as permanent unpublication. When a Catalog.ID personal account is terminated (§7.3.3) or an organization identity is terminated (Catalog.ID Whitepaper §9a.3), Catalog.ID destroys the account's or organization's public claims — including every cpr_signing_key publish claim. From the CPR event-feed perspective this is indistinguishable from voluntary unpublication: the same automatic muting (key_unpublished) is applied to every attribution claim signed by the affected keys. Because the account or organization no longer exists and the username is permanently retired (§7.4), republication is impossible and the muting is effectively permanent. CPR does not introduce a separate "terminated" mute reason — the existing key_unpublished reason covers the behavior cleanly, and the consequence (the claim is not returned in standard query responses) is the same in either case.

Organization freezing (a temporary state, e.g., domain revalidation expired) does not destroy the cpr_signing_key claims and therefore does not mute historical attributions. It only blocks new submissions until the organization is reactivated.

8. Provenance Model

CPR distinguishes between four different identifiers:

• asset_id: stable identifier of the provenance family — a 12-character AssetID (see §8.1)
• file_uuid: identifier of one exact file instance — a UUID
• claim_id: identifier of one CPR claim — a composite string in the format {asset_id}.{operator_id}.{sequence} (see §8.1.2)
• catalog_id: pseudonymous identifier of a party (a Catalog.ID username)

This separation makes it possible to:

• keep a stable public identity for the work
• verify one exact file independently
• register multiple successive claims over the same asset
• attribute works to parties without exposing personal identity
• track roles across the lifecycle of a work

8.1 Identifier Formats

8.1.1 AssetID (asset_id)

The asset_id is a 12-character alphanumeric string called an AssetID. The format is four lowercase letters, four digits, four lowercase letters — for example: qjrm4821xwpa.

AssetIDs are generated from sequential integers using a two-stage permutation that hides the sequential nature of internal identifiers. The encoding applies a shift, two modular multiplications, and a mixed-radix decomposition over the pattern [a-z][a-z][a-z][a-z][0-9][0-9][0-9][0-9][a-z][a-z][a-z][a-z]. The result is a compact, URL-safe, human-readable identifier with no semantic content about the asset. The transformation is reversible — the original sequential integer can be recovered from any AssetID.

The namespace spans 26^8 × 10^4 = 2,088,270,645,760,000 combinations (approximately 2.09 quadrillion).

Intellectual property. The CPR AssetID namespace — the set of all possible AssetIDs, the format in which they are expressed, and the two-stage permutation algorithm that generates them — is a creative work authored by Roberto Bourgonjen ("the Developer"), analogous to the Catalog.ID username namespace (see §7.2.1). The Developer's intellectual property in the namespace rests on copyright in the encoding algorithm and format design. The namespace is licensed from the Developer to the Operators, and sublicensed to CPR clients in exchange for payments in BIT.

8.1.2 Operator ID (operator_id)

The operator_id is a 4-character opaque alphanumeric string drawn from a reduced charset that excludes visually confusing characters (0/O, 1/I/l): 23456789abcdefghjkmnpqrstuvwxyz (31 characters). Examples: b4np, bt2a.

Operator IDs are generated from sequential integers using the same two-stage permutation approach as AssetIDs (§8.1.1), applied over 4 positions of the 31-character reduced charset. The result is a compact, URL-safe, human-readable identifier with no semantic content about the operator's identity, jurisdiction, or sequence of registration. The transformation is reversible — the original sequential integer can be recovered from any Operator ID. The same reduced charset is used for Bitcash Wallet Codes (see Bitcash Whitepaper).

The namespace spans 31^4 = 923,521 combinations (approximately 923 thousand).

An Operator ID is assigned by the Developer when the operator signs the Catalog Server and Client Software License Agreement. The identifier is permanent — it remains with the operator for the lifetime of the platform and is never reassigned after the operator ceases operation.

8.1.3 Claim ID (claim_id)

The claim_id is a composite string in the format:

{asset_id}.{operator_id}.{sequence}

Where:

• asset_id is the 12-character AssetID of the asset the claim relates to
• operator_id is the 4-character Operator ID of the accepting node (e.g., b4np, bt2a)
• sequence is a local sequential number assigned by the accepting operator, starting at 1

Examples: qjrm4821xwpa.b4np.1, qjrm4821xwpa.bt2a.1, qjrm4821xwpa.b4np.2

This format makes claim identifiers globally unique, human-readable, and self-describing — the asset, accepting operator, and local ordering are immediately visible from the identifier itself.

8.2 Asset ID Namespace Distribution

The AssetID namespace is distributed through a hierarchical licensing model.

8.2.0 Licensing chain

AssetIDs are not transferred as property; the AssetID itself is not owned. What is owned is the Catalog Asset Licence (CAL) identified by the AssetID: a permanent, freely assignable contractual right to use a given AssetID through the registry, granted to the licensee on payment of the operator's fee (see §4.1 for the full definition). The AssetID namespace is held by the Catalog founder, who licences allocation rights to federation operators. The operator in turn issues per-AssetID CALs to end users. Throughout this whitepaper, when a reader sees "owner" in relation to an AssetID, it means the owner of the CAL (the licensee), not the owner of the AssetID itself or of the cryptographic key that exercises the licence.

Three tiers, three roles:

• Founder. Holds rights in the AssetID namespace as a whole (see §8.1.1). Licences allocation rights to federation operators free of charge (§8.2.1). The founder does not see, issue, or hold any individual AssetID licence.
• Operator. Holds an allocation licence from the founder for a contiguous block of AssetIDs. Issues per-AssetID licences to end users on payment of the operator's fee, by signing a license receipt that names the licensee's owner key and the AssetID range (§8.2.3). The operator that issued the licence is the AssetID's home operator and its CPR node is the authoritative source for that licence's current owner (see below).
• Owner / licensee. The end user named in a license receipt or, after any subsequent ownership rebinding (§6.2), the current holder of the licence. Holds a permanent licence to use the named AssetID(s) through the registry. The owner proves the licence by holding the private key matched to the AssetID's current owner key; loss of that key extinguishes the practical exercise of the licence, but not the licence itself.

Registry control means authority to submit future CPR claims for an AssetID. It does not by itself establish legal title in any work registered through the AssetID, copyright ownership, authorship, or exclusive rights in content. Those are matters of substantive intellectual property law, addressed by attribution claims (§4.8), agreements outside CPR, and applicable law.

Licence ownership is resolved by the AssetID's home operator. Each AssetID falls within a contiguous integer range allocated to exactly one operator (§8.2.1). These allocation ranges are public, federation-wide knowledge, and any party can determine the home operator for any AssetID by checking the allocation registry. Downstream Catalog modules (Encrypted Filestorage, CMS, Asset Market, Licensing Agent) consult the home operator's CPR node in one of two interchangeable ways:

• Direct query. The module asks the home operator's CPR node: "is key K the current owner key for AssetID A right now?" The home operator answers yes or no, signed, with a short expiration the module may cache the answer against. Internally the home operator consults its own licensee record (established at licence issuance) and any subsequent ownership rebindings (§6.2), and returns the resolution.
• Pre-issued ownership attestation. The home operator issues a signed statement naming the current owner key for an AssetID or AssetID range, with a short expiration. The licensee or the downstream module obtains the attestation once, verifies it offline against the home operator's known public key (operator keys are federation-wide knowledge), and re-fetches it before expiry. This avoids a round trip per write while keeping the freshness window short.

Both paths concentrate ownership resolution into a single, predictable source per AssetID, and remove federation-wide replication lag from the critical path for downstream authorisation. Downstream modules do not see, parse, or verify license receipts themselves; the receipt is held by the licensee as evidence of the licence transaction (see §8.2.3), and the home operator's internal record is the authoritative state.

Free assignment via rebinding. The owner may reassign the licence to a different owner key at any time, by signing an ownership rebinding claim that names the new key (§6.2). At the CPR layer, the licence follows the owner key: from the rebinding block forward, the named key holder is the new owner. CPR does not distinguish between key rotation by the same person and assignment of the licence to a different person; both are the same primitive and both are permitted by the CPR Terms (§15) without operator consent. Reassignment is unilateral by default and bilateral on request, on the same pattern as two-sided attribution (§4.9). It is the CPR-level primitive used by Asset Market when an AssetID licence changes hands commercially. Because the home operator's node always sees the rebinding (the licensee submits it directly to the home operator in the standard case), downstream queries against the home operator see the new owner on the next query or as soon as outstanding attestations expire.

8.2.1 Allocation from founder to operators

The Developer (Roberto Bourgonjen) allocates blocks of asset IDs to CPR operators. Each block is a contiguous range of internal sequence numbers (e.g., 0–99,999,999) that map to AssetID strings via the permutation algorithm (§8.1.1). Because the permutation hides sequential structure, a contiguous integer range produces seemingly unrelated AssetID strings.

Blocks are variable in size, typically between 1 million and 100 million IDs, allocated according to the operator's anticipated demand. Allocation is free — the Developer does not charge operators for namespace blocks. The allocation grants the operator a licence to issue per-AssetID licences to end users (see §8.2.0).

A distributed database, replicated across the federation, records which integer ranges are allocated to which operator. This registry changes infrequently (new allocations happen rarely) and is signed by the Developer. Each allocation entry contains:

• range_start — the first integer in the block (inclusive)
• range_end — the last integer in the block (inclusive)
• operator_id — the receiving operator's 4-character Operator ID (e.g., b4np)
• allocated_at — timestamp
• developer_signature — the Developer's signature over the allocation

When an operator exhausts its allocation, it requests a new block from the Developer. Given the namespace size (~2.09 quadrillion), scarcity is not a concern.

8.2.2 Licensing from operators to end users

Operators issue AssetID licences to end users for a fixed fee of 1 BIT per AssetID. End users may licence individual AssetIDs or batches. No volume discounts are offered at the AssetID level — volume discounts are already available at the BIT purchase level (see Bitcash Whitepaper).

The AssetID licence fee is separate from the per-kilobyte write fee for claim submission (§13.1). Licensing an AssetID reserves the identifier and grants the licensee the permanent right to use it (§8.2.0); submitting a claim against it incurs the standard write fee.

Recommended usage. Each local installation of the Catalog software — whether a mail client, camera capture application, desktop editor, or other tool — should licence and maintain its own pool of AssetIDs. This avoids conflicts: because each installation draws from its own pre-licensed range, no two machines can accidentally assign the same AssetID, and no network connectivity is required at the moment of asset creation. A typical installation might licence a batch of 1,000–10,000 AssetIDs and replenish when the pool runs low.

8.2.3 License receipt

When an end user buys AssetID licences, the operator (which becomes the home operator for that range, §8.2.0) records the licensee in its own internal registry and issues a license receipt — a signed document binding a range of AssetIDs to the licensee's owner key. The receipt contains:

• operator_id — the issuing operator's 4-character Operator ID
• range_start — the first integer in the licensed range (inclusive)
• range_end — the last integer in the licensed range (inclusive)
• buyer_public_key — the licensee's signing public key
• issued_at — timestamp
• operator_signature — the operator's post-quantum signature over the above fields

The licensee converts licensed integers to AssetID strings locally using the cl-int2assetid algorithm.

The receipt is held by the licensee as evidence of the licence transaction; the Service does not require the licensee to present it to authenticate submissions. The home operator's internal record is the authoritative state for any AssetID licence it has issued, and any CPR node accepting a registration claim resolves the current owner for the AssetID against that record (directly or through a signed ownership attestation; see §8.2.4). The receipt remains useful to the licensee as durable proof of the original purchase in the event of a dispute over licence issuance.

No Catalog.ID account is required to obtain AssetID licences or submit registration claims — only a valid key pair. Attribution claims remain open to anyone with a published Catalog.ID signing key, regardless of who holds a given AssetID licence.

8.2.4 Cross-operator submission

A licensee may submit registration claims to any operator's CPR node, not only the AssetID's home operator (§8.2.0). The receiving operator resolves the current owner key for the AssetID by querying the home operator (or by holding a fresh signed ownership attestation from it), and accepts the claim only when the submitting key matches the resolved owner. Operator public keys are federation-wide knowledge, so the receiving operator can verify the home operator's response without further coordination. The license receipt is not used by the platform for this purpose; the home operator's internal record is the authoritative state for any AssetID licence it has issued. The receipt is held by the licensee as evidence of the licence transaction for the licensee's own records.

8.2.5 Registration locking

The current owner of an AssetID licence (the licensee, as resolved by the home operator per §8.2.0) may lock the AssetID against further registration claims. A locked AssetID accepts no new registrations or superseding claims — the file state is frozen. The lock is recorded in the AssetID's metadata and replicated across the federation.

Locking applies only to registration claims. Attribution claims remain open regardless of lock status — any party with a published Catalog.ID signing key may submit attributions for a locked AssetID.

The current owner may unlock the AssetID at any time by submitting an unlock request signed with the same key.

9. Derivative Files

CPR is designed to support derivative workflows.

Typical example:

• RAW master capture
• JPEG master
• scaled derivatives
• watermarked derivatives
• thumbnails or previews

Each exact file should have its own file UUID and digest. These files can all belong to one asset ID. A single claim manifest can register the whole set together.

This gives both:

• family-level provenance
• per-file independent verification

File-level derivation is distinct from asset-level hierarchy (§4.11). Derivative files live under the same AssetID as their source; asset-level child_of is used when a sub-object needs its own first-class AssetID, such as a page scan in a digitized encyclopedia or a track on an album. The two mechanisms do not overlap and follow independent rules.

10. Recommended Watermark and Metadata Policy

For public-facing visible watermarks, the recommended identifier is the asset ID, embedded as the canonical Catalog asset URL without the https:// prefix:

catalog.org/{asset_id}

For example: catalog.org/qjrm4821xwpa

The https:// prefix should be omitted from visible watermarks for brevity and readability. Modern browsers and QR code readers will resolve the URL correctly without the scheme prefix.

catalog.org/{asset_id} is the asset's canonical hub URL across the suite (CMS §17.1), returning links to all per-module slices: CPR claims at catalog.org/cpr/{asset_id}, current files at catalog.org/efs/{asset_id}, current description at catalog.org/cms/{asset_id}, etc. Because claims are replicated across federation nodes, the same asset ID can be verified at any node. If the canonical anchor is unavailable, the URL can be adjusted to any operator's subdomain (e.g. b4np.catalog.org/{asset_id}).

The catalog.org host is a thin redirector. It returns a 302 Found to an operator subdomain ({operatorid}.catalog.org/{asset_id}), preferring a node in the requester's jurisdiction. Since operations may involve micropayments, jurisdiction-aware routing ensures the requester interacts with a node governed by applicable local payment regulations. Optionally GeoDNS at the bare host returns a geographically nearby operator without an explicit redirect. The redirector itself does not retrieve data or handle payments.

For file metadata, the recommended identifiers are:

• asset ID
• file UUID
• CPR resolution URL

For hidden technical watermarking, a file-specific identifier may be used, typically the file UUID.

10.1 POM URL pattern

Catalog Physical Object Markers (POMs, §18) carry a QR code resolving to a distinct URL pattern:

catalog.org/pom/{pom_serial}

The resolver behaviour is described in §18.6: when the POM has been registered to a CAL, the URL redirects to the bound AssetID's hub (catalog.org/{asset_id}); when the POM is unregistered or has been detached, the URL returns a status page identifying the POM serial and its current state. The pattern is implemented in the same thin redirector that serves catalog.org/{asset_id} and is independent of, and complementary to, that pattern.

11. Block Structure and Continuity

Each node's blocks form an independent append-only chain.

Each block should include at least:

• node identifier
• block number (sequential per node)
• block opening time
• block closing time
• previous block digest
• claim count
• canonical digest or Merkle root of included claims
• protocol version
• operator post-quantum signature

A block is globally unique by the combination of node identity and block number. This makes it cryptographically evident if a published anchored block has been altered, replaced, or removed from a node's published sequence.

12. Verification Model

A verifier should be able to verify any of the following:

12.1 Verify by asset ID

This shows:

• the asset record
• files belonging to the asset (from the latest registration)
• attributions: each party, their roles, and attribution type (claimant-asserted, self-asserted, or mutual)
• claims over time (registrations, attributions, revocations)
• block references and anchors

12.2 Verify by file UUID

This shows:

• the exact file record
• recorded digest
• relationship to asset
• claims mentioning the file
• block inclusion and anchor references

12.3 Verify by claim ID

This shows:

• the exact submitted signed claim (registration or attribution)
• claimant key information
• for registrations: listed files with technical properties
• for attributions: the attributed party and roles, and whether the attribution is claimant-asserted or self-asserted
• origin node identity
• submission time
• acceptance time
• containing block (node and block number)
• XRPL anchor reference

Verification works identically whether the claim originated at the queried node or was replicated from a peer.

13. Economic Model

CPR is operated on a non-profit basis. BIT micropayments serve two purposes: compensating for the costs of infrastructure and resources, and preventing spam and abuse.

BIT is a prepaid service credit within the Catalog/Bitcash ecosystem, not a cryptocurrency, security, or investment product. BIT can be purchased from the webshop of the Operator operating a CPR node. Payment rights, wallet behavior, and distribution terms are governed by the applicable Bitcash terms and end-user license documentation (see: bit.cash).

13.1 Write operations (PUT)

Each write operation is charged exactly 1 BIT per kilobyte of payload, or portion thereof. For example, a 3.2 KB claim manifest costs 4 BIT.

This fixed rate is designed so that integrators can purchase BIT tokens in bulk beforehand, securing guaranteed access at a known cost. This removes the risk that after implementation, pricing could be increased to an unacceptable level.

Write fees are in addition to the one-time AssetID licence fee of 1 BIT per AssetID (see §8.2.2). The licence fee reserves the identifier and grants the permanent use right; the per-kilobyte write fee applies each time a claim is submitted against it.

Catalog Physical Object Markers (POMs, §18) carry a parallel fee structure: a mandatory minimum of 250 BIT per POM at the point of operator-to-end-user sale (approximately 5 euro cent), plus an operator-determined distribution fee covering physical handling and shipping. The per-POM minimum is mandated network-wide and is not waivable; its level reflects the physical-product cost structure that the Founder bears in producing and distributing POMs to operators free of charge. The per-kilobyte write fee applies separately each time a pom_registered or pom_detached claim is submitted.

13.2 Read operations (GET)

Read operations are free for as long as possible. If and when BIT payments are introduced for read operations, the cost will not exceed 1 BIT per request. This ceiling likewise allows integrators to purchase a stash of BIT tokens in advance for guaranteed medium- to long-term access at a predictable cost.

13.3 Payment layer

The payment layer is separate from the provenance layer. Payment rights and wallet behavior are governed by the applicable Bitcash terms and end-user license documentation.

14. Federation Model

CPR is a federated network. Each Operator operates one or more nodes.

14.1 Node independence

Each node:

• accepts claims from claimants directly
• maintains its own per-node block chain
• anchors its own blocks to XRPL independently
• signs its blocks with its own post-quantum operator key

No distributed consensus protocol is required. Nodes do not need to agree on a shared ordering of claims. Each node's block chain is independently verifiable.

14.2 Replication

Nodes replicate blocks and claims from peer nodes using a pull-based protocol. A replicating node:

1. fetches block headers from the peer since its last known position
2. verifies the operator signature on each block
3. fetches the claims included in each block
4. verifies each claim signature and block inclusion
5. stores the replicated data locally
6. optionally verifies the XRPL anchor independently

Replication ensures that claims survive the loss of any single node and that any node can serve verification queries for any claim in the network.

14.3 Conflict handling

If the same claim ID appears at two nodes with identical content, this is harmless duplication. If the same claim ID appears with different content, the replicating node flags a conflict. CPR does not adjudicate conflicting claims — both records are preserved as evidence.

14.4 Governance

Federated operation serves several purposes:

• operational continuity
• resilience against institutional failure
• geographic distribution
• governance transparency
• preservation-minded stewardship
• publication of supported cryptographic profiles
• coordinated migration to newer post-quantum algorithms over time

The Operators aim for long-term preservation, but CPR should be described as a best-effort perpetual registry, not as an absolute guarantee of eternal availability.

15. Why Not Put Everything On-Chain

Putting all claim data directly on a public blockchain would be undesirable for several reasons:

• higher cost
• less structured retrieval
• greater privacy risk
• poor support for corrections, annotations, and indexing
• unnecessary duplication of bulky data

CPR therefore stores claim manifests off-chain and anchors only compact block digests on XRPL.

16. Catalog.ID Integration

CPR and Catalog.ID are designed as complementary systems. CPR is a provenance registry; Catalog.ID is a privacy-preserving identity platform. Together they provide identity integration at three levels: open registration (any key can sign file registrations), verified attribution (only published Catalog.ID keys can sign attributions), and private verification via the encrypted identity bridge.

16.1 Open registration signing

Registration claims (file manifests) may be signed by any key. The submitter does not need to prove membership of the Catalog.ID network — only payment is required. The submitter may use:

• a published CPR signing key registered to a Catalog.ID account
• an anonymous CPR signing key registered to a Catalog.ID account
• any other key entirely (e.g., an application key, institutional key, or ephemeral key)

This makes CPR accessible to non-Catalog.ID users — applications, institutions, archival systems — and supports anonymous file registration for privacy-sensitive use cases.

16.2 Public attribution via attribution claims

CPR attribution claims list Catalog.ID usernames with their roles. These are full signed transactions, included in blocks and anchored. Anyone who looks up a CPR record can see which pseudonymous identifiers are associated with a work, in what capacity, and who asserted the attribution.

Because attributions are independent claims, a party can be attributed at any time — including after the initial file registration, and even if they did not yet have a Catalog.ID account at the time of file creation. A party can also submit their own attribution, asserting their role directly. When both the claimant and the party have submitted matching attributions, the result is a mutual attribution — the strongest signal of agreed participation.

A member who wants to reveal the personal identity behind their Catalog.ID username can do so through Catalog.ID's encrypted sharing protocol, at their own discretion and on their own terms.

For members who want their real-world identity to be publicly resolvable, Catalog.ID supports public claims — Operator-validated attributes (display name, professional role, website, etc.) that are published in cleartext and queryable by anyone who looks up the Catalog.ID username. This provides a durable, system-hosted resolution from pseudonymous CPR attribution to a verified public identity. See Catalog.ID Whitepaper §4.5 for the full design.

16.2a Attribution signing requirement

Attribution claims must be signed with a published (non-anonymous) CPR signing key registered to a Catalog.ID account. The CPR node verifies at submission time that the signing key matches a published, non-revoked cpr_signing_key public claim on the claimant's Catalog.ID account by querying the public profile API.

This enforcement ensures that every attribution is cryptographically linked to a verifiable Catalog.ID username. Claims signed with anonymous keys, unregistered keys, or revoked keys are rejected.

Unpublication consequence. If a member unpublishes their CPR signing key (returning it to anonymous status), all attribution claims signed by that key are automatically muted (see §7.6.5). Republishing the key reverses the muting. This makes key unpublication a non-destructive way to temporarily suppress attributions without revoking the key.

16.2b Per-machine CPR signing keys

Each machine on which the Catalog software is installed generates its own independent ML-DSA-65 keypair. The private key never leaves the machine. The public key is registered with the member's Catalog.ID account as an encrypted cpr_signing_key claim.

This per-machine model provides:

• Containment: compromise or loss of one machine does not affect other machines
• Independent revocation: each key can be revoked individually (by setting revoked_at on the claim) without disrupting other devices
• One key per machine: each machine has exactly one CPR signing key, avoiding user confusion and preventing trivial correlation between co-located keys

Each key carries a user-configurable label (e.g., "Studio workstation") and system-assigned metadata (registration time, revocation status, revocation reason). See Catalog.ID Whitepaper §3.4.1a for the full metadata specification.

Public vs. anonymous. A CPR signing key is anonymous by default (the encrypted claim is not published). To make a key public — enabling it to sign attribution claims — the member publishes the cpr_signing_key claim through Catalog.ID's standard public claims flow, validated via key control proof. The public/anonymous distinction is simply whether the claim has been published.

Privacy notice. An anonymous registration provides unlinkability only if the claimant does not subsequently create or receive public attributions on the same asset. Public attributions create a correlation path that may allow observers to infer the identity behind the anonymous registration. Members who require anonymity for a registration should not attribute that asset through their public identity.

16.3 Private verification via the identity bridge

For cases where a member does not wish to be listed as a party but still wants to be able to prove authorship selectively, the encrypted identity bridge remains available.

A member's CPR signing public key is stored as an encrypted Catalog.ID claim (cpr_signing_key). Like all Catalog.ID claims, it is encrypted end-to-end and invisible to the Catalog.ID core server.

When a member chooses to reveal their identity to another member:

1. The member shares their cpr_signing_key claim via Catalog.ID's encrypted key-sharing protocol.
2. The recipient's client decrypts the claim and learns the member's CPR public key.
3. The recipient's client can match that key against CPR provenance claims.

This path serves use cases where full anonymity in the public record is desired, with selective private disclosure.

Arbitration use case. A member who registered files anonymously can later prove authorship to arbitrators (who are Catalog.ID members) by sharing the encrypted cpr_signing_key claim with them. The arbitrators decrypt the claim, match the public key against the anonymous CPR registration, and confirm the member's authorship — without exposing the key publicly. The encrypted claim remains on the account even if the machine that held the private key is lost, ensuring the member can always prove past authorship.

16.4 Two-sided attribution via Catalog.ID

Attributions can be submitted by any party holding a published CPR signing key on a Catalog.ID account. The CPR node verifies at submission time that the signing key is published and non-revoked (§16.2a).

Attribution status for each party is visible when querying an asset:

• Claimant-asserted only: the original claimant attributed the party, but the party has not submitted their own attribution
• Self-asserted only: the party attributed themselves, but the original claimant has not attributed them
• Mutual: both the claimant and the party have submitted attributions with matching roles — the strongest form of agreed attribution
• Divergent: the claimant and the party have submitted attributions with different roles — a visible disagreement without requiring a formal dispute

16.5 Key control validation

A member may have the Catalog.ID Validator Black Box certify that they control a given CPR signing key. This validation is required when publishing a cpr_signing_key claim (§16.2a) and may be requested at any time for any key.

The validator issues a cryptographic certificate proving key control without retaining any persistent association between the member's identity and the key. Because CPR signing keys are machine-local, the validation challenge must be signed on the machine that holds the private key.

This certificate proves: "the person behind username khu3758iop controls the private key corresponding to this public key." Each cpr_signing_key claim is validated independently.

16.6 Dispute resolution

In a dispute between Catalog.ID members (governed by the Catalog.ID Membership Agreement), an arbiter panel may request that parties share their cpr_signing_key claims — including anonymous keys — linking provenance records to identities within the confidential dispute process. Because the public key is stored as an encrypted Catalog.ID claim, it can be shared from any device via the standard sharing protocol, even if the machine that held the private key is no longer available.

16.7 Cryptographic alignment

Both CPR and Catalog.ID use NIST post-quantum cryptographic standards:

• Signing: ML-DSA-65 (FIPS 204) — used by both systems
• Encryption: ML-KEM-1024 (FIPS 203) — used by both systems (Catalog.ID for claim encryption and key sharing; CPR for optional confidential payload encryption)

CPR signing keys are separate from Catalog.ID identity keys and are generated per-machine (see §16.2b and Catalog.ID Whitepaper §3.4.1a). This provides key compromise isolation: compromise of a machine's CPR signing key does not expose Catalog.ID identity keys, and vice versa.

17. Registry Anchoring and Claim Chaining

17.1 Registry anchoring

CPR supports a registry_anchor claim type that allows external registries to timestamp their state by submitting a Merkle root of their operations to CPR. This creates a layered timestamping chain:

External registry operations → Merkle root → CPR claim → CPR block → XRPL

For example, the Catalog.ID core server periodically computes a Merkle tree of its claim operations (creates, updates, shares, revocations, certificate issuances) and submits the Merkle root to CPR. This proves that a specific set of encrypted Catalog.ID claims existed at a specific time, without revealing any claim content.

A registry_anchor claim does not reference files. Instead, its extensions object contains the registry type, operator, interval boundaries, operation count, and Merkle root.

17.2 Per-claimant claim chaining

Any claimant — a registry operator, a photo application, or an individual — may chain their successive CPR claims using the previous_claim_id and sequence_number extension fields. This forms a per-claimant append-only chain within CPR, enabling proof of sequential completeness: no claims have been omitted, inserted, or reordered.

This is useful for:

• Registry operators proving no anchoring intervals were skipped
• Photo applications proving a complete capture sequence with no frames deleted
• Individuals proving a continuous record of authorship claims over time

Chain integrity is strictly enforced at submission time. CPR rejects any claim where:

• previous_claim_id references a non-existent or non-accepted claim
• previous_claim_id references a claim signed by a different key
• sequence_number does not equal the referenced claim's sequence_number + 1
• previous_claim_id is absent but sequence_number is present and not equal to 1 (which starts a new chain)

This ensures that per-claimant chains are provably complete and tamper-evident.

18. Catalog Physical Object Marker (POM)

18.1 Purpose

A Catalog Physical Object Marker (POM) is a tamper-evident physical label, optionally adhered to a real-world object, that carries an AssetID-resolving QR code plus security features that make casual reproduction visibly difficult. POMs are sold in batches by Operators to galleries, museums, archives, artists, and any CAL owner who wants to anchor a Catalog Asset Licence (§4.1) to a specific physical object.

The POM serves two purposes:

1. Identifier resolver. A QR code on the POM resolves to catalog.org/pom/{pom_serial}, which (after the POM has been registered to a CAL) redirects to the AssetID's lifecycle metadata at catalog.org/{asset_id}.
2. Added physical entropy. The POM's anti-counterfeit features and its specific physical state once attached — micro-features, exact placement, accumulated wear, interaction with the substrate it was adhered to — constitute unique entropy that the CAL owner may capture privately and use to recognise the same object later. The entropy is the CAL owner's to use; Catalog does not analyse or compare it.

POMs are optional. An AssetID may exist without any POM, and a POM batch may exist with no AssetID bindings yet. POMs are not intended as a Physically Unclonable Function (PUF) on their own; they are designed for use in combination with a real-world object, where the object's own characteristics and the POM's added entropy together give the CAL owner a reference state they may store privately and consult later (see §18.7).

18.2 Physical specification

A POM is a tamper-evident adhesive label (or equivalent physical token) manufactured under the network's specification. Required physical properties:

• Substrate. A specialty substrate that visibly destructs on removal, leaving a void pattern or fibre residue. A removed POM cannot be restored to a state indistinguishable from new.
• Anti-counterfeit features. Banknote-equivalent physical security: microprinting, optical-variable ink, UV-fluorescent markers, tactile features, and a covert element verifiable only with specialist equipment. The exact specification is managed by the network and may evolve over time; each POM revision carries a profile identifier.
• POM serial. A globally unique alphanumeric serial (pom_serial) printed on the POM in both human-readable and machine-readable form, optionally also embedded in a passive RFID or NFC chip in the substrate. The serial is the POM's identity from manufacture onward.
• Resolving QR code. Encodes https://catalog.org/pom/{pom_serial}. The URL pattern is distinct from the AssetID hub URL catalog.org/{asset_id}; resolution behaviour is given in §18.6.

POMs do not carry a printed AssetID at manufacture. The binding from POM serial to AssetID is established only via a registration claim (§18.5) and is exposed through the registry; the printed POM itself carries only the serial and the resolving QR. This is intentional and is what allows POMs to be sold as generic batches and assigned later.

18.3 Identifiers

Two identifiers operate together:

• AssetID (§4.1, §8.1.1) names the CAL.
• POM serial (pom_serial) names the physical POM. The serial space is distinct from the AssetID space and is federation-wide (not operator-scoped).

A POM in its manufactured-but-unregistered state has only a POM serial. The QR code resolves to a generic "unregistered" page at catalog.org/pom/{pom_serial} (see §18.6). After a pom_registered claim binds the serial to an AssetID, the same URL resolves to the AssetID's hub.

POM serial format. A POM serial is a 28-character lowercase alphanumeric string from the reduced charset [a-z2-9] (31 characters, excluding o, 1, i, l, 0), structured positionally:

positions 0..2   : 3-char checksum
positions 3..27  : 25-char secret

• The secret is 25 characters of cryptographic randomness generated by the manufacturer under HSM. ~123 bits of entropy.
• The checksum is deterministically derived from the secret as the first 3 characters of base31([a-z2-9]) encoding of SHA-512(secret), where the encoding maps each 5-bit group of the hash output to one charset character. The checksum is not independent entropy; it is a prefix of the same hash that the service uses for verification.

The manufacturer stores the full SHA-512(secret) (64 bytes binary) as the canonical record of each manufactured POM. The secret itself is never persisted after the POM is printed; it lives only on the physical POM until a user scans it and submits a registration claim.

This split has three properties:

1. The manufacturer cannot re-issue a printed POM. After printing and secret erasure, the manufacturer holds only the SHA-512 digest. SHA-512 is one-way; the secret cannot be recovered from the digest.
2. Users cannot fabricate POMs. Producing a valid POM requires a secret whose SHA-512 hash matches a digest in the federation-wide manufacturing record. Finding such a secret is a SHA-512 pre-image attack against a specific target digest, infeasible against the full hash.
3. Validity can be sanity-checked offline. The 3-character checksum lets a scanner verify a POM's structural plausibility without a network round trip: compute SHA-512(secret), encode the first 3 charset characters, compare. A mismatch identifies the input as corrupt, fabricated, or otherwise unusable. A match indicates the POM may be genuine, and the registry lookup confirms.

18.4 Distribution and manufacturing

POMs are produced centrally and distributed through a two-tier chain:

• Founder (or, when incorporated, the non-profit foundation planned to succeed the founder in holding the network's intellectual property and producing POMs). Owns the POM design, security specification, and embedded-feature IP. Produces (or commissions a specialist security printer to produce) POMs in centrally managed batches. Generates each POM's secret under a hardware security module, computes the corresponding SHA-512 digest, prints the POM with the resulting 28-character serial encoded in the QR code, and erases the secret from any volatile and non-volatile storage. Publishes signed batch manifests listing the digests of all POMs in each batch; the manifest's Merkle root is anchored to CPR through a registry_anchor claim signed by the Founder, providing tamper-evident timestamped evidence of which POMs the Founder has manufactured and when. Provides the resulting physical POM inventory to operators at no cost as part of the founder-operator licensing agreement.
• Operator. Receives POM inventory free from the Founder. Distributes POMs to end users. Does not manufacture POMs, holds no POM production rights, and does not maintain its own POM serial namespace. Replicates the Founder's signed batch manifests through the same federation protocol that propagates operator public keys; the resulting federation-wide manufacturing record is the canonical source of truth for "which POMs exist."

End users (CAL owners, artists, galleries, museums, archives) acquire POMs from any operator and may register them through any operator. POMs are operator-agnostic by construction: the Founder is the single source of POM inventory, and the manufacturing record is the same federation-wide artifact under any operator's view. This composes with use cases where an artist receives POMs through one operator, attaches them to physical works, and the works are later sold through galleries operating under different operators in different jurisdictions; the gallery-side registration succeeds against any operator's CPR node regardless of which operator originally distributed the POMs.

POM fees. Operators must charge end users a minimum of 250 BIT per POM at the point of sale (approximately 5 euro cent at the standard BIT-to-fiat reference rate). This minimum is mandated network-wide and is not waivable, mirroring the per-AssetID licence fee model (§8.2.2). The level reflects the physical-product nature of POMs: real manufacturing, security-feature, substrate, printing, and inventory-handling costs are borne by the Founder, and the per-POM fee underwrites the supply chain. Operators may, on top of this minimum, charge an operator-determined distribution fee covering physical shipping, handling, packaging, customs, and any other operational costs of delivering the POMs to the buyer. No volume discounts at the per-POM BIT-fee level (mirroring §8.2.2's rule for AssetID licence fees); operators may offer shipping discounts on large batches as a matter of commercial freedom.

The on-chain write fee for the pom_registered claim itself (§18.5) is a separate cost, charged at the standard 1 BIT per kilobyte of payload (§13.1), payable at registration time. A typical pom_registered claim is under 1 KB and costs 1 BIT to submit.

POM design IP. The POM design, security-feature specification, substrate engineering, and embedded covert features are intellectual property of the Founder. The Founder produces POMs; operators do not. The buyer of a POM receives a sublicence in the POM design IP that grants the right to register and attach the POM to a CAL once, with the lifecycle described in this section. The sublicence prohibits reproduction, duplication, transfer of an attached POM to a different physical object outside the detach / re-register flow, and any forensic disclosure of covert security features. POM design rights are not transferred to the buyer; the buyer holds use rights only.

Manufacturer secrecy obligation. The cryptographic guarantee that the manufacturer cannot re-issue a printed POM (§18.3) is backstopped by an operational obligation: secrets must be generated under a hardware security module, used exactly once for printing, and erased from all persistent and volatile storage immediately afterward. The manufacturer retains only the SHA-512 digest. Operator compliance with this discipline is required by the founder-operator licensing agreement and by CPR Terms §13c.

18.5 Registration: pom_registered claim

Registration binds a previously unregistered POM (identified by its serial) to a specific AssetID. The CAL owner submits a pom_registered claim, signed by the AssetID's current owner key, carrying:

• pom_serial — the 28-character POM serial being registered.
• asset_id — the AssetID the POM is being bound to.
• registered_at — RFC 3339 UTC timestamp.

Note that no operator_id field is required: POM serials are federation-wide and not operator-scoped (§18.3, §18.4).

Acceptance rules:

1. Parse. Split the 28-character serial as checksum = serial[0..3] and secret = serial[3..28].
2. Checksum check. Compute candidate_checksum = first 3 chars of base31-encode(SHA-512(secret)). If candidate_checksum != checksum, reject with POM_CHECKSUM_MISMATCH. This is a fast pre-network rejection of corrupted or fabricated input.
3. Manufacturing-record check. Compute full_digest = SHA-512(secret) (64 bytes). Look up full_digest in the federation-wide manufacturing record (replicated from the Founder's signed batch manifests, §18.4). If absent, reject with POM_NOT_MANUFACTURED.
4. Owner-key check. The submitting key must match the AssetID's current owner key as resolved by the AssetID's home operator (§8.2.0).
5. Binding-state check. The POM serial must be in unregistered state: either never registered, or detached after a prior registration via pom_detached (§18.8). If the POM is currently bound to a non-detached AssetID, reject with POM_ALREADY_REGISTERED.

After acceptance, the POM serial is bound to the AssetID. The receiving operator persists the full serial in its resolver index so that catalog.org/pom/{pom_serial} redirects to the bound AssetID's hub. From this point on the POM cannot be registered to a different AssetID without first being detached (§18.8).

Offline structural pre-check. Any client (a phone scanning the QR in a gallery, a verifier inspecting an artwork) can perform step 2 of the acceptance rules without network access. A mismatched checksum identifies the input as unusable before any database lookup. A matched checksum indicates the POM is structurally plausible; final verification still requires step 3 (manufacturing-record lookup) and the rest of the chain.

18.6 URL resolution: catalog.org/pom/{pom_serial}

Every POM bears a QR code encoding https://catalog.org/pom/{pom_serial}. The resolver behaviour depends on the POM's current state:

• Unregistered. Returns a page identifying the POM serial as valid (in the network's manufacturing record), confirming it is unregistered, and explaining what registration means and how the holder of a CAL can register the POM. No AssetID is named.
• Registered. Returns a redirect (or rendered page) pointing to the current AssetID's hub: catalog.org/{asset_id}. The hub serves the AssetID's lifecycle metadata: current CAL owner key (per §8.2.0), registration claim history, attribution, file digests, structural relationships, POM bindings.
• Detached. Returns a page identifying the POM serial as previously registered (optionally with the AssetID it was previously bound to, depending on the operator's publication policy) and currently available for re-registration.

The resolver is implemented in the catalog.org thin redirector with appropriate jurisdiction routing as in §10. The resolver does not store any user-side data and does not facilitate authenticity comparisons.

18.7 Photographic anchoring (optional, owner-side)

A CAL owner who wants a private visual reference of the POM-on-object state may capture macro photographs of the attached POM and the surrounding region of the object, encrypt the photographs through Encrypted Filestorage under the CAL owner's key, and register the file digests in CPR through a standard registration claim against the AssetID. This gives the owner a tamper-evident timestamped record of the photograph's contents.

The photographs are the owner's reference state. If the owner later wants to verify that an object now in front of them is the same object the POM was originally attached to, the owner can decrypt their stored photographs and visually compare. The added entropy from the POM (unique micro-features, exact placement, interaction with the underlying substrate, accumulated wear) plus the object's own characteristics make this comparison meaningful even for objects (prints, books) that have little intrinsic distinguishing detail.

Catalog does not perform this comparison and does not offer comparison as a service. Catalog's role with respect to these photographs is exactly the same as for any other encrypted file: storage, replication, retrieval, and digest-anchoring in CPR. The photographs remain encrypted to the CAL owner's key; Catalog cannot read them, does not index them by visual content, does not compare them against any reference set, and does not return any authenticity verdict for any object. Any inference about whether a physical object is genuine is the CAL owner's act, performed on the owner's own equipment with the owner's own decrypted material.

This positioning is intentional and is set out here for clarity for integrators, auditors, and any third party assessing the POM mechanism.

18.8 Detachment and re-registration: pom_detached claim

A POM that has been registered to an AssetID may be released back to "unregistered" state via a pom_detached claim, signed by the AssetID's current owner key, carrying:

• pom_serial — the POM being detached.
• asset_id — the AssetID the POM was bound to.
• detached_at — RFC 3339 UTC timestamp.
• reason — optional, from a defined enum (physically_destroyed, lost, object_disposed, superseded, transferred_separately, other).

After acceptance, the POM is back to "registrable" state and may be re-registered to a different AssetID via a fresh pom_registered claim. CPR does not require the physical POM to be physically present, recovered, or destroyed; the detachment is a record-keeping act by the CAL owner. The owner takes responsibility for the integrity of the system: a CAL owner who detaches a POM in CPR while the physical POM is still adhered to its original object is creating a record that does not match physical reality, and is responsible for the consequences.

18.9 Multiple POMs per AssetID

An AssetID may have any number of currently-registered POMs at any time. Intended use cases:

• Composite single objects. A CAL representing one physical work that consists of physically separated parts conceptually belonging together as a single object: a diptych, a sculpture-and-pedestal, a book-and-slipcase, an installation of related panels. One AssetID for the whole object; one POM per physical part.
• Redundant anchoring. Multiple POMs on a single physical object for robustness: one visible and one covert, one on the front and one on the back, one tamper-evident and one cosmetic.
• Replacements. If a POM is detached (§18.8) because of physical damage, loss, or compromise, the CAL owner may register a fresh POM in its place.

POMs are independent of each other; detaching one POM does not affect the others. The CAL itself is unaffected by POM lifecycle events; the POM serves the physical-anchoring purpose while the CAL governs the registry-level licence.

Not for editions. Limited editions, print runs, pressings, castings, and other cases where one conceptual work exists in N physical copies are recommended to be modelled at the hierarchy layer (§4.11): a parent edition AssetID with N child AssetIDs, one per physical copy, each child carrying its own POM. This keeps individual copies independently transferable through CPR's standard detachment and rebinding mechanisms. Stacking N POMs against a single AssetID to represent an edition is technically possible but conflates the copies into a single non-divisible CAL and is not the recommended pattern.

18.10 Verification

A POM can be checked at three levels, all of which are honest about what they do and do not establish:

1. Physical inspection. An observer with the published POM specification and standard inspection equipment (UV lamp, magnifier, tactile check) can verify the network's security features against the published spec for the POM revision. A POM that fails physical inspection is presumptively counterfeit. A POM that passes physical inspection has demonstrated that it carries the network's security features; it has not, by itself, demonstrated that it was issued for any specific AssetID or attached to any specific object.
2. Registry lookup. Scanning the QR resolves to catalog.org/pom/{pom_serial}, which redirects to the AssetID hub when the POM is registered. The hub serves the CPR-recorded lifecycle: registering operator, registration claim, current AssetID binding, current CAL owner key, registered file digests, attribution claims, and so on. The registry shows what the network has recorded; it does not assert that the physical POM in front of the verifier is the genuine POM that the network manufactured.
3. Owner-side photographic comparison. The CAL owner, holding their own decryption keys and their own previously-stored macro photographs (§18.7), may compare the photographs to the current physical state of the POM-on-object and decide for themselves whether the object is the one they originally anchored. This comparison happens on the owner's equipment, with the owner's data; Catalog is not a party to it.

No combination of these checks constitutes an authentication service offered by Catalog. The owner decides; the network provides the infrastructure for the owner's decision.

18.11 What POM is and is not

The POM is, explicitly:

• a physical label with anti-counterfeit security features that make casual reproduction visibly difficult;
• a QR-encoded resolver pointing the curious to the CPR registry record for the bound AssetID;
• a source of additional entropy that complements the object's own physical characteristics in the CAL owner's private reference photographs;
• a registry-anchored binding (via pom_registered / pom_detached) so the network records what is bound to what.

The POM is, explicitly, not:

• a Physically Unclonable Function (PUF) intended to be self-sufficient evidence of authenticity;
• a token whose authenticity Catalog will verify on request;
• the input to an authentication-as-a-service offering by Catalog or any Operator;
• a guarantee of legal title in the underlying object;
• a substitute for the owner's own due diligence in verifying a physical object's provenance.

Comparable services on the market — for example, Avery Dennison's atma.io / identropy, and Zortag — offer label-authentication-by-server-side-comparison as their primary product. Catalog deliberately does not occupy that space: the comparison act, where it happens, is the owner's, not Catalog's, and uses the owner's encrypted material on the owner's equipment.

18.12 Relationship to CAL ownership rebinding

When a CAL is reassigned (§6.2), all POMs registered to its AssetID remain bound and their pom_registered records remain valid; the new CAL owner inherits the right to detach existing POMs and to register fresh ones. The physical POMs already attached to objects do not need to be replaced; the binding to the AssetID is the persistent record, and the CAL has simply changed hands. In commercial practice the physical objects bearing the POMs typically transfer to the new CAL owner in tandem with the CAL (see §6.2, "Implicit tandem transfer of associated real-world assets"), but this is governed by the external commercial instrument, not by the POM mechanism itself.

19. Summary

CPR is a cryptographically structured provenance registry that combines:

• open registration signing: any key can sign file registrations, no Catalog.ID membership required
• verified attribution: attribution claims must be signed with a published CPR signing key registered to a Catalog.ID account
• per-machine CPR signing keys with independent revocation, one key per machine, public or anonymous
• decoupled attribution via separate signed claims with Catalog.ID usernames and industry-specific roles
• two-sided attribution model: claimant-asserted, self-asserted, and mutual attributions replace the previous attestation mechanism
• six claim types: registration (files), attribution, revocation, registry anchor, POM registration, and POM detachment
• compact identifiers: 12-character AssetID for assets, composite claim IDs encoding asset, operator, and sequence
• Catalog Asset Licence (CAL) framing: AssetIDs are not transferred as property; what is held and transferred is the permanent, freely assignable CAL identified by the AssetID
• optional physical anchoring through Catalog Physical Object Markers (POMs): tamper-evident labels with anti-counterfeit features, sold in unregistered batches, registered against a CAL via on-chain claims, designed as identifier resolver plus added entropy and explicitly not as a PUF or comparison-as-a-service
• snapshot model for files; incremental model for attributions
• private identity verification via the Catalog.ID encrypted identity bridge for selective disclosure
• registry anchoring for timestamping external registry state via Merkle roots
• per-claimant claim chaining for sequential completeness proofs
• post-quantum signed canonical claim manifests
• federated network of independently operating nodes
• per-node append-only block chains with operator post-quantum signatures
• pull-based replication across peer nodes
• public external timestamping via XRPL
• hierarchical licensing distribution: the Developer allocates AssetID ranges to operators, operators issue per-AssetID licences to end users at 1 BIT per licence
• receipt-based ownership binding: license receipts bind an AssetID range to the licensee's initial owner key; downstream ownership decisions are resolved by the AssetID's home operator
• registration locking: the current owner of an AssetID licence can freeze the file state against further registrations while keeping attributions open
• non-profit operation with fixed-rate BIT micropayments for writes and free reads
• crypto-agile design supporting algorithm migration over time

Its purpose is simple:

to preserve signed timestamped claims about digital files — including who created them and who participated in their creation — in a form that remains independently verifiable for the very long term.