CPR Terms

Operator and Developer: Roberto Bourgonjen, a private individual in the Netherlands, operating under operator code fndr
Address: Lange Leidsedwarsstraat 96, 1017 NM Amsterdam, the Netherlands
Applies to: the Catalog Provenance Registry ("CPR") service operated by the Operator (the "Service")
Last updated: 2026-10-15

1. Parties and scope

  1. Roberto Bourgonjen ("Developer") develops and owns the CPR software and related intellectual property, including the Bitcash trademark.
  2. Roberto Bourgonjen also operates the CPR Service himself, as a private individual ("Operator"), under operator code fndr. Where these Terms refer to a license from the Developer to the Operator, that license has effect when the role of Operator is held by another party (§19.5); while the Developer is the Operator, he provides the Service under his own rights.
  3. These Terms govern your access to and use of the CPR Service operated by the Operator. They do not replace or modify the Catalog EULA and Cloud Services Terms, the Catalog.ID Membership Agreement, or other applicable terms, which continue to apply where relevant.

Contact: [email protected]

2. Acceptance

By accessing or using the CPR Service, you agree to these Terms. If you do not agree, do not use the Service.

3. Definitions

  • CPR Service / Service: the CPR service operated by the Operator, including its APIs, storage, block production, XRPL anchoring, replication, and verification endpoints.
  • CPR Network: the CPR nodes operated by the Operator, together with the replicas that hold copies of their blocks and claims. Each node maintains its own block chain and replicates data from the other nodes.
  • Node: one instance of the CPR service, identified by a unique node identifier (such as fndr), operator key pair, and jurisdiction (country code).
  • Global resolver: the redirect service at bit.pub that routes requests to an appropriate node. The resolver does not retrieve data or handle payments.
  • Asset ID: a 12-character alphanumeric service identifier assigned to each registered asset, in the format of four lowercase letters, four digits, and four lowercase letters (e.g. qjrm4821xwpa). Asset IDs are generated by deterministic encoding of internal sequence numbers. The AssetID format, encoding algorithm, and resulting namespace are copyrighted works of the Developer, licensed to clients in exchange for BIT payments. An Asset ID is a service identifier, not a personal data element, and functions analogously to a Catalog.ID username within the CPR system. Asset ID licences must be obtained from the Operator before use (see §7.2a).
  • Catalog Asset Licence (CAL): the permanent, freely assignable contractual right (this Agreement) to use an Asset ID through the CPR Service. A CAL is identified by an Asset ID and is held by the current owner of the CAL (the licensee, as recorded by the Operator). The grant scope, payment terms, assignment, and limitations are set out in these Terms and summarised in CPR Whitepaper §4.1 and §8.2.0. See §15.1a for the licensing chain.
  • License receipt: a cryptographically signed document issued by the Operator confirming that the buyer has obtained a CAL for one or more Asset IDs, binding the licensed Asset IDs to the licensee's public key (the owner key of the CAL). The receipt is signed with the key of the issuing node and is verifiable on every node of the CPR Network. The issuing node is the home node for the licensed range and is the authoritative source for the current owner key of any Asset ID in that range (see §8.3).
  • Owner key: the public key currently named, in the Operator's internal record at the home node, as the holder of a CAL. The owner key reflects the most recent of (a) the licensee's public key as recorded at licence issuance, and (b) any ownership-rebinding registration claim accepted against that Asset ID. The owner key is the cryptographic gate for registration writes to the Asset ID and is resolved by the home node on request.
  • Licensee / owner of the CAL: the key holder of the current owner key for an Asset ID. Holds the CAL and the right to exercise registry control over the Asset ID. The licensee may reassign the CAL freely by signing an ownership-rebinding registration claim that names a new owner key (see §13b). In this document, "owner" in relation to an Asset ID means the owner of the CAL — not the owner of the Asset ID itself (the AssetID is a service identifier licensed to users, not owned by them; see §15.1a) and not the owner of the cryptographic key.
  • Registry control: authority to submit future CPR claims for an Asset ID. Registry control does not by itself establish legal title in any work registered through the Asset ID, copyright ownership, authorship, or exclusive rights in content; those are matters of substantive intellectual property law, addressed by attribution claims, agreements outside CPR, and applicable law.
  • Catalog Physical Object Marker (POM): the printed, self-adhesive label of one Asset ID, supplied on the Developer-printed label sheets that ship with a physical CAL purchase. The label carries the Asset ID as a barcode, as text, and as the URL catalog.org/{asset_id}, together with a confetti marker unique to that Asset ID. POMs are explicitly not authentication tokens, not Physically Unclonable Functions, and not the input to any automated authentication-as-a-service offering by the Operator or the Developer. See §13c and CPR Whitepaper §18.
  • Claim: a structured signed statement submitted to CPR asserting authorship, participation, publication, correction, revocation, or dispute concerning a digital file or asset.
  • Claim ID: a composite service identifier assigned to each accepted claim, in the format {asset_id}.{operator_id}.{sequence} (e.g. qjrm4821xwpa.fndr.1), where asset_id is the Asset ID of the asset to which the claim relates, operator_id is the identifier of the node that accepted the claim, and sequence is an integer sequence number assigned by that node. Claim IDs are deterministically derived and unique within the CPR Network.
  • Claim manifest: the canonical structured object signed by the claimant and submitted to CPR.
  • Block: a per-node time-bounded batch of accepted claims, chained by previous block digest and anchored to XRPL.
  • BIT / BIT tokens ("BIT"): tokens used as the pay-as-you-go usage mechanism for the Service, issued by the Operator through the Bitcash payment system. See Bitcash Whitepaper.

4. Nature of the Service

CPR is a registry that records timestamped, cryptographically signed claims about digital files and assets. When you submit a claim — for example asserting authorship of a photograph, participation in a recording, or publication of a document — CPR accepts the claim, stores it in a tamper-evident block chain, and anchors that block to a public ledger (XRPL) so that the timestamp can be independently verified. The result is a durable, machine-verifiable record that a specific claim was made, by a specific key holder, at a specific point in time.

CPR is not:

  • a court;
  • a public notary;
  • a guarantee of legal title;
  • a guarantee of authorship;
  • a guarantee of authenticity of underlying files;
  • a guarantee of uninterrupted perpetual availability;
  • a final adjudication of truth.

5. Eligibility and authority

  1. Age requirement. You must be at least 18 years old to use the Service. By accepting these Terms, you represent that you are 18 or older.
  2. Legal capacity. You may use CPR only if you have the legal capacity to enter into these Terms and to make the submitted claims.
  3. Representations. You represent and warrant that:
    • you have authority to submit the claim;
    • the claim data you submit is accurate to the best of your knowledge;
    • your use of CPR does not violate applicable law or third-party rights;
    • you will not use CPR to submit unlawful, misleading, fraudulent, abusive, or malicious claims;
    • you are the current owner of the Asset ID licence (the licensee) for each Asset ID for which you submit registration claims, whether as the original licensee named in the license receipt or by subsequent ownership rebinding.
  4. Jurisdiction limits. The Operator may restrict service availability to certain jurisdictions or user categories to comply with law or manage risk.

6. Structured submission only

CPR accepts only structured machine-readable submissions according to the then-current CPR technical specification.

You may not submit arbitrary free text unless expressly permitted by a future specification.

Registration claims for an Asset ID must be signed by the Asset ID's current owner key, as resolved by the Asset ID's home node (see §3 and §8.3).

The Operator may reject, normalize, or discard malformed or non-conforming submissions.

7. Micropayments and fees

  1. Purpose. BIT micropayments serve two purposes: compensating for the costs of infrastructure and resources, and preventing spam and abuse. See Bitcash Whitepaper for the full description of the micropayment system.
  2. Write operations (PUT). Each write operation is charged exactly 1 BIT per kilobyte of payload, or portion thereof (e.g. a 3.2 KB claim manifest costs 4 BIT). This fixed rate enables integrators to purchase BIT tokens in bulk beforehand, securing guaranteed access at a known cost without exposure to future price increases.
    2a. Asset ID licence fee. Each Asset ID licence costs exactly 1 BIT. Asset ID licences may be purchased individually or in batches. The licence fee is separate from the per-kilobyte write fee for claim submission (§7.2). Purchasing an Asset ID licence reserves the identifier, grants the buyer a permanent, freely assignable licence to use the Asset ID through the Service (see §13b and §15.1a), and binds the Asset ID licence's initial owner key to the buyer's public key; submitting claims against the Asset ID incurs the standard write fee. It is recommended that each local installation of the Catalog software (mail client, camera capture application, desktop editor, or other tool) purchases and maintains its own pool of Asset ID licences to avoid conflicts between installations. No network connectivity is required at the moment of asset creation when using a pre-purchased pool.
  3. 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 enables integrators to purchase BIT tokens in advance for guaranteed medium- to long-term access at a predictable cost.
  4. Authorization. By using a paid CPR operation, you authorize the required consumption, transfer, or deduction of the corresponding amount of BIT according to the payment flow offered by the Operator.
  5. Separate Bitcash terms. The terms governing BIT tokens, Bitcash wallets, wallet balances, spending authorization, refunds, reversals, payment errors, and related matters are defined separately in the Bitcash terms published by the Operator and any applicable Bitcash end-user license terms.
  6. Separate costs. CPR access fees are separate from any network fees, wallet fees, exchange costs, or third-party payment costs that may apply.
  7. Non-refundable. Unless stated otherwise by mandatory law or the Operator's published policy, paid CPR operations are non-refundable once performed.
  8. Node routing. The global resolver at bit.pub/ may direct you to a particular node of the CPR Network. You may also select a node explicitly.
  9. Bitcash trademark. "Bitcash" is a trademark owned by the Developer.

8. Signatures and keys

  1. You are responsible for the generation, safekeeping, security, backup, and lawful use of your cryptographic keys.
  2. Registration claims may be signed by any key. The submitter does not need to prove Catalog.ID membership — only payment and a valid signature are required. Attribution claims must be signed with a published (non-anonymous) CPR signing key registered to a Catalog.ID account. CPR verifies this at submission time and rejects attributions signed with anonymous, unregistered, or revoked keys.
  3. License issuance and owner resolution. When you purchase Asset ID licences, the Operator records you as the licensee for the licensed Asset IDs in its own internal registry and issues you a license receipt signed with the Operator's key as evidence of the transaction. The receipt is for your own records and dispute resolution purposes; the Service does not require you to present it to authenticate submissions. The current owner key for any Asset ID is resolved from the Operator's internal record at the Asset ID's home node, which reflects the original licence issuance and any subsequent ownership rebindings (see §13b). Only the current owner key may submit registration claims for the Asset ID. Attribution claims are not subject to this restriction.
  4. CPR may rely on submitted signatures and public keys as technical evidence of control of a key.
  5. Loss, compromise, reuse, or misuse of keys is your responsibility, except to the extent caused directly by the Operator's own breach.
  6. Per-machine keys. CPR signing keys are generated per-machine. Each machine on which the Catalog software is installed generates its own keypair; the private key is stored only on that machine and is not part of your Catalog.ID key bag. You may have multiple CPR signing keys across different machines (one per machine). Each key may be published (enabling attribution signing) or kept anonymous (enabling only registration signing).
  7. Key loss. If a machine is lost or destroyed, the CPR signing key on that machine is gone. You should revoke the corresponding cpr_signing_key claim in Catalog.ID and generate a new key on the replacement machine. Your existing CPR claims signed with the old key remain valid and immutable. If your Catalog.ID account is terminated due to identity key loss, you may re-register with a new identity. Existing CPR claims remain in the immutable record under your old identity. New claims are submitted under your new identity.
  8. Key compromise. If a CPR signing key on one of your machines is compromised, you should immediately revoke that key's cpr_signing_key claim in Catalog.ID. Because CPR signing keys are per-machine and not part of the key bag, compromise of one machine's key does not affect your other machines or your identity keys. Generate a new key on the affected machine if needed. Existing CPR claims signed with the compromised key remain valid and immutable. Between compromise and revocation, an attacker with access to the key may submit claims; CPR does not reverse accepted claims. If your identity keys (key bag) are also compromised, initiate a full account lockdown (see the Catalog.ID Membership Agreement §5.6).

9. Post-quantum cryptography

CPR is designed to require post-quantum cryptographic signatures for claim submission, according to the protocol version and cryptographic profile then supported by the Operator.

You acknowledge that:

  • CPR may require use of specific post-quantum signature algorithms and parameter sets;
  • CPR may reject submissions that use non-conforming signature algorithms;
  • CPR may migrate supported cryptographic algorithms over time as standards evolve;
  • XRPL anchoring is used as an external timestamp anchor and is not represented as a post-quantum signature system.

10. Privacy and data minimization

  1. Minimized immutable data. CPR is designed to minimize immutable data. Users must not submit personal data or confidential data unless the current CPR specification clearly permits it.
  2. Prohibited content. In particular, users must not include in immutable claim submissions:
    • names;
    • email addresses;
    • phone numbers;
    • addresses;
    • filenames containing personal data;
    • captions, notes, or descriptions containing personal data;
    • any unlawful or sensitive content.
  3. Pseudonymous service identifiers. CPR attribution claims may include Catalog.ID usernames (e.g. khu3758iop) as party identifiers. Catalog.ID usernames are service identifiers owned by the Developer and licensed to individual members. They are not personal data in the CPR context: CPR nodes have no access to Catalog.ID and no means to resolve a username to a real-world identity. The mapping from username to personal data is encrypted end-to-end within the Catalog.ID system and requires the member's active cooperation to reveal. After account termination in Catalog.ID, a username becomes a dead identifier that no longer resolves to any identity. By submitting an attribution claim that identifies a party, you represent that you have authority to include that party in the claim, and that the party is identified by their Catalog.ID username only. Similarly, CPR Asset IDs and Claim IDs are service identifiers owned by the Developer and licensed to users. Asset IDs are generated from a deterministic encoding of internal sequence numbers (see §3) and do not contain or encode personal data. Like Catalog.ID usernames, they serve as pseudonymous references within the CPR system.
  4. Enforcement. The Operator may define, enforce, or tighten data-minimization rules and may reject submissions that appear to violate them.
  5. Separate systems. Where the Operator provides separate mutable systems for account administration, billing, wallet operation, abuse handling, or support, those systems may be governed by separate privacy notices or terms.
  6. Data protection. The Operator processes personal data in accordance with the General Data Protection Regulation (GDPR) and applicable Dutch data protection law. Your rights — including access, rectification, portability, erasure, restriction, and objection — are described in the Privacy Policy. Because CPR is designed for long-term retention and replication, certain deletion or erasure requests may not be fulfillable for content already accepted into the immutable claim layer, while the Operator may still be able to restrict access or apply other safeguards depending on the circumstances.
  7. Voluntary de-anonymization. If you choose to publicly associate your Catalog.ID username with your real-world identity (e.g. on a personal website or social media profile), CPR is not the controller of that voluntarily disclosed association. CPR did not create, store, or publish the link between your username and your personal identity. The right to erasure with respect to the identity behind a username is exercised through Catalog.ID (which destroys all encrypted identity data upon account termination), not through CPR. After account termination in Catalog.ID, your username in CPR records becomes a dead service identifier that no longer resolves to any identity. See CPR Whitepaper §7.3 for the full analysis.

11. Preservation and availability

  1. The Operator aims to preserve CPR records for the very long term on a best-effort basis. The CPR Network replicates blocks and claims across multiple nodes and replicas to improve durability and resilience. However, CPR is provided without any promise that records, endpoints, domains, storage media, or infrastructure will remain available forever or in unchanged form.
  2. The Operator may migrate storage, formats, software, domains, or infrastructure while seeking to preserve verifiability and continuity.
  3. Claims submitted to a node may be replicated to the other nodes and replicas of the CPR Network, including in other jurisdictions. Replication is intended to improve preservation and verification availability.

12. Blocking, rejection, and abuse control

The Operator may reject, rate-limit, delay, annotate, hide from public interfaces, or otherwise restrict any submission or lookup activity that the Operator reasonably believes to be:

  • unlawful;
  • abusive;
  • fraudulent;
  • technically harmful;
  • privacy-invasive;
  • misleading;
  • in violation of applicable export control or sanctions laws;
  • incompatible with CPR policies or mission.

This may include duplicate spam, automated abuse, attempts to overload the service, or claims submitted in bad faith.

13. Public lookup and publication

  1. CPR may expose claim-related information through public or semi-public lookup interfaces.
  2. The exact fields available through public lookup are determined by the Operator's published policies and technical implementation.
  3. The Operator may provide annotations such as:
    • conflicting claim;
    • disputed claim;
    • withdrawn claim;
    • superseded claim;
    • abusive submission hidden from public index.
  4. Such annotations do not necessarily imply a legal determination.
  5. Publication muting. The Operator may mute any claim or attribution — excluding it from standard query responses — for reasons including error correction, legal compliance, abuse, or editorial discretion. A party referenced in an attribution claim may request that the publisher mute that record (see CPR Whitepaper §7.6). Muting is a publication-layer decision managed in the node's operational database; it does not modify the immutable layer. A muted claim is annotated as muted and, where appropriate, with the reason for muting.

13a. Registration locking

Registration locking. The current owner of an Asset ID licence (the licensee, as resolved by the Asset ID's home node) may lock the Asset ID against further registration claims, freezing its file state. A locked Asset ID accepts no new registrations or superseding claims. Locking does not affect attribution claims — any party with a published Catalog.ID signing key may submit attributions for a locked Asset ID. The current owner may unlock the Asset ID at any time.

13b. Ownership rebinding (Asset ID licence assignment)

The current owner of an Asset ID licence may at any time reassign the licence to a different owner key by signing an ownership-rebinding registration claim that names the new key (see CPR Whitepaper §6.2). From acceptance of the rebinding claim forward, the Operator records at the home node the named key holder as the licensee and the new key as the Asset ID licence's owner key.

At the registry layer, CPR does not distinguish between (a) the same licensee rotating their own owner key (after device replacement, key compromise, or recovery-kit reconstitution) and (b) the Asset ID licence being assigned to a different party (private sale, gift, inheritance, institutional accession, court-ordered reassignment). Both are the same operation. The Asset ID licence follows the owner key.

You may freely reassign the Asset ID licence by rebinding the owner key without Operator consent. Rebinding does not by itself transfer any copyright, authorship, or substantive rights in works registered against the Asset ID; it transfers registry control only. The new owner succeeds to the rights and obligations of the licensee under these Terms in respect of that Asset ID from the rebinding forward. Where the Asset ID is associated with real-world assets (digital files, physical works, archives, recordings), transfer of ownership in those assets is governed by the external commercial or legal instrument (bill of sale, deed of gift, donor agreement, will) and is not automatic; the rebinding records only the Asset ID licence assignment.

13c. Catalog Physical Object Marker (POM)

  1. Optional product. A POM is the printed label of an Asset ID, supplied on the label sheets that ship with a physical CAL purchase. A CAL owner is not required to purchase physical sheets and may operate their Asset IDs purely digitally. The POM mechanism is described in CPR Whitepaper §18.

  2. Acquisition and fee. Label sheets are sold by the Operator as part of a physical CAL purchase: twenty pre-cut labels per sheet, one Asset ID per label, in printed order. A physical purchase costs the regular CAL fee plus a premium per sheet, published in the Operator's fee schedule, which reflects the cost of manufacturing the custom label sheets. There is no separate POM transaction, and using a label involves no claim and no write fee. The sheets are printed by the Developer and supplied to the Operator as stock (§13c.6).

  3. Binding to the Asset ID. A POM is bound to its Asset ID from the moment it is printed. No registration, detachment, or re-registration claim exists or is required. There is one label per Asset ID. The label follows the CAL: after an ownership rebinding (§13b) the new owner of the CAL holds the Asset ID the label carries, and no action on the label is needed.

  4. Physical attachment. Physical attachment of a POM to an object is your act, outside the CPR Service, and the CPR Service records nothing about it. You are advised to attach the label where it is not on display, to photograph the object with the label attached, and to keep the carrier sheet from which the label was peeled, which is the primary means of verifying the label later (§13c.8).

  5. Reserved series. The Developer may reserve series of Asset IDs for particular label products, including a series that is available only as physical labels. The availability and conditions of such series are published by the Operator.

  6. Design intellectual property and central manufacturing. The label design, the confetti marker, the algorithm that generates it, and the production seed are intellectual property of the Developer. The Developer prints the label sheets centrally and supplies the Operator with sheet stock; the Operator does not print labels and holds no production rights. You receive a licence to use the labels you have purchased on physical objects. You receive no right to reproduce, duplicate, print, or commission the printing of labels or markers, and no right to the production seed or to the digital reference of any marker.

  7. Photographs; storage only. You may, at your own initiative and expense, photograph a label on an object and make macro photographs of a label, upload them to Encrypted Filestorage encrypted under your own key, and register the file digests in CPR through standard registration claims. The Operator's role with respect to such photographs is strictly storage, replication, retrieval, and digest-anchoring; the Operator does not analyse the photographs, does not index them by visual content, does not maintain any reference set of label appearances, and does not perform any visual or computational comparison between uploaded photographs and any other material. The Operator does not offer, and will not provide, any service in the nature of "compare this image to a stored reference and return an authenticity verdict." Any comparison the Developer makes against the digital reference of a marker (CPR Whitepaper §18.5) is a manual act at the Developer's discretion and is not a service under these Terms.

  8. Verification responsibility. Any verification of a label or of a physical object's authenticity is your responsibility. CPR Whitepaper §18.5 describes the three routes: inspection of the label's characteristics by whoever holds the work; comparison of the label with the carrier sheet kept by the original purchaser or gallery, on which the copy of the marker and the cut fibres of the label align; and comparison by the Developer against the digital reference, which is not distributed. The Operator's roles are limited to: (i) selling genuine Developer-printed sheets, (ii) serving catalog.org/{asset_id} URL resolutions, and (iii) storing and serving your encrypted photographs as ordinary EFS material when you choose to upload them.

  9. No PUF, no authentication-as-a-service positioning. The POM is provided to you as (a) the printed label of an Asset ID, resolving to the Asset ID's hub, and (b) a label carrying a marker whose copy on the carrier sheet you keep and whose digital reference the Developer alone can regenerate. The POM is not offered as a Physically Unclonable Function, not offered as a self-sufficient authenticity token, and not the input to any automated authentication service operated by the Operator or the Developer. You acknowledge that nothing in your purchase, attachment, or use of a POM creates any obligation on the part of the Operator or the Developer to verify or attest the authenticity of any physical object on your or any third party's behalf.

  10. No legal title in the underlying object. A POM attached to a physical object does not by itself establish legal title in that object, does not transfer any rights in the object, and does not constitute a representation by the Operator about the object's provenance, authenticity, or value. POM attachment is a record-keeping act by you.

  11. Counterfeit labels and reporting. If you encounter a label that appears not to be a genuine Developer-printed label, or whose Asset ID record materially conflicts with the object it is attached to, you may report this to the Operator. The Operator's response is governed by its abuse and dispute-handling procedures (§§12, 23) and is not an authentication service.

14. Attribution and identity associations

  1. Pseudonymous attribution. CPR attribution claims identify parties by their Catalog.ID usernames in the immutable claim layer, and identify assets and claims by their Asset IDs and Claim IDs respectively. These are service identifiers owned by the Developer (see §3 and §10.3) that enable attribution and co-authorship tracking without exposing personal identity.
  2. Attribution signing requirement. Attribution claims must be signed with a published (non-anonymous) CPR signing key registered to a Catalog.ID account. CPR verifies at submission time that the signing key matches a published, non-revoked cpr_signing_key public claim on the claimant's account. This ensures that every attribution is cryptographically linked to a verifiable Catalog.ID username. If you unpublish your CPR signing key after submitting attribution claims, those attributions will be automatically muted (excluded from standard query responses) until the key is republished. This automatic muting is reversible — republishing the key restores the attributions to standard query responses.
  3. Registration signing. Registration claims (file manifests) may be signed by any key. The submitter does not need to prove Catalog.ID membership — only payment is required. This includes published keys, anonymous keys, and keys not associated with any Catalog.ID account.
  4. Attribution claims. By submitting an attribution claim that identifies a party, you represent and warrant that you have authority to attribute that party. Attributed parties may independently confirm or dispute their attribution by submitting their own attribution claims (see CPR Whitepaper §4.9).
  5. Account termination. When a party's Catalog.ID account is terminated, the party's username becomes a dead identifier that no longer resolves to any identity within Catalog.ID. Because usernames are permanently retired after account termination (see CPR Whitepaper §7.4), the username will never be reassigned to another member. Published CPR signing keys associated with the terminated account are effectively dead — they remain in the public record but the account behind them no longer exists.
  6. External identity association. You may associate your CPR signing key with a Catalog.ID account through the standard cpr_signing_key claim mechanism. Any such association is governed by the terms of Catalog.ID (see the Catalog.ID Membership Agreement), not by these CPR Terms.
  7. No CPR responsibility for accuracy. CPR and the Operator are not responsible for the accuracy of attributions or identity associations made in CPR claims. CPR records what claimants submit; it does not verify the accuracy of submitted data beyond the signing key verification described in §14.2.
  8. No personal data in claims. You must not include personal identity information (names, email addresses, phone numbers, etc.) in immutable CPR claim submissions. Attribution must use Catalog.ID usernames only. If you voluntarily de-anonymize your username outside CPR, the provisions of §10.7 apply.

15. Intellectual property

  1. Software and service IP. The CPR software, specifications, branding, and related materials are owned by the Developer. These Terms do not grant you ownership of CPR software, trademarks, or service materials.
    1a. AssetID namespace and the Catalog Asset Licence (CAL). The AssetID format, the encoding algorithm used to generate Asset IDs from internal sequence numbers, and the resulting AssetID namespace are copyrighted works and intellectual property of the Developer. Individual Asset IDs and Claim IDs are service identifiers licensed to users in exchange for BIT payments (see §3). The Operator issues Catalog Asset Licences (CALs) to end users for a fee, each CAL identified by an Asset ID; end users hold a permanent, freely assignable CAL evidenced by a license receipt naming the licensee's owner key. If the role of Operator passes to another party (§19.5), the Developer licenses Asset ID allocation rights to that party free of charge, the CALs it issues are sublicences, and CALs issued before the transfer remain valid. The CAL is freely assignable by the licensee through ownership rebinding (see §13b), without Operator consent. This arrangement is analogous to the Catalog.ID username namespace: as with usernames, users receive a licence to use assigned identifiers within the Service but do not acquire ownership of the identifiers themselves.

1b. POM design IP. The label design, the confetti marker, the algorithm that generates it, and the production seed of the Catalog Physical Object Marker (POM) are intellectual property of the Developer, who prints the labels; buyers receive a licence with the scope and limitations described in §13c.

  1. Your content. You retain whatever rights you already hold in the digital works or files referenced by your submissions. CPR does not take ownership of your works merely because you register claims about them.
  2. License to operate. By submitting a claim manifest to the CPR Service, you grant the Operator, and any party that succeeds it in the role of Operator, a worldwide, non-exclusive, royalty-free, perpetual license to store, reproduce, replicate, and technically process the claim manifest and its associated metadata for the purposes of operating, maintaining, and preserving the CPR Service and Network. This license includes, without limitation, the right to:
    • include the claim manifest in blocks and anchor those blocks to external ledgers (including XRPL);
    • replicate the claim manifest and its containing block to the other nodes and replicas of the CPR Network, including in other jurisdictions;
    • serve the claim manifest through public and semi-public lookup and verification interfaces;
    • permit the holders of replicas to store, serve, and replicate the claim manifest in accordance with the CPR replication protocol.
      This license applies to the claim manifest data submitted to CPR, not to the underlying digital works or files referenced by your claims.
  3. Revocable publication license. The license granted in §15.3 to serve claim data through public and semi-public interfaces is subject to the following condition: if you submit a request to stop further publication of a claim or attribution (identifying the record by its Claim ID or Asset ID, and submitted by the original claimant or by a party referenced in the attribution) through the node that originally accepted the submission, the Operator propagates that request to the other nodes of the CPR Network through the replication protocol and excludes the specified record from the publication interfaces of every node. Any holder of a replica that serves records publicly must honor the request in the same way; a holder that fails to honor a properly propagated request is in breach of the license granted in §15.3 with respect to publication of that record. This obligation applies to publication only: it does not require deletion from the immutable data layer, and nodes and replicas may continue to store and replicate the claim for integrity, verification, and archival purposes.
  4. Irrevocability at the data layer. You acknowledge that once a claim manifest is accepted into a block and replicated to other nodes, it becomes part of an immutable, cryptographically chained record that cannot be modified or deleted at the data layer. The license to store, replicate, and technically process the claim manifest (§15.3) is irrevocable. The license to publish the claim through query interfaces may be curtailed by a request to stop further publication (§15.4). You should consider the permanent nature of CPR submission before submitting any claim.

16. No legal advice; no evidentiary guarantee

CPR is a technical registry service and does not provide legal advice.

The admissibility, relevance, and evidentiary weight of CPR records in any legal, administrative, or arbitral setting depend on the applicable law, procedures, facts, and decision-maker.

17. Disclaimers

To the maximum extent permitted by law, the Service is provided "as is" and "as available", without warranties of any kind, whether express, implied, or statutory, including implied warranties of merchantability, fitness for a particular purpose, and non-infringement.

Neither the Operator nor the Developer warrants that:

  • every submission will be accepted;
  • every accepted submission will remain publicly searchable;
  • every block will be anchored without delay;
  • every claim will be replicated to all nodes;
  • every node will remain operational;
  • every external dependency will remain available;
  • every claimant is truthful or authorized;
  • cryptographic algorithms will remain secure indefinitely, though the Operator will act in good faith to maintain crypto agility and migrate to updated algorithms as standards evolve.

Some jurisdictions do not allow certain disclaimers, so some of the above may not apply to you.

18. Limitation of liability

To the maximum extent permitted by law:

  1. Neither the Operator nor the Developer shall be liable for indirect, incidental, consequential, special, exemplary, or punitive damages, or for loss of profits, revenue, data, reputation, goodwill, or opportunity.
  2. The total aggregate liability of the Operator and the Developer arising out of or relating to the Service shall not exceed the amount you paid to the Operator for CPR operations in the 12 months before the event giving rise to the claim, or EUR 50 if you paid nothing, unless mandatory law requires otherwise.

19. Suspension, modification, and termination

  1. You may stop using the Service at any time.
  2. The Operator may modify, suspend, or discontinue CPR features, fee schedules, policies, or technical interfaces.
  3. The Operator may suspend or terminate your access for breach, security reasons, legal compliance, or non-payment.
  4. The Operator may update these Terms from time to time. Continued use of the Service after updated Terms become effective constitutes acceptance of the updated Terms, except where applicable law requires a different mechanism.
  5. Transfer of the role of Operator. The Operator may transfer the operation of the Service, together with its records and the Operator's rights and obligations under these Terms, to a company or other organisation that takes over the role of Operator. You consent in advance to such a transfer. The Operator announces a transfer before it takes effect, naming the successor. Accepted claims, Asset IDs, Claim IDs, CALs and owner keys remain valid and unchanged.

20. Force majeure

Neither the Operator nor the Developer shall be liable for delays or failures in performance of the Service resulting from events beyond reasonable control, including natural disasters, war, terrorism, cyberattacks, pandemic, government action, or internet/infrastructure failures.

21. Severability

If any provision of these Terms is held invalid, illegal, or unenforceable, the remaining provisions continue in full force. The invalid provision shall be modified to the minimum extent necessary to make it enforceable while preserving its intent.

22. Waiver

Failure or delay by the Operator or the Developer in enforcing a provision of these Terms does not constitute a waiver of that provision or of the right to enforce it later.

23. Governing law and disputes

23.1 Governing law

These Terms are governed by the laws of the Netherlands, excluding conflict-of-law rules, unless mandatory consumer law requires otherwise.

23.2 Disputes

This section applies to disputes between you and the Operator arising from or relating to these Terms or the Service.

Step 1 — Informal resolution (mandatory). Before initiating formal proceedings, you must contact the Operator at [email protected] describing your dispute. The Operator will attempt to resolve the matter within 30 days. You agree to engage in this step in good faith.

Step 2 — Mediation (mandatory). If Step 1 does not resolve the dispute, either party may refer the matter to mediation administered by a qualified mediator in the Netherlands, agreed upon by the parties or, failing agreement, appointed by the competent court. Each party bears its own mediation costs; the mediator's fees are shared equally. Mediation shall conclude within 60 days of referral unless the parties agree to extend.

Step 3 — Court (last resort). If the dispute is not resolved through Steps 1–2, either party may bring the dispute before the competent court in the Netherlands for the district in which the Operator is domiciled or established, unless mandatory consumer law requires a different court.

Muting requests. If you are a party referenced in a CPR attribution claim and you wish the record not to be displayed, you may request that the Operator mute the attribution by identifying the record by its Claim ID or Asset ID (see CPR Whitepaper §7.6). The Operator will process such requests in accordance with its published policies. If you believe a CPR claim affecting you was submitted in error or in bad faith, you may raise the matter through the dispute resolution process above. If you are a Catalog.ID member, the dispute resolution provisions of the Catalog.ID Membership Agreement (§§17–18) also apply.

Urgent relief. Nothing in this section prevents either party from seeking interim or injunctive relief from a competent court where necessary to prevent irreparable harm.

24. Contact

Roberto Bourgonjen, operator of the CPR Service
Address: Lange Leidsedwarsstraat 96, 1017 NM Amsterdam, the Netherlands
Website: catalog.org
Email: [email protected]