Catalog Asset Registry

Public Description and Whitepaper

Working title: Catalog Asset Registry
Working URL: reg.catalog.org
Last updated: 2026-05-04
Author: Roberto Bourgonjen
Copyright: © 2026 Roberto Bourgonjen. All rights reserved.
Project: Catalog Asset Registry

1. Overview

Catalog Asset Registry is a long-term digital provenance service for registering signed claims about digital files. Asset Registry 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.

The Catalog Asset Registry 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.

Asset Registry 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 (Asset Library), and file storage and delivery (Encrypted Filestorage) — but it can also be used on its own. Asset Registry doubles as the suite's rights-management substrate: because every AssetID is bound to an owner key (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.

Asset Registry 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

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

1.1 Blockchain agnosticism

Asset Registry 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 Asset Registry 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

Asset Registry 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 Asset Registry 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 Asset Registry 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. Asset Registry 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 Asset Registry operators.
  • The XRPL transaction provides an additional public timestamp anchor, but is not itself the post-quantum security primitive.

3. Design Goals

Asset Registry 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
    Asset Registry 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 Asset

An asset is the logical work or provenance family, identified by its asset_id — a 12-character alphanumeric AssetID (see §8.1). One asset may include one master file and many derivative files. Asset IDs must be purchased before use — operators sell them at a fixed price of 1 BIT per ID (see §8.2.2). Only the key holder named in the purchase receipt can submit registration claims for that asset ID (see §8.2.3).

AssetID lifecycle states

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

  • Purchased. An operator has issued a purchase receipt (§8.2.3) binding the AssetID — or a contiguous range of AssetIDs — to a buyer's public key. The receipt is held privately by the buyer; the federation does not yet know the AssetID is in use. In this state the buyer may embed the AssetID into local files and metadata as part of offline preparation — tagging captured images, drafting descriptive metadata, editing derivative files — but no other Catalog module will accept actions against the AssetID. The receipt is a credential between the buyer and the registry only; it is not presented to other modules. The only service that accepts a submission for a purchased-but-unregistered AssetID is Asset Registry itself, and the only submission it accepts is the registration claim (§4.3).
  • Registered. The buyer has submitted a registration claim (§4.3) against the AssetID and a node has accepted it into a block (§4.6). The asset 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. Once registered, downstream modules — Encrypted Filestorage, Asset Library, and others — accept writes against the AssetID by consulting the registry to confirm registration and the current owner key (see §6.1).

The distinction means a purchased AssetID is ownership-bound but inert outside the registry: it exists in the buyer's local files and the operator's receipt, and nowhere else. A registered AssetID is ownership-bound and addressable by every module that consults the registry. AssetIDs are sold 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 Asset Registry, identified by its claim_id — a composite string in the format {asset_id}.{operator_id}.{sequence} (see §8.1.2). Asset Registry defines four 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 a purchase receipt proving ownership of the asset ID (see §8.2.3) — the submitting key must match the buyer's public key in the receipt.
  • 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) Asset Registry signing key that is registered to a Catalog.ID account (see §16.2a). The Asset Registry node verifies at submission time that the signing key is a published, non‑revoked bitpub_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 Asset Registry. This type has a different structure: no files, no parties, no file creation time (see §17).

The claim type describes the event being recorded. A registration with a supersedes_claim relation is a correction. 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 Asset Registry. 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 Asset Registry 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 Asset Registry 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.bit.pub), 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) Asset Registry signing key registered to a Catalog.ID account. The Asset Registry node verifies at submission time that the signing key matches a published, non‑revoked bitpub_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 Asset Registry signing key, an anonymous Asset Registry signing key registered to a Catalog.ID account, or any other key entirely. Only payment is required. This makes Asset Registry accessible to non‑Catalog.ID users (applications, institutions, archival systems) and supports anonymous file registration.

Asset Registry 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 Asset Registry 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 ownership 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 Asset Registry is designed to record. Attributions from different signers coexist independently.

5. Trust Model

Asset Registry 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
  • Asset Registry 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 Asset Registry Proves

Asset Registry is designed to prove the following:

  • a structured signed claim was submitted
  • the signed claim was accepted into a specific Asset Registry 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

Asset Registry 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)

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

6.1 Rights Authorization for Downstream Services

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

Downstream modules act on three Asset Registry signals:

  • Owner key (write authorization). The key holder named in a purchase receipt (§8.2.3) becomes the owner of the AssetID once a registration claim has been accepted. Encrypted Filestorage and Asset Library require a write request signed by the owner key to accept blobs or metadata against the AssetID, and they confirm both the AssetID's registered state and the current owner key by consulting the registry — they do not see or verify the receipt themselves. The receipt is purely between the buyer and the registry.
  • 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; Asset Registry 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 (hard threshold). Registration is the hard prerequisite for any non-registry activity against an AssetID. A purchased AssetID is invisible to every Catalog module except Asset Registry itself; downstream modules query the registry and reject writes for unregistered AssetIDs. This makes the registry the single source of truth: there is no parallel path by which a downstream module learns about an AssetID it has not been told about by the registry.

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

  • The registry records 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, Asset Registry takes no position.
  • The registry does not adjudicate disputes about ownership 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.

7. Privacy Posture

Asset Registry 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, Asset Registry 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

Asset Registry 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 Asset Registry'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. Asset Registry 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 Asset Registry 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. Asset Registry 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 Asset Registry 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 Asset Registry 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. Asset Registry 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 Asset Registry's and Catalog.ID's control and diminishes over time.

7.2.3 Lawful basis for processing

Asset Registry 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 Asset Registry 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)): Asset Registry 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 Asset Registry'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 Asset Registry.
  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, Asset Registry 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

Asset Registry and Catalog.ID are designed as complementary systems operated by related Operators. When a member has active public claims, the combined effect is that Asset Registry 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, Asset Registry's data protection posture rests on two pillars:

  1. Lawful basis: Asset Registry 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 Asset Registry 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 Asset Registry'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. Asset Registry 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, Asset Registry'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 Asset Registry's design.

This two-layered defense — erasure by de-identification as the primary mechanism, plus the archiving exception as a secondary basis — means that Asset Registry'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 Asset Registry'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. Asset Registry 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. Asset Registry signing keys must be generated exclusively for Asset Registry 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 Asset Registry signing key pair exclusively for Asset Registry 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.

Asset Registry 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

Asset Registry 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 Asset Registry identifier and submitted through the node that originally accepted the submission — that request is propagated to peer nodes in the Asset Registry 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 Asset Registry 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 bitpub_signing_key claim (returning it to anonymous status), all attribution claims signed by that key are automatically muted by each Asset Registry 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 bitpub_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 bitpub_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 bitpub_signing_key publish claim. From the Asset Registry 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. Asset Registry 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 bitpub_signing_key claims and therefore does not mute historical attributions. It only blocks new submissions until the organization is reactivated.

8. Provenance Model

Asset Registry 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 Asset Registry 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 Asset Registry 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 Asset Registry 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 allocation model.

8.2.1 Allocation from founder to operators

The Developer (Roberto Bourgonjen) allocates blocks of asset IDs to Asset Registry 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 represents a license to distribute the IDs commercially.

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 Sale from operators to end users

Operators sell asset IDs to end users at a fixed price of 1 BIT per asset ID. End users may purchase individual IDs or batches. No volume discounts are offered at the asset ID level — volume discounts are already available at the BIT purchase level (see Bitcash Whitepaper).

The asset ID purchase is separate from the per-kilobyte write fee for claim submission (§13.1). Purchasing an asset ID reserves the identifier; 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 purchase and maintain its own pool of asset IDs. This avoids conflicts: because each installation draws from its own pre-purchased range, no two machines can accidentally assign the same asset ID, and no network connectivity is required at the moment of asset creation. A typical installation might purchase a batch of 1,000–10,000 IDs and replenish when the pool runs low.

8.2.3 Purchase receipt

When an end user purchases asset IDs, the operator issues a purchase receipt — a signed document binding a range of asset IDs to the buyer's public key. The receipt contains:

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

The buyer converts purchased integers to AssetID strings locally using the cl-int2assetid algorithm. Any Asset Registry node can verify the receipt by checking the operator's signature against the federation's operator key registry.

A purchase receipt is required to submit a registration claim for an asset ID. The submitting key must match the buyer_public_key in the receipt. This ensures that only the purchaser of an asset ID can create registration claims for it.

No Catalog.ID account is required to purchase asset IDs or submit registration claims — only a valid key pair and a purchase receipt. Attribution claims remain open to anyone with a published Catalog.ID signing key, regardless of asset ID ownership.

8.2.4 Cross-operator submission

Because all Asset Registry nodes know each other's operator public keys through the federation, a receipt issued by one operator is verifiable by any other operator. An end user may purchase asset IDs from operator A and submit claims to operator B, providing the receipt as proof of ownership. The receiving operator verifies the receipt signature and confirms the asset ID falls within the signed range.

8.2.5 Registration locking

The owner of an asset ID (the key holder named in the purchase receipt) may lock the asset against further registration claims. A locked asset accepts no new registrations or superseding claims — the file state is frozen. The lock is recorded in the asset'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 asset.

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

9. Derivative Files

Asset Registry 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

10. Recommended Watermark and Metadata Policy

For public-facing visible watermarks, the recommended identifier is the asset ID, embedded as a Asset Registry resolution URL without the https:// prefix:

bit.pub/{asset_id}

For example: bit.pub/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.

Because claims are replicated across federation nodes, the same asset ID can be verified at any node. If the originating node is unavailable, the URL can be adjusted to any other node's prefix.

A global resolver at bit.pub/{asset_id} redirects requests to an appropriate node, 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. The resolver itself is a lightweight redirect service that does not retrieve data or handle payments.

For file metadata, the recommended identifiers are:

  • asset ID
  • file UUID
  • Asset Registry resolution URL

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

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

Asset Registry 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 Asset Registry 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 asset ID purchase cost of 1 BIT per ID (see §8.2.2). The asset ID purchase reserves the identifier; the per-kilobyte write fee applies each time a claim is submitted against it.

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

Asset Registry 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. Asset Registry 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 Asset Registry 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

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

16. Catalog.ID Integration

Asset Registry and Catalog.ID are designed as complementary systems. Asset Registry 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 Asset Registry signing key registered to a Catalog.ID account
  • an anonymous Asset Registry signing key registered to a Catalog.ID account
  • any other key entirely (e.g., an application key, institutional key, or ephemeral key)

This makes Asset Registry 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

Asset Registry attribution claims list Catalog.ID usernames with their roles. These are full signed transactions, included in blocks and anchored. Anyone who looks up a Asset Registry 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 Asset Registry 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) Asset Registry signing key registered to a Catalog.ID account. The Asset Registry node verifies at submission time that the signing key matches a published, non-revoked bitpub_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 Asset Registry 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 Asset Registry 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 bitpub_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 Asset Registry 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 Asset Registry 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 bitpub_signing_key claim through Catalog.ID's standard public claims flow, validated via key ownership 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 Asset Registry signing public key is stored as an encrypted Catalog.ID claim (bitpub_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 bitpub_signing_key claim via Catalog.ID's encrypted key-sharing protocol.
  2. The recipient's client decrypts the claim and learns the member's Asset Registry public key.
  3. The recipient's client can match that key against Asset Registry 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 ownership to arbitrators (who are Catalog.ID members) by sharing the encrypted bitpub_signing_key claim with them. The arbitrators decrypt the claim, match the public key against the anonymous Asset Registry 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 Asset Registry signing key on a Catalog.ID account. The Asset Registry 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 ownership validation

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

The validator issues a cryptographic certificate proving key ownership without retaining any persistent association between the member's identity and the key. Because Asset Registry 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 bitpub_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 bitpub_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 Asset Registry 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; Asset Registry for optional confidential payload encryption)

Asset Registry 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 Asset Registry signing key does not expose Catalog.ID identity keys, and vice versa.

17. Registry Anchoring and Claim Chaining

17.1 Registry anchoring

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

External registry operations → Merkle root → Asset Registry claim → Asset Registry 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 Asset Registry. 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 Asset Registry claims using the previous_claim_id and sequence_number extension fields. This forms a per-claimant append-only chain within Asset Registry, 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. Asset Registry 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. Summary

Asset Registry 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 Asset Registry signing key registered to a Catalog.ID account
  • per-machine Asset Registry 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
  • four claim types: registration (files), attribution, revocation, and registry anchor
  • compact identifiers: 12-character AssetID for assets, composite claim IDs encoding asset, operator, and sequence
  • 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 namespace distribution: the Developer allocates ID blocks to operators, operators sell individual IDs to end users at 1 BIT per ID
  • receipt-based asset ID ownership verification: registration claims require a purchase receipt binding the asset ID range to the submitter's public key
  • registration locking: asset owners 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.