Bitcash Whitepaper

A Prepaid Micropayment System for Digital Services and Content

Version: 3.0, draft
Last updated: 2026-10-05
Author: Roberto Bourgonjen
Copyright: © 2026 Roberto Bourgonjen. All rights reserved.
Project: Bitcash / BIT
Companion documents: Bitcash Ledger Specification, which carries the technical detail this whitepaper deliberately leaves out, and Catalog Statements, which describes the statements system on which the royalties of section 6.5 and the statements of section 6.9 are computed and issued, and the EUR matters outside BIT that it also covers.

Status. This document describes the design of Bitcash. Sections 3 to 14 describe that design by role, without naming who holds each role. Bitcash is currently run by its founder, Roberto Bourgonjen, as a private project for his own archive, and no BIT is sold. Section 15 records who holds each role today, which elements are active, and what is planned next. Nothing in this document is a legal opinion, a regulatory approval, a financial promotion, or an offer of an investment product.

1. The problem

Making digital services and content available to the public creates a set of problems that conventional payment and funding models do not solve cleanly. Bitcash exists to solve them together.

Payments smaller than a cent. Streaming one video chunk, serving one image tile, storing one file for one month, or answering one API call each costs a fraction of a cent to deliver. Card networks and payment processors charge a fixed fee per transaction that is larger than that, so services either bundle consumption into subscriptions or give it away and pay for it some other way. A payment unit that can be charged in fractions of a cent, thousands of times an hour, at negligible marginal cost, has to live in software.

Funding infrastructure without compromising users. The conventional ways of paying for that infrastructure are advertising, data monetisation and subscriptions. Advertising requires surveillance. Data monetisation turns users into the product. Subscriptions create access barriers and fatigue, and charge for what is not used. Pay-per-use micropayments replace all three: users pay only for what they consume, in amounts small enough to be affordable, without surrendering personal data.

Protecting content against harvesting. Content published on open platforms is exposed to mass scraping, unauthorised redistribution and extraction into training datasets. Creators who make their work accessible have no practical defence against harvesting at scale. When every access requires a payment there is no free bulk endpoint to scrape, harvesting becomes economically prohibitive, and every request is individually accounted for.

Creators must be paid in money. A payment unit that can only be spent inside the system is fine for a viewer, and useless for the musician, photographer or writer whose work the viewer paid for. Their costs are in money. A system that cannot turn what a work earned into money starves the people who supply what it exists to deliver.

One party must answer for the unit. A payment unit that passes between independent legal entities, one issuing it, another accepting it, a third settling it, creates a legal relationship at every step and makes each of those entities answerable for what the others do. One participant that accepts the unit for the wrong thing, fails its obligations or falls out with its regulator changes the character of the instrument for all of them, and can leave the others liable. A prepaid credit is at its simplest, and safest for the people who hold it, when the party that issues it is the party that honours it and the party that pays the creators.

Users should not have to become cryptocurrency users. Bearer wallets, irreversible transfers and per-request accounting are good properties for a micropayment unit. Price volatility, exchange accounts, seed phrases and on-chain fees are not properties a viewer should need to understand in order to watch a film. The unit therefore lives on an internal ledger built for micropayments, not on a blockchain, and it is not traded anywhere.

Continuity. Users and integrators need assurance that the services they depend on will not disappear because the funding model was unsustainable. A model that relies on donations, grants or one benefactor is fragile. Revenue that scales with usage is not.

In summary, the system needs a unit of account that can be charged in fractions of a cent, is sold for money by one party, is honoured by that same party wherever it delivers its services, pays creators in money for what their work earned, can be held without identification, and is at every moment the obligation of one party only.

2. The solution in one page

Bitcash is the prepaid micropayment system of Catalog, an integrated suite of applications for creatives and other producers of intellectual property: identity (Catalog.ID), payments (Bitcash), mail, chat, a provenance and claims registry (CPR), metadata management, digital rights management, and file storage and delivery.

• BIT is a prepaid service credit recorded on an internal ledger. Every service in Catalog is priced in BIT by a fee schedule that changes only slowly, so a BIT is a claim on a known quantity of capacity.
• One operator. A single party, the Operator, issues BIT, sells it at a published list price, hosts the ledger, runs the Catalog infrastructure, accepts BIT for the services and the content it delivers, and pays the authors of that content their royalties. BIT begins and ends with the Operator: nobody else issues it, nobody else accepts it in payment, and nobody redeems it for money.
• Publishers publish paid content through the Operator, which sells access to it under licence and pays them royalties in EUR. A Publisher receives no BIT as payment for its works; the BIT it holds it bought or was given.
• End Users buy BIT from the Operator and spend it on its services and on the content it carries. BIT is never turned back into money.
• Wallets are bearer codes. Seven wallet kinds cover spending, gifting, trials, receiving, delegated spending, conditional release and invoiced accounts. The ledger carries BIT only: what the Operator owes its Publishers is kept in EUR in its own books, computed from the ledger's metering of every asset.
• Every ledger row is signed by the ledger host, mirrored by the wallet holder and replicated to independent parties, and the Operator publishes signed supply figures.

The rest of this document describes each of these in turn.

3. Participants

The Operator is the only party that creates BIT, the only party that sells BIT for money, and the only party that accepts BIT in payment. Nobody receives money for BIT: Publishers and rights holders receive royalties in EUR for the works the Operator sold access to, and End Users neither sell nor redeem BIT. BIT that holders pass among themselves, as a transfer, a gift or a tip, stays BIT until it is spent with the Operator.

Section 14 sets out the reasoning behind a single party, and section 15 records who holds the role today.

4. What BIT is

4.1 Definition

BIT is a software-defined prepaid service credit recorded on the Bitcash ledger, an internal ledger operated by the Operator. It is the unit of account for every service in Catalog. It exists because conventional payment systems cannot economically process payments of fractions of a cent: on the Bitcash ledger a payment is a ledger entry with negligible marginal cost.

BIT is:

• a unit of account within Catalog, in which every metered service is priced;
• a unit of capacity: the fee schedule (section 10) defines what one BIT buys of storage, delivery and every other core service, and that definition changes only slowly;
• a prepaid stored-value credit, spendable on the services the Operator delivers and the content it carries;
• a micropayment unit, divisible to eight decimal places;
• subject to expiration when left idle (section 8);
• recorded on an internal ledger, not on a public blockchain;
• an obligation of one party, the Operator, to deliver services;
• not redeemable for money, by anyone (section 6.4).

4.2 What BIT is not

BIT is not legal tender, not a general-purpose money substitute, not a deposit, and not an investment. It is not marketed as appreciating in value, yielding returns, or generating profit. It has no guaranteed value in any currency for the person holding it. It is not a blockchain token, it has no representation on any public ledger (section 12), and it is not listed or traded on any exchange.

4.3 The list price

The Operator publishes a list price, the EUR price at which it sells BIT to anyone, without limit, minting on demand (section 6.1). The list price is the price of a purchase. It is not a rate at which anyone buys BIT back: nobody does (section 6.4). An increase of the list price takes effect no sooner than thirty days after it is announced, so that buyers can pre-purchase at the old price.

What a BIT costs is set by the list price, and what a BIT buys by the fee schedule (section 10). The two are governed together (section 14.4), because the Operator's EUR income per unit of service is the one multiplied by the other.

4.4 The reference rate

The Operator also publishes a reference rate, the EUR value of one BIT used wherever a monetary value has to be attached to a quantity of BIT for tax, accounting or reporting. For VAT it is the monetary value of BIT wherever the Operator delivers a service against BIT and cannot know what the payer paid for it (section 13.2), and that value includes the VAT the Operator owes. It is derived from the list price. It is published per day with its effective date, and its history stays published, so that what is spent can be valued at the rate of the day it was settled. The reference rate is information, not a promise. Nobody undertakes to buy or sell BIT at the reference rate.

5. Wallets

5.1 Wallet codes

BIT is held in a Bitcash Wallet, identified by a bearer-style wallet code:

CASH-XXXX-XXXX-XXXX-XXXX-XXXX-XXCC

The code is 34 characters: a four-character type prefix, 22 random characters drawn from a 55-character alphabet that excludes visually confusable letters and digits, and a two-character checksum. The 22 random characters carry about 127 bits of entropy. The checksum lets client software detect transcription errors offline, and it also encodes the code's type, so that a given code is valid for exactly one wallet kind and the kind can be recovered from the 24-character compact form without consulting the ledger. Machine interfaces carry only the compact form; the type prefix is for people.

Possession of a wallet code is authority to spend the associated balance. Wallet codes are bearer instruments: like cash, a lost or stolen code may mean lost BIT. Holders are responsible for securing their codes, and the wallet software described in section 5.12 exists to make that easy.

A wallet code carries no information about who holds the wallet or where it was created. The ledger does record, on the wallet itself and never in the code, the country of the wallet at its creation: the billing country of the purchase that created it, the member's country where Catalog.ID created it, and otherwise the country of the creating client's network address. It is set once, is never rewritten, and exists for the tax rules of section 13.2.

A spending wallet's code has a companion, the view code, derived from the wallet code by a one-way function and carrying the prefix VIEW. The view code reads the wallet's balance and history and can do nothing else. From the view code the ledger derives the wallet's reference, the public identifier under which the wallet appears in other wallets' rows and in the ledger's records. Wallet code, view code and reference form a chain that can be walked in one direction only: whoever holds the code can compute the view code, whoever holds the view code can compute the reference, and nobody can go back.

5.2 The seven wallet kinds

All seven share the same layout and the same entropy, and so does the view code of section 5.1, an eighth kind that is not a wallet; one further ordinal is reserved and never issued. Because the type is part of the checksum, the kinds live in disjoint namespaces: a code of one kind cannot be re-presented as a code of another.

5.3 Spending wallets (CASH)

A spending wallet holds BIT, pays for services, transfers BIT to receive addresses, and creates the other instruments. It may publish receive addresses and issue authorised-spend tokens, up to 128 of those in total. Its balance expires after the term set by its credit policy (section 8) if the wallet is left idle.

Every wallet of the Operator is a spending wallet with a role recorded on the ledger: the wallets it issues from, the wallet that collects the fees, and the wallet that receives what is paid for services and content, which keeps the usage record (section 5.9). The role changes what the ledger lets the wallet do and what counters it keeps (section 9). It changes nothing about the code. A Publisher's wallet, where it has one, is an ordinary spending wallet that holds BIT for the services the Publisher uses; its royalties are kept by the Operator in EUR (section 6.5), never in a wallet.

5.4 Gift vouchers (GIFT)

A gift voucher is a single-use bearer instrument for sending BIT to a recipient without either party revealing a spending code. The sender creates the voucher by moving BIT from their wallet into a fresh voucher wallet and hands over the voucher code, on a card, in a QR, or in a message. The recipient redeems it by draining the full balance into their own wallet, which may be created at that moment.

A gift voucher receives exactly one credit, at creation, and is drained exactly once, in full. It expires one year after creation, returning any unclaimed balance to the sender. Because the sender holds the code, the sender can reclaim the voucher at any time before it is redeemed. On redemption the recipient's wallet is credited as if the sender had transferred directly; the voucher is transparent in the return chain (section 8). A voucher funded with BIT that has not yet cleared (section 6.6) passes it on uncleared: the recipient can spend it once it clears, and until then it can be taken back if the purchase it came from is refunded or lost in a dispute.

Any wallet with a balance may create gift vouchers. Gift vouchers are not sales discounts: they move BIT that is already in circulation.

5.5 Demo wallets (DEMO)

A demo wallet is an allowance, prefunded with cleared BIT (section 6.6), that can be spent at exactly one site, chosen by the issuer at creation, and nowhere else. It cannot be drained into another wallet; BIT leaves it only through consumption at the bound site or, at expiry, by returning to the issuer. It expires at a fixed moment between one day and one year after creation, regardless of activity. It can be topped up only through a receive address published on it, with cleared BIT, and a top-up never extends the expiry or changes who the unspent balance returns to.

Demo wallets are what the Operator or a Publisher hands to a prospective customer to try a service, what a conference organiser hands to attendees for the duration of the event, and what a user hands to a friend to share access to something specific. Any wallet with a balance may create them. An account wallet may create them too, so that an institution can give its members an allowance at a site; what they spend is the account's consumption (section 5.10).

5.6 Receive addresses (FUND)

A receive address is a publishable identifier that other wallets can transfer BIT into. Possession of a receive address grants nothing: not spending, not balance queries, not any view of the wallet behind it. It is safe to print on a card, put on a web page or encode in a QR. That holds toward the public; the ledger host, and the parties that keep verified copies of the ledger (section 9.2), necessarily know which wallet an address belongs to, so a holder who wants two streams of payments to stay unconnected keeps a separate wallet for each published address. A wallet's first receive address is free; each further one costs a flat fee. Spending wallets and demo wallets may publish receive addresses; an author may publish one on the pages that carry its work, for voluntary tips (section 6.5).

A receive address can exist unbound: a valid code that currently resolves to no wallet. A holder may disassociate an address from their wallet, hand the code to someone else, and that person binds it to their own wallet by presenting it together with their wallet code. An unbound address is not a delivery target; a transfer to it fails, and a payment already on its way to an address that is unbound when it arrives is returned to the payer, without its fees.

5.7 Authorised-spend tokens (AUTH)

An authorised-spend token lets a wallet holder authorise someone else to debit their wallet within limits, without handing over the wallet code. It is, in practice, a credit card the holder issues on their own prefunded balance: the holder picks the sites it works at, the service types it may pay for, a daily and a monthly cap, an optional fixed expiry between one day and ten years, and, optionally, a single payee to which every debit must go. The holder can revoke the token at any time. A token holds no balance and is not a destination; it is purely an authorisation.

A token bound to a payee can only ever reach that payee, however widely it leaks, and a token without one pays only at the sites and for the service types the holder chose. This is the form in which a Catalog.ID member's account pays for the services it uses: a token on the member's wallet, with caps the member sets. A token bound to a site's content pays for that content and nothing else. An organisation that wants to be invoiced for what its people and systems consume holds an account wallet instead (section 5.10) and issues its tokens from that.

Only spending wallets issue tokens. A wallet's first token is free, and so is one token that pays only for content at Catalog sites; each further one costs a flat fee. Tokens and receive addresses share the 128-extension cap; the content token stands outside it.

5.8 Locks (LOCK)

A lock is a wallet that holds a balance for a recipient who has not yet claimed it, and releases it only against a signature from a private key the recipient holds. The ledger stores the recipient's public key; it never sees a code that could be used to claim the balance. This is what makes a lock different from a gift voucher: a gift voucher's code is a spending secret that passes through the ledger when it is redeemed, while a lock's release credential never does.

A lock is created with:

• one to four conditions, each an Ed25519 public key with an optional expiry of its own; any live condition may release the lock;
• a fixed expiry between one day and ten years after creation, five years by default, not extended by activity;
• a return wallet, the funder, to which the balance goes if the lock expires unreleased.

A lock that a holder funds is funded with BIT that has cleared (section 6.6). A release names its target inside the signed bytes: a fresh spending wallet, an existing receive address, or a new lock with new conditions. The release drains the lock in full, so one signature spends once and there is nothing left for a second one. A release repeated with the same target is answered as already done, so a client that crashed between the release and its own bookkeeping can safely retry. A lock accepts no second credit, cannot issue tokens, and does not publish receive addresses. Anyone who holds a lock's code can read its state: the code is an identifier derived from the recipient's public key, not a credential.

Locks are how BIT is delivered to someone who does not yet have a wallet and whose claim must survive an untrusted channel. The Catalog.ID registration flow uses them: a registration may carry a quantity of BIT, held in a lock whose condition is a key the new member's device generates, and released into the member's first wallet when the registration completes. The Operator also uses locks to deliver compensation and gifts. Where a lock was created by a sale and that sale is refunded, or lost in a dispute, while the lock is unreleased, the lock is drained back to the Operator whatever the payment method, because nobody has received anything yet: in full, or in proportion when only part of the BIT bought is refunded; a refund of the rest of the purchase, such as a registration fee, leaves it untouched. Once released, what its recipient received is treated like any other BIT bought with a reversible payment: it can be taken back only while it has not yet cleared (section 6.6). A funder has no other way to reclaim a lock: it releases to its recipient or returns at expiry.

5.9 Assets and attribution

Every priced unit a site serves belongs to exactly one asset: a work with an AssetID and an entry in the Catalog Provenance Registry that names its authors, and, for a paid work, one tier and an inclusion policy (section 10.2) that are published beside them. The signed URL of a unit carries its AssetID, and the ledger meters by it: the Operator's receiving wallet keeps, for every day, the units, requests and bytes settled to it per site, asset, tax category and customer country. That usage record is the basis of every royalty (section 6.5) and of the statistics a Publisher wants about its works. It carries no wallet, token or address, and nothing finer than the day, so it says how much each asset earned and nothing about who paid. The ledger serves it signed, so that the Operator can hand every author the ledger's own figures for the author's assets, and the Operator keeps the record for as long as its statements require.

One unit carries one attribution. A site's renderer may combine several works into one served unit, a sheet of thumbnails for instance, only when their assets have the same authors and the same split; it learns which assets may be combined from the Operator's publication service, which knows the splits without disclosing them. A combined unit carries a sheet identifier that the site's build maps to the assets it contains, so statistics per asset survive the combination. Works by different authors are served as separate units, however small, and each is credited to its own authors; a page of fifty thumbnails from fifty authors is fifty metered units. A Publisher who finds that too dear marks thumbnails free, and a free unit is never metered and credits nobody. Units that belong to no attributed asset, a site's own pages, are the site owner's.

The ledger holds no EUR and knows no author. Royalties, splits and payments are kept in the Operator's books, described in section 6.5 and in the Catalog Statements whitepaper.

5.10 Account wallets (ACCT)

An account wallet is a spending wallet held by a customer that the Operator has identified and contracted, typically an institution. It exists so that a customer can consume on account and receive an ordinary invoice for it, with VAT, instead of buying BIT. The customer holds the code and mirrors its rows like any holder, and issues authorised-spend tokens to its departments and systems, each with its own caps. It publishes no receive addresses, creates no gift vouchers or locks, and makes no transfers other than into demo wallets it created. It may create demo wallets (section 5.5), so that an institution can hand its members or visitors a bounded allowance for a site, its own or a Publisher's, and pay for it on account: what those demo wallets spend is the account's consumption, invoiced like the rest, and what they leave unspent returns to the account. Only the Operator creates it.

A spending wallet cannot serve this purpose, for two reasons that follow from what BIT is. Its balance is a bearer voucher: a sale into it carries no VAT, its buyer is not identified, and it can be passed on, so what is consumed from it cannot be invoiced to anyone without counting the same consumption twice, once as an invoiced service and once as a voucher spent. And its balance cannot go below zero, so no credit can be extended through it, and credit placed in it anyway would leave as bearer value that never comes back.

An account wallet turns those properties around. It is non-transferable and credited only by the Operator, so credit the Operator advances can only ever come back to the Operator as payment for its own services, which bounds its exposure to the credit limit it sets, and the Operator recognises the account's payments by the wallet kind on the row and leaves them out of the voucher spending it taxes at the reference rate. And it is held by an identified customer under an account agreement, which is what an invoice needs.

The Operator funds it in one of two ways, or both. On credit: the balance never goes below zero, but when a payment would take it short, the ledger advances the shortfall as part of that payment and counts it as advanced. What has been advanced and not yet settled is the account's debt, capped by a credit limit the Operator sets for that account. Once a month the Operator invoices the advances at the rate in the account agreement, and payment clears the debt. By deposit: the customer pays first, the Operator credits the balance and invoices the deposit, and the credit limit may be zero. An advance and a deposit are fee-free, like a sale.

The account wallet's return wallet is the Operator and its term is the term of the account agreement; a balance the customer hands back or leaves at the end is settled in EUR under that agreement. For tax an account wallet is an account with the Operator, not a voucher (section 13.2).

5.11 Minimum deposit

Every wallet that holds a balance is created with an initial credit of at least 1000 BIT. The ledger does not register the wallet until that threshold is met. Subsequent credits have no minimum. The minimum prevents address spam. The Operator may set a higher minimum for purchases to cover payment-provider costs.

5.12 Wallet software

The Bitcash Wallet Manager is a desktop application for Windows, macOS and Linux that creates, imports and manages wallets and the instruments attached to them. It never stores a wallet code in plaintext: codes are encrypted under a key held in the operating system's secret store and decrypted in memory only for the duration of a spending operation. Routine operations, balances, history, expiry and the tree of child wallets use the view code (section 5.1) and leave the secret store locked. Beside the balance the manager shows what is on its way to the wallet but not yet credited: payments awaiting settlement, BIT that has not yet cleared with the dates it clears, and BIT held back by a dispute (section 6.6). The manager mirrors every signed ledger row it sees into local storage, together with the lines of every settled batch (section 9). Before the first unit of a premium or exclusive work is charged, the manager and the browser wallet show its tier and price and ask the viewer to confirm (section 10.2).

The browser wallet embedded in Catalog sites lets a visitor hold a wallet, pay for content, open a session for chunked content (section 10.2), publish a receive address for in-person funding, and issue tokens, from a browser, with the same signed-row mirror.

A wallet may opt into privacy mode, in which the ledger records every payment's amount and coarse category but strips the specific resource paid for before the row is written. The signed chain is unaffected; only the content path is absent.

6. How BIT enters and leaves circulation

6.1 Issuance by the Operator

The Operator is the only party that creates BIT. BIT enters circulation from the Operator's wallets in two ways, each reported as its own line in the supply figures (section 9.3):

• Sale. The Operator sells BIT for EUR at the list price (section 4.3), without limit, minting on demand. Sales are self-limiting because every sale needs a buyer, and every sale brings in the money with which the Operator builds the capacity that the BIT will consume (section 10.3).
• Gifts within a published budget. BIT the Operator distributes without payment: invitations, promotion, compensation, testing. Gifts are bounded by an annual budget that the Operator announces before the year starts, as a percentage of the supply in circulation, and reports against afterwards. Gifts are the only issuance that is not matched by money received, which is why they are the only category with a limit.

There is no fixed supply cap. What substitutes for one is the issuance policy above, the capacity stewardship of section 10.3, and public, signed supply figures (section 9). A BIT obliges the Operator to deliver the service that the fee schedule says it buys; it obliges nobody to pay money. The Operator's income is what it receives for the BIT it sells, and from that income it pays for the infrastructure, for the royalties of section 6.5 and for its own operation.

Before the Operator sells BIT, every BIT in circulation was given. Section 15 records how BIT is issued in the phases that precede sales.

6.2 Sales

The Operator sells BIT through its own webshop and through the "buy BIT" checkout on the sites it carries, a Publisher's site included. Wherever BIT is sold, the Operator is the seller of record, and a Publisher never sells BIT. A sale of BIT carries no VAT and its price includes none (section 13.2). The Operator may also sell BIT to an author against the royalty balance it holds for that author (section 6.5): a sale paid in the Operator's own books, whose BIT clears at once.

Sales of BIT are fee-free: the buyer receives the full quantity purchased.

6.3 Spending

BIT is spent on services priced in BIT: content access, streaming, storage, delivery, metered APIs, registrations, and the other services in the Catalog service catalog. Every payment carries the tax category of what it buys (section 10.2). A payment settles on the ledger at the moment of transfer and is final for the payer; it is credited to the Operator's receiving wallet in periodic settlements, at most an hour apart (section 9.1). BIT that has settled to the Operator has done its work and leaves circulation.

The Operator is the seller of everything that BIT buys, its own services and its Publishers' content alike. It owes VAT on what is spent with it, valued at the reference rate of the day of the settlement, at the rate of the payment's category in the payer's country (section 13.2), and where the payment was for a Publisher's content it owes the Publisher a royalty in EUR on what remains (section 6.5). The BIT price of a service therefore includes the VAT the Operator owes. A payment from an account wallet (section 5.10) is instead invoiced, and the Operator does not tax it as a voucher spent. The ledger does not track whether the service was then delivered. Where the Operator fails to deliver, the remedy is a credit in its own systems or, where the law requires, a refund in EUR through the original payment provider, never a reversal on the ledger.

Every payment carries the scheme fee (section 7).

6.4 No redemption

Nobody can redeem BIT for money: not an End User and not a Publisher, not with the Operator and not with anyone else. BIT has one exit, a service delivered by the Operator. This is deliberate. It is what keeps BIT a prepaid service credit rather than a store of value, and it is why BIT never has to pass from one party to another as a claim to money. The refund of a purchase is a different matter and follows section 6.6.

6.5 Royalties

Publishing a work through the Operator grants the Operator a licence to sell access to it: non-exclusive, ended by the Publisher by unpublishing, and not transferable. A work may be published on several sites, its author's own and others' that invite it or that include it under its open inclusion policy (section 10.2); the royalties of every unit go to the work's authors, whatever site served it. The Operator sells the access for BIT and owes a royalty in EUR for every unit it is paid for: its net receipt for the unit, after the VAT it owes on it, less the platform share of section 7.2 and, where the unit was served through a site whose owner is not among the work's authors, less the site share of section 7.2, which the Operator owes the site's owner. The net receipt follows from a net rate table the Operator publishes with its terms, in EUR per BIT for each tax category and customer country, derived from the reference rate and the VAT rates that apply (section 13.2). The Operator computes the royalty in its own books from the ledger's signed usage record (section 5.9), per asset and per settlement day; the ledger computes no VAT and holds no EUR. A royalty is final once computed: only BIT that has cleared settles to the Operator (section 6.6), and cleared BIT is never taken back. A royalty does not depend on how the BIT that paid for a unit entered circulation: a unit paid for with BIT the Operator gave away earns its authors the same as a unit paid for with BIT it sold, which is one more reason gifts are budgeted (section 6.1).

The royalty of an asset belongs to its authors, the persons the Catalog Provenance Registry attributes on it. Who they are is public in the registry. How they share is private: a split they register with the Operator, readable by the listed authors and the Operator alone, equal shares unless they register otherwise, and a registered split takes effect only once every author whose share it lowers has confirmed it; the registry may carry a fingerprint of the confirmed split, so that a later dispute can be decided without revealing it. A Publisher who publishes a work warrants that it may license it on behalf of every author attributed on it, sets its tier and its inclusion policy under that warranty, and the Operator's duty to pay each author directly is a term of the Publisher's agreement made for the authors' benefit. Each author is thereby a co-licensor for its share.

The Operator credits each author's share to an EUR balance it keeps for that author, keyed by the author's Catalog.ID, so an author needs no wallet and publishes nothing to be paid. Before it pays an author for the first time the Operator enrols it: a Catalog.ID sign-in, its acceptance of the Operator's Publisher terms, and a supplier profile, its VAT status and the class of what it supplies, which the author keeps on its Catalog.ID. An author's share accrues from the first payment and waits in the Operator's books until the author enrols; a share unclaimed after the term the Rulebook sets lapses. The Operator pays the balance in EUR at the cadence and above the minimum its terms set, against the self-billed statement it issues on the author's behalf (section 6.9), or the author uses the balance to buy BIT from the Operator, an ordinary sale paid from the balance (section 6.2). An author can recompute every royalty from the ledger's signed figures for its assets, the Operator's published net rates, the platform share and its own split. A Publisher never receives BIT as payment for its works, and never money for BIT.

A viewer may nonetheless tip an author in BIT. A tip is a voluntary transfer to a receive address the page publishes (section 5.6), made by the viewer's own wallet software: it buys nothing, access to a work never depends on it, and the work is the same with or without it. It is a transfer like any other, carries the scheme fee, lands in the author's spending wallet as spendable BIT, and is never convertible to money, since nobody redeems BIT. Nothing on the ledger splits BIT among authors, so a page that attributes several authors publishes one address for each author it wants tippable. What an author receives in tips is its own affair for tax, valued at the reference rate; its wallet statement gives it the figures.

6.6 Clearing and refunds

BIT bought with a payment method that the buyer can reverse afterwards, a card, is uncleared until the period in which that payment can be reversed has passed; the Rulebook sets that period for each method, and BIT bought by bank transfer clears on arrival. Uncleared BIT may be spent: paid for a service, it settles to the Operator when it clears, and until then the payment is announced; transferred or gifted, its recipient holds it until it clears. A site may decline uncleared BIT for its standard and premium units, exclusive units are never served against it (section 10.2), and the instruments that need cleared BIT say so in section 5.

The refund of a purchase of BIT is governed by the Operator's terms and applicable law, and is made in EUR through the original payment provider. A refund also takes back the BIT bought, as far as it has not cleared. Where the purchase is refunded, or a dispute over it is lost, the uncleared BIT is taken back: from the buyer's wallet, from payments that have not yet settled, and from anyone the buyer passed it to directly. BIT that has cleared is never taken back, except from a lock the purchase filled that nobody has released yet (section 5.8), and what cannot be recovered is the Operator's loss. While a card payment is disputed, the BIT bought with it does not clear: the buyer may still spend it, but its recipients receive it only once the dispute is won, or after at most 180 days.

6.7 The circulation loop

Money and BIT each make one journey, in opposite directions:

1. A viewer buys BIT from the Operator. EUR goes to the Operator; BIT goes to the viewer.
2. The viewer spends BIT on a work or on a service. The BIT returns to the Operator and leaves circulation.
3. The Operator pays the work's authors their royalty. EUR goes from the Operator to the authors; no BIT moves.

BIT is created when it is sold or given, and it ends when it is spent. Between those two moments it may pass from holder to holder, as a transfer, a gift or a tip, without anyone but the Operator ever owing anything on it. Money enters once, at the sale, and leaves the Operator as royalties and as the cost of the infrastructure that delivered the service. There is no settlement between parties, because there is one party.

6.8 Recovered and expired BIT

BIT that expires unspent returns to the wallet that last sold or sent it (section 8). It bears no VAT: what returns is credit that was never spent on a service. What reaches the Operator's wallets along that chain is recovered: it leaves circulation and reduces the Operator's outstanding commitments. The Operator reports recovered BIT separately in the supply figures.

6.9 Statements

The ledger moves BIT; money moves in the Operator's books, and every EUR obligation that arises from BIT is documented by a statement the Operator issues from the ledger's figures. The royalties of a Publisher or an author are documented by a self-billed statement the Operator issues on the supplier's behalf from its own books (section 6.5): the royalties of the period, computed per asset and settlement day from the ledger's signed usage record, by site and tax category, plus the VAT the supplier's profile requires. An account wallet (section 5.10) is invoiced monthly for the BIT advanced to it and at payment for a deposit, by tax category. The Operator's sales to consumers are invoiced to nobody; the Operator accounts for them on its VAT returns from the same figures, by settlement day, category and the paying wallet's country, at the reference rate of the settlement day.

Before it pays a supplier for the first time, the Operator records the supplier's profile: its identity through Catalog.ID; its VAT status, registered in the Operator's country, registered elsewhere in the EU so that the statement is reverse-charged, established outside the EU, exempt or under a small-business scheme, or a private person; and the class of what it supplies, the licence of its works. The supplier's terms are the Operator's own: they contain its agreement to self-billing and the conditions of the Rulebook that apply to Publishers (section 13.1). A supplier that uses its balance to buy BIT is documented on the same statement; the sale is its payment.

The ledger serves the figures behind every such statement. Any wallet can pull its own statement for a period from its signed rows: what was credited to it, by counterparty and kind, and what it paid, by payee and category, each day valued at the reference rate of that day. The Operator's own statement adds the units settled to it per site, asset, tax category and country for every day of the period, signed by the ledger, which is the basis of every royalty it owes, and the consumption of each account wallet. Because the Operator's statements are computed from these figures and nothing else, an author can recompute the statement it receives from the ledger's signed figures for its assets, and an auditor can rebuild any statement from the signed rows.

Work done for Catalog, translations, annotations, development, is paid in EUR, outside the ledger: rates are agreed in contracts, tasks are recorded in the Operator's task system, workers are paid and prepaid from the Operator's books, and a customer that commissions work is invoiced in EUR. No BIT is paid for labour and no worker accepts BIT, which keeps BIT to what it is for: the services and the access to content that the Operator delivers (section 13.1). A Publisher or an account holder that wants work done commissions it through the Operator; BIT it hands a helper directly is a transfer, not earnings. The task system, the contracts, prepayments and the statements that document work are described in the Catalog Statements whitepaper.

7. Fees

Fees apply where the ledger does work: moving value between holders, and recording payments. Sales of BIT for money are fee-free; royalties are paid in EUR and never touch the ledger's fees.

7.1 Scheme fee: 0.1%

A fee of 0.1% applies to every transfer of BIT between holders and to every service or content payment. The ledger credits it to the Operator's fee wallet in periodic settlements, once the BIT it was paid with has cleared, so that the maintenance of the ledger is funded by its use, automatically, in the way transaction fees fund the operators of a public ledger. Fee BIT leaves circulation when it is collected. The fee is payment in BIT for the ledger's service, and the Operator accounts for it under its own tax rules (section 13.2).

The fee is kept apart from the price of what is bought. The price of a content payment enters the royalty computation of section 6.5, from which the work's authors receive their share; the fee does not. The upkeep of the ledger is thereby paid by every row that is written, by a transfer between holders that buys nothing from the Operator as much as by a payment, and never out of an author's share. The fee rate is set in the Rulebook and changes only with notice.

Minimum fee. The scheme fee on any single payment or transfer is never less than a minimum fee, set in the Rulebook and initially 0.02 BIT. Content and services priced in small units are paid in sessions (section 10.2): each unit metered in a session carries a per-unit minimum, set in the Rulebook and initially 0.01 BIT, and the session is settled as one payment, whose fee is never less than the payment minimum. Every payment creates signed ledger rows, and every metered unit a ledger write, that cost the ledger more to record and keep than a proportional fee on a tiny amount would ever recover, and a percentage fee that rounds down to nothing on small amounts would also make the fee avoidable by pricing in dust. The scheme fee is therefore charged to the payer on top of the amount, so that a payment of any size can be processed: a payment below the minimum fee simply costs its payer the amount plus the minimum fee. The minimums are the price of a ledger row and of a metered unit, and whoever causes them pays for them.

7.2 Platform share and site share

A payment for a Publisher's content, including spending from a demo wallet at a Publisher's site, settles to the Operator. What the Operator owes the Publisher is settled in EUR (section 6.5): from its net receipt for the payment, the EUR value at the reference rate of the settlement day less the VAT it owes on it, the Operator keeps a platform share of 30%, set in the Rulebook, and the rest is the Publisher's royalty. The share pays for the delivery of the content and is the Operator's margin as its seller; storage remains a service the Publisher buys like any customer. A payment for the Operator's own service carries no share: the Operator is seller and supplier at once.

A site may carry works whose authors are not its owner: a magazine, a festival, a gallery (section 10.2). Where a unit is served through a site whose owner is not among the work's authors, a site share of 20% of the net receipt, set in the Rulebook like the platform share, goes to the site's owner, and the work's authors receive the remaining 50%; served through a site owned by one of its authors, a work earns its authors the full 70%. The site share is the same for every site and is not negotiable: an author who accepts inclusion in a site accepts it, and a site owner may ask for nothing more. It is a royalty like any other, the owner's consideration for licensing its site, a work in its own right, to the Operator, and it is paid through the owner's royalty balance (section 6.5). The Operator may own sites through its own Catalog.ID and then keeps the site share beside its platform share, on the same terms as any other site owner.

7.3 Flat fees

A small set of flat fees, credited to the Operator like the scheme fee, bounds proliferation of the instruments that cost the ledger storage. Like the scheme fee, they are payment in BIT for the ledger's service:

The fees for a receive address and a token may be paid with BIT that has not yet cleared; settlement on demand is paid with BIT that has cleared (section 6.6).

7.4 Fee matrix

The scheme fee is charged to the payer on top of the amount and appears as its own column on the payer's signed ledger row, so a holder can reconstruct the gross and net of every transaction from signed data. The platform share of section 7.2 is not a fee on the ledger: it is the part of the Operator's EUR receipt that is not owed as royalty.

8. Expiration

8.1 The credit policy

Every wallet that holds a balance carries a return wallet and a term, written together as one pair, and a last-activity timestamp. The wallet expires when it has been idle for the full term, and its remaining balance then goes to the return wallet.

Three rules govern the pair:

• Pair rule. Return wallet and term are written together, at creation and whenever a credit rewrites them, never separately.
• Dominance rule. A credit rewrites the pair only if it is at least three times the wallet's existing balance. Smaller credits add to the balance without displacing the existing return commitment. A large top-up therefore earns the right to name where the balance goes at expiry; a small one does not. Credits that arrive in a settlement of several payments (section 9.1) add to the balance and never rewrite the pair; a sale, a transfer, a gift or a lock release offers its pair as the table below says. Demo wallets, locks and account wallets are exempt: their pair is fixed at creation and never rewritten, which is what stops a third party from capturing another party's unspent or unsettled balance with a late large credit.
• Activity rule. Any transaction the wallet takes part in resets the last-activity timestamp, so an active wallet never expires, and a frozen wallet (section 11) does not expire while it is frozen. Demo wallets, locks and account wallets are exempt: they expire at the fixed moment chosen at creation.

The defaults a credit carries depend on the kind of transaction, not on who the parties are:

The Operator's own wallets do not expire.

8.2 Cascade on expiry

When a wallet expires, its balance goes to its return wallet; if that wallet has itself expired, to that wallet's return wallet, and so on until a live wallet is reached, and ultimately the Operator. The expired wallet is then closed. Unspent value therefore always reaches whichever live wallet is upstream, and BIT returned this way keeps its clearing state (section 6.6).

BIT returned by expiry is not income for the wallet that receives it. It is the unspent remainder of credit that wallet sold or sent.

9. Ledger integrity

9.1 Signed rows

Every row appended to any wallet's ledger is signed at the moment of commit by the ledger host, the Operator, over the row's durable fields: the wallet's reference (section 5.1), its monotonic sequence number, the transaction type, the signed amount, the running balance after the transaction, the timestamp, the fee column, the ledger and the signing key it was signed under, the paying wallet's country and kind, and where applicable the content path, the service type with its tax category, the token through which a debit was routed, the counterparty, which for a content payment is the site, and the batch. The Operator publishes its signing public keys, current and past, at a well-known address, so any holder, counterparty or arbiter can verify a row offline.

Because each row commits to the running balance, a signed row attests to the entire history before it: no earlier row can be rewritten without breaking the arithmetic at every later signed row. Every row is signed, including creation, fee and administrative rows, so there is no gap through which value could be shifted between rows.

A payer's row records each payment it makes. A payee's credit row covers a batch of payments settled together, at most an hour apart, and names the batch; the payee's software keeps the lines of the batch, one per paying wallet or token, whose hash the row commits to, and a payee may have its pending credits settled on demand for a flat fee. A payer's row may likewise cover one session of metered units (section 10.2), stating their count and total and committing to them by a hash. Value on its way from a payer's row to a payee's settlement is recorded in the replicated log of section 9.2, not in either holder's rows.

9.2 Mirror

The wallet manager and the browser wallet replicate every signed row into the holder's local storage and never overwrite a mirrored row. If the ledger later returns a different signature for the same wallet and sequence number, the software surfaces a fork rather than replacing the row. Once a row has been mirrored by any holder, it is outside the ledger host's control. Disputes about historical state reduce to producing the signed row.

Replication. The ledger host also keeps a signed, replicated log of every change to every wallet, from which the ledger can be rebuilt anywhere with nothing but the published public keys. Independent replicas, parties outside the Operator and under contract with it, pull and verify the log continuously, keep the ledger's state, and serve any holder a proof that a row is in the log; copies of the log held outside the Operator are encrypted under a key held in escrow. The log carries no wallet codes. The signed head of the ledger in the supply figures is the head of that log.

9.3 Counters and supply figures

The ledger keeps, on the wallets to which they apply, the counters from which the supply and every entitlement are derived: on the Operator's wallets, BIT issued, recovered, accepted for services and collected in fees, and the usage record of section 5.9; on each account wallet, BIT advanced and settled. The Operator publishes, at least monthly, signed supply figures: total issued, split into sales and gifts; the gift budget for the year and the amount used; the supply in circulation, and the BIT recovered, spent and collected in fees; BIT on its way between payers and payees, and BIT taken back by refunds; the committed capacity of section 10.3; and the number of authors the Operator reports paying; together with a signed head of the ledger. Once anchoring is active, these checkpoints are anchored to a public ledger (section 12), so that the figures cannot be restated later.

What this proves is that the ledger host attested to the exact figures on every row at the moment of commit, and to the total supply at every checkpoint. What it does not catch by itself is a host maintaining two parallel ledgers and showing different ones to different parties. The mirror and the independent replicas make that detectable by comparison, and anchoring makes the checkpoints unrepudiable.

10. The fee schedule and capacity

10.1 The fee schedule

Every service in the Catalog core catalog has one price in BIT, set in the Rulebook: storage per gigabyte-month, delivery and streaming per gigabyte, access to published content in three tiers (section 10.2), metered API calls, registrations, CPR writes, and the other services within the scope of section 11. Every service in the schedule is of the standard tax category, except content access, whose category the Publisher marks (section 10.2). The schedule is what makes a BIT a unit of capacity: it defines what one BIT buys, on any day.

The schedule changes slowly, by design. A change takes effect no sooner than twelve months after it is announced, and the price of a core capacity service may rise by no more than a percentage per year fixed in the Rulebook. An institution that buys BIT today therefore knows the least its BIT will buy over its planning horizon, whatever the list price does in the meantime. Pre-purchasing BIT is pre-purchasing capacity at a known price. An institution has two ways to do that: general BIT in a spending wallet, or an account wallet (section 5.10), on credit or by deposit, invoiced with VAT (section 13.2).

Each schedule carries a version. A metered request is priced under the version current when it is made, and a version the Rulebook has retired is refused after its notice period, so that a stale price cannot be charged indefinitely.

10.2 Content access

Access to a Publisher's content is priced by the schedule like any other service, in three tiers, standard, premium and exclusive, the same on every site. For each tier the schedule states a price per megabyte served, per minute of audio or video played and per page of text, and the Operator's publication software computes the price of every unit from its medium, its size or duration and its asset's tier, and signs it into the unit's URL together with the tier; the ledger charges the price in the URL and records the bytes it served. A Publisher does not price its works. It decides which units are free and which are paid, gives each of its assets one tier, which follows the asset to every site that carries it, and marks each paid unit with a tax category from the short list the Rulebook keeps: standard unless the Publisher marks it otherwise, publication for an electronic publication that a country may tax at a reduced rate. An electronic publication is the electronic counterpart of a book, newspaper or periodical: a text work, a chapter or article of one, an audiobook, and the images that are part of such a page as it is served; a standalone image, video, audio recording or download is not one, and a work that consists wholly or mainly of advertising, video or music never is. The category follows the unit as it is served, so the same photograph is part of a publication inside a magazine's article and standard content as a download. The category travels with the payment (section 6.3) and, through the Operator's VAT, decides the royalty (section 6.5); the tier decides the price.

A site's owner sets which tiers the site admits, one or several. A site that carries the works of many creators, a magazine, a festival, a gallery, includes them under each work's inclusion policy, published with the asset like its tier: open, so that any site may include the work without asking; by invitation, so that the work's author accepts each inclusion; or closed, so that only its authors' own sites carry it. Because the tier is the asset's and the site share of section 7.2 is the same everywhere, an inclusion has nothing left to negotiate, and an open policy is a standing acceptance of both. The Operator records every inclusion, and an author may withdraw its work from any site it did not publish itself, with the effect of unpublishing (section 6.5). A site that admits one tier holds every work it publishes at that level, and a work keeps its tier wherever it appears, so the same work never costs more on one site than on another; its royalties go to the work's authors, less the site share where the site is someone else's, whatever site served it (section 6.5). An asset's tier is public, like its authors, and is shown with the sites that carry it. Wallet software shows the tier and the price and asks the viewer to confirm before the first unit of a premium or exclusive work is charged, and a site marks such works before the viewer opens them. A site's owner also decides whether its standard and its premium units may be paid with BIT that has not yet cleared (section 6.6); exclusive units never are, a rule that protects the work whatever site carries it, so a viewer who wants exclusive content pays with BIT that has cleared, bought by bank transfer or aged past its card's clearing period.

Every paid unit, a tile, a chunk, a page, is metered by the ledger as it is served, and its viewer pays the per-unit minimum fee of section 7.1 on top of its price. The units a viewer consumes at one site under one tax category form a session, settled in one signed ledger row that states their count and total and commits to the list of units by a hash; a session is closed when it has been idle for a short time, reaches its spending cap, its age or its size, is closed by the viewer, or meets a new category. Content URLs carry the unit's AssetID, its tier, its price and the site's content revision, and a revision the Publisher has retired is refused, so that a cached page cannot keep charging a price or a classification that has since changed. One unit carries one attribution: works by different authors are served as separate units, and a combined unit contains only works with the same authors and the same split (section 5.9). Until the Rulebook adopts the schedule, a published price list states the three tiers.

10.3 Committed capacity and stewardship

Every BIT in circulation is a claim on capacity that the Operator will have to deliver. The supply in circulation multiplied by the schedule is the committed capacity, and the Operator publishes it with the supply figures (section 9.3), per service category, as the upper bound on what the outstanding BIT could consume.

The party that sells a BIT is the party that has to deliver what it buys, so the money of every sale arrives where the capacity has to be built. Two mechanisms keep the two in step:

• The Operator reviews committed against available capacity every quarter.
• When committed capacity approaches available capacity, the Operator raises the list price or pauses sales until capacity has caught up.

An Operator that sells BIT has every interest in that BIT being usable: BIT that cannot be spent finds no buyers.

11. One ledger, one scope

There is one ledger, one kind of BIT, and one party that accepts it. BIT bought at one site is spent at any other without anything having to be settled between anyone: the buyer paid the Operator, and the Operator delivers. A gigabyte-month, a delivered gigabyte or a registration costs the same number of BIT at every site, because there is one fee schedule.

Two constraints hold at every site, so that BIT stays one instrument:

• Scope. BIT is accepted only for services within the Catalog service catalog delivered through a Catalog installation: digital content access, including electronic publications, cloud services, storage, delivery, metered APIs, registrations and related digital services, whatever their VAT treatment. It is accepted for nothing else, because accepting BIT outside that scope would change the character of the instrument for everyone who holds it.
• Carve-out. The Operator may refuse a specific transaction, or freeze a wallet, where acceptance would violate law binding on it, including sanctions and court orders: narrowly, documented, and disclosed. A frozen wallet accepts credits, makes no payments, and does not expire while frozen; a freeze applies at every site.

A site may decline BIT that has not yet cleared for its standard and premium units, and exclusive units never take it (sections 6.6, 10.2). That is a choice about payment risk, and it leaves BIT one kind.

Two things follow for VAT (section 13.2). BIT is bound to no country: it is spent by customers wherever they are. And because the Operator is taxed where its customer is, it uses the country recorded on the paying wallet (section 5.1) as its evidence of where the customer is.

12. Public anchoring (designed, not active)

Not active. Nothing in this section is in operation. It describes a designed extension that may be amended or abandoned following legal and technical review.

The Operator may record the supply checkpoints of section 9.3 on a public ledger, the XRP Ledger being the intended venue, in the way the Catalog Provenance Registry anchors its claims: a transaction from the Operator's account that carries the hash of the signed checkpoint. A checkpoint that has been anchored cannot be restated, by the Operator or by anyone who later controls its keys.

Anchoring puts no BIT on the public ledger. BIT has no representation there or on any other public ledger: there is no token, nothing to trade, and nothing for which a holder would need a blockchain account.

13. Compliance and legal posture

This section is deliberately conservative and factual. It is not a legal opinion and does not assert that any element of the design falls within any particular exemption. Section 13.1 states the posture; section 13.2 sets out the VAT treatment.

13.1 Posture

• BIT is a prepaid service credit. It is sold for money, it can be used only to pay its issuer for services within a defined service catalog, and it is not redeemable for money by anyone. The royalties the Operator pays Publishers are payments for licences, in EUR, outside the instrument.
• The issuer is the only acceptor. The party that issues BIT is the party that accepts it. No other person accepts BIT in payment: a Publisher is a licensor paid in EUR and never accepts BIT as payment (section 6.5), nobody is paid in BIT for labour (section 6.9), and a voluntary tip to an author is a transfer between holders that buys nothing (section 6.5). BIT is therefore never a claim on one party that another party takes in payment.
• One purpose. BIT buys one category of things: access to digital content published through Catalog, and the storage, delivery and related services that carry it. The ledger enforces that boundary through site records and the scope of section 11, not through terms alone. Of the forms of the exclusion for instruments of limited use, Bitcash is built to meet two at once: the form of an instrument that buys services only from its issuer, and the limited-range form, a single functionally connected category of services, whatever the number of Publishers.
• Publishers contract with the Operator alone. They license their works to it, it pays them royalties in EUR, and its terms with them carry the conditions of the Rulebook, among them the scope of section 11, the verified identity and royalty rules of section 6.5, and the rule that a Publisher never sells BIT and never makes access to a work depend on a payment to itself. The supply figures report the number of authors the Operator pays (section 9.3).
• A list price, not a peg. The list price is the price of a purchase from the Operator. It is not a redemption right, and there is none.
• Notifications. Where the volume of BIT sold or accepted in a jurisdiction exceeds a threshold above which that jurisdiction requires a notification for instruments of this kind, the Operator makes it.
• Controls. The Operator maintains purchase limits, fraud and abuse controls, clearing periods for reversible payment methods (section 6.6), a payment-provider account used only for BIT sales, wallet freezing where legally required or contractually permitted, chargeback handling, refund and error-correction procedures with a deadline for refunding a buyer whose purchase could not be completed, and the separation of live and test environments. Logging is proportionate and respects privacy by design. The ledger host and the parties that keep verified copies of the ledger can read every wallet's history by its reference and the consumption of every asset by day, category and country, and know which wallet stands behind a receive address; they never hold a wallet code or a view code, and copies of the ledger held outside the Operator are encrypted (sections 5.6, 9.2).
• Not an investment. Nobody may market BIT as an investment, or promise appreciation, yield or profit. BIT is not traded, and there is no market on which its price could move.

13.2 VAT

BIT is a multi-purpose voucher. At the moment it is sold, neither the rate of VAT nor the place of the eventual supply is known: BIT buys every service in the catalog and every Publisher's content whatever its VAT treatment, is spent by customers in more than one country, and passes freely from holder to holder. A sale of BIT therefore carries no VAT. BIT that expires unspent bears no VAT.

One seller. Every supply against BIT is made by the Operator: its own services, and access to content, which it sells as a principal under a licence from the Publisher. VAT falls due when a service is delivered against BIT and is owed by the Operator, on the BIT settled to it for that service, valued at the reference rate of the day of the settlement, a value that includes the VAT, at the rate of the payment's tax category in the country recorded on the paying wallet.

Consumers and accounts. A payer holding a spending wallet is a consumer. A payer that needs an invoice holds an account wallet (section 5.10), which is an account with the Operator and not a voucher: the Operator invoices it, monthly for advances or at payment for a deposit, with VAT at the rate of each category, and excludes its payments, and those of the demo wallets it funds, from the voucher spending it taxes at the reference rate, recognising them by the payer's kind and funding on the row.

Suppliers. Publishers and the authors the registry attributes on their assets license their works to the Operator, and the owner of a site licenses the site, a work in itself, and receives the site share for the works of others it carries; their consideration is a royalty in EUR, computed by the Operator from its net receipt on the day each payment settles (sections 6.5, 7.2). The Operator records each supplier's profile at enrolment and documents each period's royalties with a self-billed statement plus the VAT the profile requires (section 6.9): none for an author whose country exempts its services or for a supplier under a small-business scheme or below its registration threshold, reverse-charged for a supplier registered elsewhere in the EU, at the supplier's rate otherwise. Whatever VAT a supplier charges, the Operator deducts, so its cost is the net royalty in every case.

The ledger's fees. The scheme fee and the flat fees are payment for the ledger's service, and the Operator accounts for them under its own tax rules.

Fixed for the life of the instrument. The Rulebook fixes this character and keeps the list of tax categories, and the treatment is confirmed with qualified advisers before BIT is first sold.

14. Governance: one Operator

14.1 What the Operator controls

The Operator controls everything Bitcash cannot do without: the ledger and its signing key, the issuance of BIT, the fee schedule, the list price, the Rulebook, and the infrastructure on which BIT is spent. Every micropayment settles on the ledger it hosts, and every BIT is its promise to deliver. That is a concentration, and it is deliberate. The rest of this section explains why, and what stands against it.

14.2 One party, and why

A payment system for digital content can be built as a federation: an issuer, independent operators that accept the unit for the services they deliver and turn it back into money with the issuer, and a body above them all. Bitcash is not built that way, for one reason.

In a federation the unit moves between legal entities: one sells it, another accepts it, a third settles it. Every such movement is a legal relationship of its own, with its own questions of what the unit is in law, who owes tax on it and who answers to which regulator. And every member depends on the conduct of every other. One member that accepts the unit outside its scope, sells it carelessly, fails, or falls out with its regulator can change the character of the instrument for the whole network, and can leave the other members liable for an act they had no part in. A payment model with that property is fragile exactly where it has to be strongest.

With one party the unit never crosses such a boundary:

• A holder has one counterparty. The party that sold the BIT is the party that owes the service.
• An author has one debtor. The party that sold access to the work is the party that received the money and the party that pays the royalty.
• A regulator and a tax authority have one addressee. What BIT is, who issued it and who delivered against it are never spread over several legal persons.
• Nobody is liable for somebody else. There are no members whose acts could endanger the others, because there are no members.

14.3 What stands against the concentration

What a single party costs is that Bitcash is as well run as that party is. Two things stand against that concentration. The first is verifiability: every row is signed, every holder keeps its own mirror, independent replicas keep the whole ledger, and the supply figures are published (sections 9 and 12), so the Operator cannot quietly restate what it owes or to whom. The second is continuity: the replicated log lets the ledger be rebuilt anywhere with nothing but public keys, so that neither the balances nor their history depend on the Operator's own systems surviving (section 14.5).

14.4 The Rulebook

The Bitcash Rulebook is the published set of rules the Operator binds itself to: acceptance and scope, the fee schedule with its notice period and annual cap, the list price with its notice period, the issuance policy and the gift budget, sales terms and clearing periods, the capacity review, the platform share and the site share, the terms and disclosure of royalties, records and audit. The Operator's terms with holders and with Publishers incorporate it, and no amendment takes effect without the notice periods it specifies.

14.5 Transfer of the role

Should the Operator role pass from one holder to a successor, holders of BIT are not affected. The successor issues its BIT to every open wallet against the outgoing holder's record of outstanding balances, and takes over what is owed to authors and account holders in EUR. The successor rebuilds the ledger from the replicated log of section 9.2 with public keys only, and needs nothing that the outgoing holder alone holds. Because every row is signed and mirrored, the history of every wallet survives the transfer in the hands of its holder; a row a holder has mirrored that is missing from the log, which can happen only for the last moments before a failure, is settled as a claim under the Rulebook.

14.6 Audit

Any holder can verify its own rows offline. The independent replicas verify the whole ledger continuously and can check the supply figures against it. An author can recompute its royalties from the signed usage record of its assets and the published net rates (section 6.5).

15. Roadmap

Bitcash develops in three phases. The dates are targets and may move; a change of phase is announced in a versioned update of this document.

Phase 1, now until May 2027: the founder runs the platform, and no BIT is sold

• The Operator. The role is held by Roberto Bourgonjen as a private individual. He is the author and owner of the Catalog software and the owner of the trademark; he holds the keys, hosts the ledger, runs the servers and operates the software himself, as a private project for his own archive.
• No sales. No BIT is sold, by him or by anyone. Every BIT in circulation was issued by him free of charge, for his own use of the platform, for testing and for demonstration. BIT has no list price and no reference rate in this phase, nobody has paid for any of it, and it cannot be exchanged for money.
• Publisher. He is the only Publisher, with content on his personal websites: writing published as electronic publications, beside photographs, audio and video published as standard content. His archive, some forty terabytes, is stored and deployed on the platform he runs.
• Royalties. None arise. Nothing is sold, so there is no rate at which a royalty could be computed, and the only author is the person who runs the platform.
• Servers. The servers are his property and he operates them. They stand in the secured storage space that Stichting Outpapier, a foundation under Dutch law, rents and maintains for the preservation of his physical archive, under a written agreement on physical archive management between him and the foundation, for which he pays the foundation an annual fee. The foundation preserves physical material and houses the servers that hold its digitised counterpart. It does not operate them: it holds no licence to the Catalog software, runs no node, and takes no part in Bitcash. It issues, sells, accepts and holds no BIT.
• Prices. A published price list in BIT stands in for the fee schedule until the Rulebook adopts one.
• Trademark. Held by Roberto Bourgonjen.

Phase 2, until May 2028: invited artists and small archives

• Invitations. The founder invites artists and small archives to use the platform: to store, register and publish their work on it.
• Free BIT. He provides them with BIT free of charge for that use. Still no BIT is sold, by anyone, and BIT still has no price.
• The Operator. Still the founder, privately, who still runs the servers and operates the software himself.
• Royalties. Still none in money: BIT that was given and never sold brings in no money, and there is no rate at which a royalty could be computed. The metering per asset runs, so that every invited author sees how its works are used.
• Supply figures. Published from the start of this phase: how much BIT has been issued, and how much is in circulation.
• Software. What sales and royalties need, metering per asset, tax categories on payments, statements and self-billing, is completed during this phase.

Phase 3, from 2028: possible sales and royalties

• Sales. BIT may go on sale, at a published list price.
• Royalties. If BIT is sold, authors are paid royalties in EUR for what their works earn.
• Terms. Whether sales begin, and on what terms, is decided before the phase starts and published in a versioned update of this document.

Status by element

16. Trademark

Bitcash® is a registered trademark in the United States, the European Union and the United Kingdom, held by Roberto Bourgonjen. A licence to use the mark authorises no claim of ownership, no sublicensing unless expressly permitted, no confusingly similar registration, no suggestion of regulatory endorsement, and no use outside the permitted scope.

17. Records, reporting and test BIT

The Operator keeps records of BIT issued in each of the two categories of section 6.1, sold, recovered, accepted for services and collected in fees, and of the supply figures it publishes; of the BIT settled to it for services by day and by the country of the paying wallet, together with the reference rate applied; of its net rate table, the licences of its sites and the splits its authors registered; of the usage record and of the royalties accrued to and paid to each author; of the advances to and settlements of each account wallet; and of the supplier profiles of the parties it pays and the statements it issues.

Live BIT and test BIT are kept on separate ledgers. Test BIT has no value, cannot be bought, sold, converted or used to satisfy any live obligation, and is visibly distinguishable wherever it appears.

18. Summary

Bitcash is a prepaid micropayment system with one party behind it. The Operator issues BIT, sells it, accepts it for the services and the content it delivers, and pays the authors of that content in money; BIT begins and ends with the Operator, and it never becomes money in anyone's hands. It is held in wallets of seven kinds, authors are paid royalties in EUR from the ledger's metering of every asset, every movement is signed, mirrored and replicated, the supply is published, and what a BIT buys is fixed by a schedule that changes only slowly. Today the founder runs the platform himself, as a private project for his own archive, and no BIT is sold. Next he invites artists and small archives to use it, with BIT he gives them. Sales and royalties may follow after that.

End of Bitcash Whitepaper.