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-05-14

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 (a "FileID") 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 FileID 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 IDs must be purchased from an Operator before use (see §7.2a).
  • Purchase receipt: a cryptographically signed document issued by an Operator confirming the purchase of one or more Asset IDs, binding them to the buyer's public key. The receipt is signed with the issuing Operator's key and is verifiable by any Operator in the CPR Network.
  • 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 ownership;
  • 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 hold a valid purchase receipt for each Asset ID for which you submit registration claims.
  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 must include a valid purchase receipt proving the submitter's right to use the Asset ID (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 purchase. Each Asset ID costs exactly 1 BIT. Asset IDs may be purchased individually or in batches. The purchase price is separate from the per-kilobyte write fee for claim submission (§7.2). Purchasing an Asset ID reserves the identifier and binds it to the buyer's public key; submitting claims against it 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 IDs 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. Purchase receipt verification. When you purchase Asset IDs, the Operator issues a purchase receipt signed with the Operator's key, binding the purchased ID range to your public key. You must present this receipt when submitting registration claims. The receipt is verifiable by any Operator in the CPR Network. Only the key holder named in the purchase receipt may submit registration claims for the purchased Asset IDs. 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 bitpub_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 bitpub_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 (FileIDs) 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 owner of an Asset ID (the key holder named in the purchase receipt) may lock the asset against further registration claims, freezing its file state. A locked asset 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. The owner may unlock the asset at any time.

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 bitpub_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 bitpub_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. FileID namespace. The FileID format, the encoding algorithm used to generate Asset IDs from internal sequence numbers, and the resulting FileID namespace are copyrighted works and intellectual property of the Developer. The FileID 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 hierarchical model: the Developer allocates blocks of Asset IDs to Operators, and Operators sell individual Asset IDs to end users. The purchase receipt (see §3) represents a sublicense to use the purchased Asset ID within the Service. This arrangement is analogous to the Catalog.ID username namespace: as with usernames, users receive a sublicense to use assigned identifiers within the Service but do not acquire ownership of identifiers themselves.
  2. 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.
  3. 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.
  4. 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.
  5. 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]