CPR Terms

Operator: Stichting Outpapier, identified by Operator ID b4np (Netherlands)
Developer / IP Owner: Roberto Bourgonjen
Applies to: the Catalog Provenance Registry ("CPR") service operated by the Operator (the "Service")
Last updated: 2026-09-23

1. Parties and scope

  1. Stichting Outpapier ("Operator", "we", "us") operates the CPR Service under a license from the Developer.
  2. Roberto Bourgonjen ("Developer") develops and owns the CPR software and related intellectual property, including the Bitcash trademark.
  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: outpapier.nl — [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 federated network of CPR nodes operated by the Operator and other participating foundations. Each node maintains its own block chain and replicates data from peer nodes.
  • Node: one independently operating CPR federation member, identified by a unique node identity, operator key pair, and jurisdiction (country code).
  • Global resolver: the redirect service at bit.pub that routes requests to an appropriate node, preferring a node in the requester's jurisdiction. 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 the Operator, and sublicensed 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 an 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 resolved by the home 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 three-tier licensing chain (Developer → Operator → CAL owner).
  • License receipt: a cryptographically signed document issued by an 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 issuing Operator's key and is verifiable by any Operator in the CPR Network. The issuing Operator is the home operator 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 home operator's internal record, 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 operator on request.
  • Licensee / owner of the CAL: the key holder of the current owner key for an Asset ID. Holds the CAL from the Operator 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 sublicensed 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): an optional, tamper-evident physical label issued in batches by the Operator, bearing a unique POM serial and a QR code resolving to catalog.org/pom/{pom_serial}. POMs are sold as unregistered generic batches and are bound to a specific Asset ID at the moment of use via a pom_registered claim. POMs are explicitly not authentication tokens, not Physically Unclonable Functions, and not the input to any authentication-as-a-service offering by the Operator or the Developer. See §13c and CPR Whitepaper §18.
  • POM serial (pom_serial): a globally unique alphanumeric identifier of a POM, printed on the POM at manufacture and verifiable against the Operator's manufacturing record. POMs are sold unregistered (POM serial only) and remain so until the CAL owner submits a pom_registered claim binding the POM serial to one of their Asset IDs.
  • 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.b4np.1), where asset_id is the Asset ID of the asset to which the claim relates, operator_id is the 4-character Operator ID 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. BIT purchase, holding, and spending are additionally governed by the Webshop Terms. 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. We 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 operator (see §3 and §8.3).

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

7. Micropayments and fees

  1. Non-profit basis. CPR is operated on a non-profit basis. BIT micropayments serve two purposes: compensating for the costs of infrastructure and resources, and preventing spam and abuse. 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 Webshop Terms 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. Jurisdiction routing. Since operations may involve micropayments, you may be required to interact with a CPR node in your own jurisdiction. The global resolver at bit.pub/ may direct you to a node in your jurisdiction for this purpose. You may also select a node explicitly.
  9. Bitcash trademark. "Bitcash" is a trademark owned by the Developer and used under license.

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 by the Asset ID's home operator's internal record, 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, licensed to the operating foundation, and sublicensed 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, licensed to the Operator, and sublicensed 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 (published on outpapier.nl). 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 uses federated replication across multiple nodes 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 the Operator's node may be replicated to peer nodes operated by other foundations as part of the CPR federation protocol. 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 operator) 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 home operator records 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. POMs are an optional product offered by the Operator. A CAL owner is not required to purchase POMs and may operate their Asset IDs purely digitally. The POM mechanism is described in detail in CPR Whitepaper §18.

  2. Acquisition and fee. POMs are sold by the Operator in batches, typically as physical sheets of multiple unregistered POMs, each carrying a unique POM serial. The purchase of POMs is a separate transaction from the purchase of CALs. The Operator charges a mandatory minimum of 250 BIT per POM (approximately 5 euro cent at the standard BIT-to-fiat reference rate). This minimum is mandated network-wide and is not waivable. On top of this minimum, the Operator charges an Operator-determined distribution fee covering physical shipping, handling, packaging, customs, and any other operational costs of delivering the POMs to you. The underlying manufacturing, security-feature, and substrate costs of POMs are borne by the Developer, who produces POMs centrally and provides physical POM inventory to the Operator at no cost as part of the Operator's service licence; the per-POM fee underwrites the network supply chain.

  3. Registration to a CAL. A POM is bound to one of your Asset IDs by submitting a pom_registered claim signed by the current owner key of that CAL. From acceptance of the claim, the POM serial is recorded as registered against that Asset ID and catalog.org/pom/{pom_serial} resolves to the Asset ID's hub. A POM may be registered to only one Asset ID at any time.

  4. Physical attachment. Physical attachment of a registered POM to an object is your act, outside the CPR Service. POMs are manufactured on a destruct-on-removal substrate; attempting to remove and reattach a POM is contractually prohibited and physically detectable. If you need to anchor a different object, you must first submit a pom_detached claim (§13c.5) and then either register a fresh POM or, after detachment, register the detached POM serial to a new Asset ID.

  5. Detachment and re-registration. You may release a POM's binding by submitting a pom_detached claim signed by the current owner key of the bound CAL. The claim may state a reason from a defined enum (physical destruction, loss, object disposal, supersession, separate transfer, other). After acceptance the POM serial returns to "registrable" state and may be re-registered to a different Asset ID. CPR does not require the physical POM to be present, recovered, or destroyed; the detachment is a record-keeping act by you, and you are responsible for keeping the registry record consistent with physical reality.

  6. POM design intellectual property and central manufacturing. The POM design, security-feature specification, substrate engineering, and embedded covert features are intellectual property of the Developer. The Developer produces POMs centrally (directly or through a contracted specialist security printer) and provides physical POM inventory to the Operator at no cost as part of the Operator's service licence. The Operator does not manufacture POMs, holds no POM production rights, and does not maintain its own POM serial namespace; the Operator's role with respect to POMs is distribution to end users only. You, the buyer, receive a sublicence in the POM design IP with use rights limited to the lifecycle described in CPR Whitepaper §18 and this §13c. You receive no rights to reproduce, duplicate, manufacture, or commission manufacture of POMs; to reverse-engineer or forensically disclose any covert security features; or to transfer an attached POM to a different physical object without going through the pom_detached + re-registration flow first.

  7. Photographic anchoring; storage only. You may, at your own initiative and expense, capture photographs of POM-on-object states and upload them to Encrypted Filestorage encrypted under your own key, and you may 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 POM 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 such comparison, if you choose to perform it, is your act, on your equipment, with your own decrypted material.

  8. No PUF, no authentication-as-a-service positioning. The POM is provided to you as (a) a tamper-evident physical label with anti-counterfeit features that make casual reproduction visibly difficult, (b) an identifier resolver via the QR code, and (c) added physical entropy that supplements an object's own characteristics in your private reference photographs (§13c.7). The POM is not offered as a Physically Unclonable Function on its own, not offered as a self-sufficient authenticity token, and not the input to any authentication service operated by the Operator or the Developer. You acknowledge that nothing in your purchase, registration, 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.

  9. Verification responsibility. Any verification of a physical object's authenticity, including comparison of a POM and surrounding object state to your stored reference photographs, is your responsibility. The Operator's roles are limited to: (i) issuing genuine POMs from its manufacturing record, (ii) recording POM registrations, detachments, and re-registrations through the CPR Service, (iii) serving catalog.org/pom/{pom_serial} URL resolutions, and (iv) storing and serving your encrypted photographs as ordinary EFS material when you choose to upload them.

  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 POMs and reporting. If you encounter a POM that appears to fail physical inspection or whose registry record materially conflicts with the physical state of 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 and licensed to the Operator. 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. The AssetID namespace is licensed from the Developer to the Operator as part of the CPR service license. Individual Asset IDs and Claim IDs are service identifiers sublicensed to users in exchange for BIT payments (see §3). Individual Asset IDs are distributed through a three-tier licensing chain: the Developer licenses Asset ID allocation rights to Operators free of charge; Operators issue 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. 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 sublicence to use assigned identifiers within the Service but do not acquire ownership of the identifiers themselves.

1b. POM design IP. The physical design, security-feature specification, substrate engineering, and embedded covert features of the Catalog Physical Object Marker (POM) are intellectual property of the Developer, licensed to the Operator for production and sublicensed to POM buyers 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 each node operator in the CPR Network 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 peer nodes operated by other foundations in the CPR Network, including nodes in other jurisdictions;
    • serve the claim manifest through public and semi-public lookup and verification interfaces;
    • permit peer node operators to further store, serve, and replicate the claim manifest in accordance with the CPR federation 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 will propagate that request to peer nodes in the CPR Network in accordance with the federation protocol. Each peer node operator is obligated to honor the request by excluding the specified record from its own publication interfaces. A node operator that fails to honor a properly propagated request to stop further publication 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 peer nodes 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 peer 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 federation nodes;
  • every federation 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. We 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.

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 jurisdiction of the Operator in the Netherlands, 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

Stichting Outpapier
Website: outpapier.nl
Email: [email protected]