Bitcash: A Prepaid Micropayment System for Digital Services and Content Access

Public Description and Whitepaper

Last updated: 2026-05-08
Author: Roberto Bourgonjen
Copyright: © 2026 Roberto Bourgonjen. All rights reserved.
Project: Bitcash / BIT

1. Overview

Bitcash is the prepaid micropayment system within Catalog, an integrated suite of applications for creatives and other intellectual-property producers — covering identity (Catalog.ID), payments (Bitcash), mail, chat, a provenance and claims registry (Asset Registry), metadata management, digital rights management, and file storage and delivery. Each module is usable on its own, but all modules are designed to interoperate, enabling individuals, organizations, and developers to publish, verify, and access digital content and services with built-in provenance and privacy — without relying on centralized platforms, advertising, or data harvesting.

Catalog was created by Roberto Bourgonjen, who brings over twenty years of professional experience as an application developer for major institutional archives in the Netherlands. Catalog was engineered from the ground up — after his retirement from business, as a private undertaking — for massive, global scale, built on archival practice proven at national scale, while its usability and feature set were shaped around the founder's own needs as an active photographer, musician, and software developer managing a lifetime of work. It is now licensed for operation to Operators, the first being Stichting Outpapier, a non-profit institution (stichting) established under Dutch law.

Bitcash represents the financial infrastructure within the Catalog suite — payment processing, wallet management, balance accounting, and micropayment settlement — that enables sustainable access to Catalog's digital services and content.

The Bitcash system comprises:

• Bitcash Wallet — a digital wallet for holding, spending, and transferring prepaid value;
• Bitcash Wallet Manager — a desktop application for Windows, macOS, and Linux that enables End Users to create and manage one or multiple wallets locally (see §3.4);
• BIT — the prepaid service credit used as the unit of account for all transactions within the Catalog software;
• Payment processing software — client and server components that handle micropayment authorization, balance deduction, and transaction recording;
• Ledger and settlement systems — internal financial ledger for tracking balances, transfers, and revenue accounting across the Catalog software.

BIT is not a cryptocurrency, security, or investment product. It is a prepaid payment instrument — functionally comparable to a stored-value card or prepaid digital wallet — operated by a licensed Operator.

Participant roles

The Bitcash system defines four participant roles that govern how BIT is created, distributed, and circulated:

The distribution chain is strictly hierarchical:

Founder → Operator → Reseller → End User

The Founder can only allot BIT to Operators. Operators can only fund Resellers and End Users. Resellers can only sell to End Users. At no level may BIT be created except by the Founder; all other transfers move existing BIT from the sender's balance to the receiver's.

In the current deployment, the Founder role is held by Roberto Bourgonjen, and the first Operator role is held by Stichting Outpapier. These specific arrangements are described in §2 and §4.

The Problem

Bitcash exists because making software and digital content available to the public creates three interlocking problems that conventional models fail to solve cleanly.

Funding infrastructure without compromising users. Delivering digital services and content to the public requires servers, bandwidth, storage, and processing power — all of which cost money. The conventional answers to this are advertising, data monetization, or subscriptions. Advertising requires surveillance. Data monetization turns users into the product. Subscriptions create access barriers and fatigue. Each of these models trades away something that should not be negotiable: user privacy, autonomy, or affordability. Bitcash replaces advertising, data monetization, and subscriptions with pay-per-use micropayments — users pay only for what they consume, in amounts small enough to be affordable, without surrendering personal data.

Protecting intellectual property against harvesting. Digital content published on open platforms is vulnerable to mass scraping, unauthorized redistribution, and extraction for AI training datasets. Creators who make their work freely accessible have no practical means to prevent bulk harvesting at scale. Since every access through Bitcash requires a BIT payment, there is no free bulk endpoint to scrape. Mass harvesting becomes economically prohibitive and every request is individually logged and accountable.

Guaranteeing continuity of access. Users and integrators need assurance that the services they depend on will not disappear because the funding model is unsustainable. A system that relies on donations, grants, or a single benefactor's willingness to pay is fragile. Because Bitcash revenue scales directly with usage, the operational funding model is self-sustaining — more users means more resources, not more burden.

In summary, Bitcash enables a system where access is affordable, content is protected, and infrastructure pays for itself.

2. Background and Motivation

2.1 The Founder's position

Roberto Bourgonjen has developed Catalog as a private person. Catalog includes:

• Catalog.ID — a privacy-preserving identity and claim verification framework (see: Catalog.ID Whitepaper);
• Asset Registry — a federated digital provenance service for registering signed claims about digital files (see: Asset Registry Whitepaper);
• Catalog client applications — desktop, mobile, and browser-based clients for interacting with Catalog services;
• Supporting infrastructure — media streaming, file storage, payment processing, and related backend services.

This software is the product of sustained individual effort. The Founder's goal is to make it available to the public — not to operate it himself as a commercial service, but to license it to an Operator that can operate it on behalf of users.

2.2 The operational reality

Software that provides cloud services requires servers. Servers require bandwidth, storage, and compute. These resources are finite and cost money. When usage exceeds capacity, either the service degrades for everyone or additional capacity must be procured. Without a mechanism to align usage with capacity, any free-access model eventually collapses under its own success — or survives only by monetizing user data.

The Bitcash model addresses this by making access to server capacity a measurable, payable quantity. Users prepay for access in the form of BIT tokens. The Operator operating the servers collects BIT as payment for the resources consumed. This creates a direct, transparent link between usage and funding — no intermediaries, no advertising, no data exploitation.

2.3 The licensing arrangement

The Founder has licensed his software to Stichting Outpapier, a Dutch foundation ("stichting") and the first Operator, under the Catalog Server and Client Software License Agreement. The key conditions of this license are:

1. The Operator operates the servers. The Operator operates the Catalog software on server hardware provided by the Founder, providing cloud services to end users.

2. The Operator manages the Founder's archives. The Founder has agreed to pay the Operator €25,000 per year for managing his personal archives and operating servers with his software installed.

3. Access must be metered via BIT. The license stipulates that the Operator must charge micropayments for access to its servers through BIT payments. This applies to all users, including the Founder — there are no exceptions. The Founder purchases BIT from the Operator's webshop like any other End User. This is not optional — it is a condition of the license, designed to ensure that operational costs are covered by usage rather than by donations, grants, or the Founder's personal funds alone.

4. Revenue sharing through cost offset. Half of all BIT revenue collected by the Operator — including revenue from the Founder's own BIT purchases — is discounted from the Founder's annual €25,000 payment, until that payable amount has dropped to zero. Beyond that point, the Operator keeps all BIT revenue.

5. The Founder receives no money. The Founder does not sell BIT tokens and does not receive payment for them. BIT revenue only reduces the amount the Founder pays for archive management and server hosting. This is a cost-sharing mechanism, not an income stream.

This structure ensures that:

• The Operator has a sustainable revenue model from day one.
• The Founder's financial burden decreases as usage grows.
• No party profits from token speculation.
• Users pay only for what they use.

3. What BIT Is

3.1 Definition

BIT is a software-defined unit of account used within the Catalog software for high-frequency, low-value payments. At its core, BIT is an algorithm — a set of rules implemented in software that track balances, authorize transactions, and settle payments on an internal ledger. BIT exists because conventional payment systems (credit cards, bank transfers, payment processors) are not designed for micropayments: their per-transaction fees make payments of fractions of a cent economically impossible. BIT solves this by moving the payment logic entirely into software, where transactions are ledger entries with negligible marginal cost, enabling payments as small as a fraction of a cent at volumes that would be prohibitive through traditional payment infrastructure.

The Bitcash system provides the financial services layer — payment processing, balance management, transaction settlement, and wallet infrastructure — through which BIT is issued, held, transferred, and spent.

BIT is:

• Software — an algorithm for tracking and settling high-frequency, low-value payments;
• A unit of account within the Catalog software, with no intrinsic monetary value outside the system;
• A prepaid stored-value credit for digital services and content;
• Denominated in a fixed unit;
• Subject to expiration (10 years when purchased from the Operator, 1 year when purchased from a reseller — see §5.4);
• Ecosystem-scoped (spendable across the federated Catalog/Bitcash ecosystem — see §8);
• Not redeemable for cash;
• Not a speculative or investment product.

3.2 What BIT is not

While BIT functions as a prepaid payment instrument within the Catalog software, it is not:

• Legal tender or a general-purpose money substitute;
• A blockchain token (BIT balances are maintained on an internal financial ledger, not a public blockchain);
• An investment or security — BIT must never be marketed as appreciating in value, yielding returns, or generating profit;
• Transferable to external exchanges or third-party platforms;
• A speculative asset.

BIT is functionally comparable to a stored-value card or prepaid digital wallet: you load credit, you pay for services, the credit is consumed. The difference is scale: BIT is designed for micropayments — individual transactions measured in fractions of a cent, at frequencies that conventional payment systems cannot economically support — providing the payment infrastructure that connects users to services within the Catalog software.

3.3 The Bitcash Wallet

BIT is held in a Bitcash Wallet — a digital wallet that provides prepaid payment services including balance storage, payment authorization, and transaction history. Each wallet is identified by a bearer-style Wallet Code in the format:

CASH-{operator}-XXXX-XXXX-XXXX-XXXX-XXCC

The Wallet Code is 34 characters long and consists of four positional fields, separated by dashes:

• CASH — a 4-character TYPE prefix indicating the kind of code. Normal spending wallets carry CASH; variants use GIFT (Gift Vouchers, §5.6), DEMO (Demo Wallets, §5.7), FUND (Receive Addresses, §5.9), AUTH (Authorized-Spend Tokens, §5.10), and FORK (Fork Addresses, §5.11). The TYPE prefix is decoration for human consumption — it lets a reader distinguish the kinds at a glance — and also serves as a hint the validator cross-checks after paste against the type encoded in the checksum (see below). The prefix itself is redundant with the checksum: machine surfaces strip it on ingress and carry only the 24-character compact form.
• {operator} — a 4-character Operator ID from a reduced charset excluding visually confusing characters (0/O, 1/I/l) — for example, b4np. Operator IDs carry no semantic content about the Operator's identity or jurisdiction (see Asset Registry Whitepaper §8.1.2). All wallets under a given Operator — whether belonging to Resellers or End Users — share the same operator code, making the Operator relationship immediately visible from the Wallet Code.
• XXXX-XXXX-XXXX-XXXX-XXCC — 18 random characters drawn from a 54-character alphabet (mixed case, digits, no visually confusing letters) followed by a 2-character type-aware checksum (CC). The 18 random characters carry approximately 104 bits of entropy. The checksum is computed over the operator code and the random body, and the last character is then shifted in the alphabet by the code's type ordinal (CASH=0, GIFT=1, DEMO=2, FUND=3, AUTH=4, FORK=5). This lets client software detect transcription errors locally and — because the shift is recoverable from the checksum alone — also identify the code's type from the 24-character body without consulting the Operator. Since CASH is ordinal 0, CASH codes produced under this rule are bit-identical to codes produced under the earlier type-agnostic variant, and all previously distributed CASH codes remain valid.

All six code kinds (CASH, GIFT, DEMO, FUND, AUTH, FORK) share exactly the same layout and the same 104-bit entropy budget. Two useful consequences follow from encoding the type in the checksum rather than only in the TYPE prefix: first, any given body + checksum is valid for exactly one type, so the six kinds live in disjoint namespaces and a code from one cannot be re-presented as a code from another. Second, internal systems can carry just the compact form and recover the type from it — the TYPE prefix is never load-bearing on the wire, only on the page.

Possession of the Wallet Code enables spending of the associated BIT balance. Wallet Codes are bearer instruments — like cash, if lost or stolen, the BIT may be unrecoverable. Users are responsible for securing their Wallet Codes, and the Secure Desktop Wallet Manager described in §3.4 is the recommended way to do so.

In addition to the bearer Wallet Code, every wallet may optionally publish one or more Receive Addresses — short, non-spending public identifiers that other wallets can transfer BIT into without the holder ever revealing their Wallet Code. A Receive Address is safe to print on a card, encode in a QR, or display on a webpage: possession of a Receive Address does not grant any ability to spend the wallet's balance or to inspect the wallet's state. Receive Addresses are described in detail in §5.9.

The Bitcash Wallet serves as the primary financial account for users within the Catalog software. It supports:

• Balance management — loading, holding, and spending prepaid value;
• Payment authorization — authenticating and processing micropayments for services and content;
• Transfer — sending BIT between wallets via Gift Vouchers (§5.6), Demo Wallets (§5.7), or direct transfers to a Receive Address (§5.9), subject to applicable fees;
• Transaction records — maintaining a ledger of all financial activity on the wallet.

Every wallet — whether created through a webshop purchase (§5.2, §5.4), a Gift Voucher (§5.6), or a Demo Wallet (§5.7) — requires an initial deposit of at least 1,000 BIT. (A Receive Address (§5.9) is not a separate wallet but an attribute of an already-funded wallet, and so is not subject to this minimum.) The wallet is not registered on the ledger until this threshold is met. Subsequent deposits to an existing wallet have no minimum. The minimum prevents address spam: without it, an attacker could cheaply generate large numbers of wallets, each consuming storage and expiration-cascade bookkeeping, at negligible cost. The webshop may enforce a higher minimum (currently 5,000 BIT) to cover payment-service-provider transaction costs and the Operator's accounting obligations on EUR-denominated sales; the 1,000 BIT floor is the system-wide minimum that applies regardless of the funding path.

3.4 Secure Desktop Wallet Manager

The Bitcash system includes a desktop wallet manager application that provides secure, user-friendly management of Bitcash Wallets and their associated artifacts. The wallet manager is the recommended way for End Users to hold, spend, and organize multiple wallets — particularly for those who hold more than one wallet, who create Gift Vouchers or Demo Wallets on behalf of others, or who publish Receive Addresses (§5.9) for inbound payments.

Because Wallet Codes are bearer instruments, the primary security concern for any wallet-holding software is how the code is stored at rest. The wallet manager addresses this by never storing Wallet Codes in plaintext. On first run it derives a device-bound master key from the operating system's native secret store — GNOME Keyring or KWallet (via libsecret) on Linux, DPAPI on Windows, or Keychain Services on macOS — and uses it to encrypt every Wallet Code the user imports or creates. The master key is unlocked by the operating system's own authentication (desktop login, TPM-sealed user profile, or Keychain authorization) and is accessible only to the signed-in user on the same device.

Routine operations — fetching balances, checking expiration, listing activity, tracking child wallets — do not require the Wallet Code and are performed through non-spending internal identifiers, so the OS keyring remains locked during background work. The Wallet Code is decrypted in memory only for the duration of an actual spending operation (creating a Gift Voucher, Demo Wallet, or Fork Address, transferring BIT, creating or disassociating a Receive Address, or explicitly revealing the code for sharing) and is cleared immediately afterwards. The in-browser user interface of the manager never receives plaintext Wallet Codes; reveal actions go through an explicit one-shot endpoint that the user invokes only when they intend to display or share a code.

The wallet manager tracks labels, notes, child wallets, Receive Addresses, and any Fork Addresses (§5.11) for which the managed wallet is either the creator or a bound output, and provides a navigable tree view of the wallet hierarchy. It runs fully offline against a local database and synchronizes wallet state from the Operator's public API using only non-spending identifiers. Cross-device availability — where the same wallet tree and annotations are available on any machine the user has linked to their Catalog.ID — is a planned extension (§8).

4. Minting and Allotment

4.1 Minting authority

BIT is created by the Founder as part of the Catalog/Bitcash software. The Founder defines the token format and the ledger mechanisms; the issuance rules under which BIT enters circulation are described in §5. No other party — including Operators, Resellers, or End Users — may create, mint, or define alternative BIT tokens within the software. The Founder is the sole source of all BIT.

4.2 Allotment to Operators

The Founder provides each Operator with an initial allotment of newly minted BIT at no charge under the license and program terms. For the first Operator (Stichting Outpapier), this is 200,000,000 BIT, delivered to the Operator's wallet upon commencement of operations.

The Founder and Operator shall periodically review the adequacy of the circulating supply, taking into account sales volume, BIT lost to dormant wallets, BIT destroyed through the platform fee (§6.4), and the Operator's server capacity. Where the review indicates that additional BIT is required to sustain normal operations, the Founder may allot additional BIT to the Operator at no charge.

The allotment is not a sale, and it is not a gift. BIT has no intrinsic monetary value. BIT is a unit of account representing future access to services that only the Operator can deliver. An allotment of BIT to an Operator does not constitute a transfer of economic value — it provides the Operator with an accounting mechanism through which its actual inventory (software and services, in a by definition limited capacity) can be sold via prepayment and consumed pay-as-you-go. The Operator assumes no obligation by receiving BIT; obligation arises only when the Operator sells BIT to an End User or Reseller (§5.2, §5.4), at which point the Operator — not the Founder — has created the economic value by committing to deliver the corresponding server capacity. Unsold BIT in the Operator's inventory represents neither an asset nor a liability.

The Founder does not sell BIT to Operators. Allotments are provided as a mechanism to seed and sustain the system with the payment credits that End Users need to interact with the services.

4.3 Responsible allotment

All allotments — both the initial allotment and any subsequent allotments — are sized responsibly. The Founder considers the Operator's server capacity, current circulating supply, and actual demand when determining allotment quantities. This design principle serves multiple purposes:

1. Prevents overselling. If more BIT were issued than the infrastructure could honor, the system could degrade under load. Responsible allotment ensures that BIT in circulation corresponds to deliverable server capacity.

2. Removes the burden from the Operator. By providing allotments at no charge, the Founder removes the financial burden of acquiring inventory from the Operator. The Operator does not need to purchase tokens — it receives them as part of the license arrangement and sells them to End Users to fund operations.

3. Aligns incentives. As the server infrastructure grows and demand increases, allotments can grow proportionally. This creates a natural, sustainable growth model tied to real infrastructure investment and demonstrated demand rather than token inflation.

4.4 No secondary market

BIT is not designed for, and must not be used in, secondary market trading. There is no exchange, no order book, no price discovery mechanism. BIT has a fixed platform-wide retail price in EUR, and purchasing BIT through the webshop of the operator or a reseller is the only legitimate channel for acquiring BIT.

5. Distribution and Circulation

5.1 The issuance discipline

BIT enters circulation only by being sold by the Operator in exchange for EUR. The Operator may sell BIT directly to End Users (§5.2) or wholesale to Resellers (§5.4). In both cases, money must change hands at the Operator's outbound boundary, and no other path puts BIT into circulation.

Once BIT has left the Operator's inventory through a sale, it is in circulation — whether it is held by a Reseller in inventory or by an End User in a regular wallet. Holders of in-circulation BIT may redistribute it to other parties via the mechanisms described in the subsections that follow. Redistribution is governed by mechanism-specific constraints (in particular, the published-price requirement on Reseller webshop sales, §5.4) but is not itself an issuance event. The issuance discipline applies only to the Operator's outbound boundary.

The full set of permitted flows is summarized below. Each mechanism is described in detail in the subsections that follow.

No other flow is permitted. In particular, Operators may not redistribute BIT to End Users or Resellers by any means other than sale — including via Receive Addresses — because their inventory is allotment-sourced (§4.2) and any non-sale outflow to a non-Operator party would constitute free issuance.

5.2 Webshop sales

The Operator sells BIT to End Users through its webshop. End Users pay in EUR and receive BIT credited to their Bitcash Wallet. The webshop terms clearly state:

• BIT is prepaid service credit, not money;
• Wallet Codes are bearer instruments (loss/theft risk);
• BIT purchased from the Operator expires after 10 years by default (see §5.8);
• BIT is spendable across the federated Catalog/Bitcash ecosystem (§8);
• BIT is not redeemable for cash;
• Webshop purchases are non-refundable; once BIT has been credited to your wallet, the EUR purchase price is final.

5.3 Pricing

The Operator sets the retail price of BIT in EUR, subject to pricing controls in the license agreement. Per-transaction volume discounts apply for larger purchases, enabling institutional and high-volume users to acquire BIT at reduced rates. The standard price, discount tiers, and maximum discount percentages are defined in the BIT Issuance & Distribution Addendum and may only be changed by written amendment.

5.4 Reseller distribution

In addition to selling BIT directly to End Users, the Operator may sell BIT to Resellers — third parties, typically content providers or service operators, who wish to accept BIT as payment on their own platforms and sell BIT to their own audiences. This creates the full distribution chain:

Founder → Operator → Reseller → End User

Reseller inventory

A Reseller purchases BIT from the Operator for EUR. The purchased BIT is transferred from the Operator's balance to the Reseller's wallet — the Reseller's inventory. The Reseller cannot sell more BIT than is available in their inventory at any given time. If a funding request exceeds the available inventory, the transaction fails.

Retail sale by the Reseller

The Reseller sells BIT from their inventory to End Users through their own webshop, using their own payment provider, at the fixed price determined by the system (currently €0.0002 per BIT). The sold BIT is transferred from the Reseller's wallet to the buyer's Bitcash Wallet. This sale is a distribution flow and is fee-free — the full purchased amount is delivered to the buyer. Fees (§6.4, §6.5) apply later, when the End User spends the BIT on content or transfers it via a bearer instrument (§6.6).

5.5 Recycling and resale

When End Users spend BIT on services provided by the Operator or a Reseller, the spent BIT flows out of the End User's wallet and back into the inventory wallet of the providing party. When the providing party is the Operator, this is the inverse of issuance: BIT exits circulation and returns to the Operator's inventory. When the providing party is a Reseller, the BIT remains in circulation — it has simply moved from an End User's wallet back into the Reseller's inventory, which the Reseller previously purchased from the Operator. The Operator or Reseller may then resell that BIT through subsequent webshop sales — for the Operator, each resale is itself a new issuance event, governed by the same discipline as the original sale; for the Reseller, it is a redistribution of already-circulating BIT.

This recycling mechanism means that the initial allotment seeds the economy, but the actual circulating supply is sustained by the alternation of issuance and recycling. Because fees are deducted on each transaction (see §6.4, §6.5), inventory gradually diminishes over time even in a perfectly closed loop, requiring periodic replenishment from upstream.

5.6 Gift Vouchers

A Gift Voucher is a single-use bearer instrument that allows a holder to send BIT to a recipient without either party having to disclose their own Wallet Code. The sender creates a voucher by transferring BIT from their wallet into a freshly issued voucher wallet, and shares the voucher's code (or its QR representation) with the recipient. The recipient redeems the voucher by transferring the full balance into their own wallet.

Gift Vouchers are one of two mechanisms for moving BIT between End Users. The other is a direct transfer to the recipient's Receive Address (§5.9). Both mechanisms redistribute existing BIT; neither creates new BIT. The difference is practical: a Gift Voucher is a fresh intermediate wallet the sender creates and hands over, which survives physical distribution (a printed card at a conference, a sticker on a package) and does not require the recipient to have any wallet at the moment of creation — the recipient may set one up at redemption time. A Receive Address, by contrast, is a stable identifier the recipient has previously published, into which anyone can fund the recipient's existing wallet directly. Gift Vouchers are better suited to ad-hoc, one-shot transfers; Receive Addresses are better suited to ongoing relationships where the recipient has a durable destination to publish.

The security rationale for both mechanisms is the same: Wallet Codes are bearer instruments that grant full spending access, so a sender cannot simply ask a recipient for their Wallet Code in order to fund it. Sharing a Wallet Code would give the sender (and anyone they forwarded it to) full spending access to the recipient's balance. Gift Vouchers solve this by having the sender create a fresh single-use wallet and share that voucher code with the recipient. Receive Addresses solve it by having the recipient publish a non-spending identifier the sender routes funds through.

Gift Vouchers are identified by a Wallet Code with the GIFT TYPE prefix in place of CASH:

GIFT-{operator}-XXXX-XXXX-XXXX-XXXX-XXCC

The format is structurally identical to a normal Wallet Code (§3.3): same 4-char operator code, same 18 random body characters, same 2-character type-aware checksum, same total length. The GIFT ordinal enters the checksum (§3.3), so a GIFT code and a CASH code live in disjoint namespaces — the same body cannot be both. A human reading the code can tell instantly that they are holding a gift voucher rather than a normal wallet.

A Gift Voucher operates under four constraints, enforced server-side:

1. Single credit. A voucher receives exactly one credit, at the moment of creation. Vouchers cannot be topped up.
2. Single full drain. A voucher can be transferred out of exactly once, and the transfer must drain the entire balance. Partial spending is rejected.
3. One-year expiration. A voucher expires one year after creation. Expired vouchers automatically refund their balance to the sender's wallet via the cascade rule (§5.8).
4. Transparent in the return chain. When a voucher is redeemed, the recipient's wallet receives the bits as if the original sender had transferred directly. The voucher itself does not appear as a return-wallet hop in the recipient's chain.

Gift Vouchers are reclaimable by the sender at any time before redemption: because the sender holds the voucher code (they generated it), they may drain the voucher back into their own wallet just as a recipient would. Combined with the automatic refund on one-year expiration, this means that BIT placed in a voucher is not "lost" if the recipient is unreachable or declines to redeem — it returns to the sender either by explicit reclaim or by expiration.

Eligibility

Gift Vouchers may be issued by End Users and by Resellers, drawing from their own paid-for balance. Operators may not issue Gift Vouchers, because Operator inventory is allotment-sourced (§4.2) rather than purchased, and an Operator-issued Gift Voucher would put allotment BIT into general circulation without a sale — in violation of the issuance discipline (§5.1).

Resellers may issue Gift Vouchers but in practice are likely to prefer Demo Wallets (§5.7), which provide tighter control: Demo Wallet bits are spendable only at one of the Reseller's own sites, whereas Gift Voucher bits can be spent at any site under the Operator (potentially funding a competitor's services). The choice between the two mechanisms is the issuer's: Gift Vouchers offer the recipient unrestricted use of the bits; Demo Wallets keep the bits within the issuer's chosen site.

Gift Vouchers are not "voucher codes" in the sense of sales discounts or coupons. No price reduction is involved at any point. A Gift Voucher is a redistribution of already-purchased BIT, not a discount on a sale.

5.7 Demo Wallets

A Demo Wallet is a single-purpose wallet that allows any holder of paid-for BIT to invite another party to consume services on a specific (web)site at the issuer's expense. Unlike a Gift Voucher, a Demo Wallet's balance cannot be drained into the recipient's general wallet — the bits are spendable only on the single (web)site chosen at creation, and any unspent balance returns to the issuer when the Demo Wallet expires.

Demo Wallets are identified by a Wallet Code with the DEMO TYPE prefix in place of CASH:

DEMO-{operator}-XXXX-XXXX-XXXX-XXXX-XXCC

The format is structurally identical to a normal Wallet Code (§3.3): same 4-char operator code, same 18 random body characters, same 2-character type-aware checksum, same total length. The DEMO ordinal enters the checksum (§3.3), so a DEMO code lives in its own namespace disjoint from CASH, GIFT, FUND and AUTH codes.

A Demo Wallet operates under the following constraints, enforced server-side:

1. Spend-locked to a single (web)site. A Demo Wallet's balance is spendable only at the (web)site chosen by the issuer at the moment of creation. It cannot be used to pay for services from any other site, even if the other site is operated by the same Reseller or under the same Operator.
2. No transfer out. A Demo Wallet cannot be drained or transferred to another wallet. The bits exit the wallet only through service consumption at the chosen site (or, on expiration, by returning to the issuer).
3. Top-up only via Receive Address. A Demo Wallet can be replenished after creation through a Receive Address (§5.9) published on the wallet — and only through that mechanism. This is intended for extending a trial or replenishing an event allowance without having to issue a fresh Demo Wallet and redistribute its Wallet Code. The top-up is treated as a peer-to-peer transfer, incurring only the 0.1% platform burn (see §6.6), and it does not extend the wallet's fixed expiration (see constraint 4): the added balance expires at the same moment the original balance would have expired. Inbound credits also do not rewrite the wallet's (return wallet, term) pair — see the Demo Wallet exception to the dominance rule in §5.8 — so the unspent balance always returns to the original issuer at expiration, regardless of who topped the wallet up.
4. Fixed expiration from creation. A Demo Wallet expires at the end of its expiration term, measured from the moment of creation. Unlike regular wallets, the expiration of a Demo Wallet is not reset by activity — neither spending nor receiving a Receive Address top-up extends its lifetime. The issuer chooses the expiration term at creation, which may range from 1 day to 1 year. Unspent bits at expiration return to the issuer's wallet. The fixed-expiration design makes Demo Wallets suitable for time-boxed events such as conferences, where an organizer can hand out Demo Wallets that expire at the end of the event.

Eligibility

Demo Wallets may be issued by End Users and by Resellers, drawing from their own paid-for balance. Operators may not issue Demo Wallets, because Operator inventory is allotment-sourced (§4.2) rather than purchased, and an Operator-issued Demo Wallet would constitute the free placement of allotment BIT into an end-user-controlled wallet — which would violate the issuance discipline (§5.1) regardless of the spend restrictions.

The two issuer roles use Demo Wallets for different but structurally identical purposes:

• A Reseller uses Demo Wallets as a marketing tool: offering prospective customers a small allowance of BIT to try out the Reseller's service before committing to a purchase. In this case the chosen site is necessarily one of the Reseller's own sites, so any bits consumed by the recipient flow directly back into the Reseller's inventory (a closed loop). The economic limit is the Reseller's willingness to spend its EUR-purchased inventory on free trials, which is naturally self-limiting.
• An End User uses Demo Wallets to invite another party to a specific (web)site at the user's expense — for example, to share access to a piece of paid content or to enable a friend to try a service the user enjoys. The chosen site is whatever site the end user wishes to extend the invitation for. Bits consumed by the recipient flow into that site's Reseller's inventory; bits not consumed return to the issuing end user.

In both cases, the bits in a Demo Wallet are an accounting token for a service commitment, not a transfer of unrestricted credit. This is the same framing §4.2 applies to Operator allotments: BIT held in a constrained wallet for a specific service purpose does not constitute economic value in the holder's hands.

Operator-prefix constraint

In jurisdictions and configurations where cross-operator service consumption is not supported — whether for technical reasons or for regulatory ones, such as VAT differences when bits purchased in jurisdiction A are spent in jurisdiction B — the chosen site for a Demo Wallet must be under the same Operator as the issuer's wallet. An End User holding a wallet under Operator O may then only create a Demo Wallet inviting a recipient to a site under Operator O. Where bilateral cross-acceptance agreements are in place between Operators, Demo Wallets may target sites under other Operators participating in the agreement, subject to whatever additional terms those agreements impose.

Distinction from Gift Vouchers

A Gift Voucher (§5.6) and a Demo Wallet superficially resemble each other — both are bearer instruments issuable by End Users and Resellers, and both have a return-on-non-redemption mechanism. They differ in expiration behavior and in what the recipient can do with the bits:

Both mechanisms transfer prepaid stored-value credit denominated in BIT — they are not transfers of money. The Demo Wallet is the more constrained variant: it earmarks the credit for one site, while the Gift Voucher leaves the recipient free to spend the credit on any site under the Operator.

Apart from per-transaction volume discounts (§5.3), no price-reduction mechanisms are permitted. Demo Wallets and Gift Vouchers are not "discount codes" or "coupons" — they are redistributions of the issuer's own paid-for BIT, not reductions of the published BIT price.

5.8 Wallet expiration and the credit policy

Each wallet has an expiration term and a return wallet. Together with the wallet's last-activity timestamp, these values determine when the wallet's balance expires and where it goes when it does. The wallet's effective expiration is last_activity + term: the wallet expires when it has been inactive for the full term.

The pair (return wallet, term) is not a fixed property of the wallet — it is a property of the most recent dominant credit the wallet has received. Three rules govern how the pair is written and how the activity timestamp is updated:

Pair rule. The return wallet and the term are a single atomic pair. They are written together at wallet creation, and rewritten together by certain subsequent credits as defined by the dominance rule below. They are never written separately.

Dominance rule. The pair is rewritten by a credit only if the credit amount is at least three times the recipient's existing balance. A credit smaller than this threshold is added to the recipient's balance but does not alter the recipient's return commitment. Exception: Demo Wallets. The dominance rule does not apply to credits hitting an existing Demo Wallet (§5.7). A Demo Wallet's pair is fixed at creation and is never rewritten by subsequent credits, regardless of amount — any credit (including via Receive Address top-ups, §5.9) is added to the balance but the return commitment stays with the original issuer. This exception is necessary because Demo Wallets are also exempt from the Activity rule below: their expiration is fixed at creation and is not extended by inbound credits. Without the Demo Wallet exception to the dominance rule, an attacker could send a large credit to a Demo Wallet shortly before its fixed expiration, take over the return commitment via dominance, and have the entire unspent balance (including the issuer's contribution) cascaded to themselves on expiration. Combined, the two exceptions guarantee that a Demo Wallet's unspent balance always returns to the original issuer, regardless of who sent BIT to it or when. Exception: Fork Addresses. The dominance rule also does not apply to credits hitting a Fork Address (§5.11). A Fork Address's pair is fixed at creation by the creator's choices — term T between 1 and 100 years, return wallet = creator's wallet — and is never rewritten by subsequent credits. A Fork Address routinely accumulates balance from many unrelated inbound payments, any of which may exceed the dominance threshold at the moment it arrives; without this exception, the most recent large payer would repeatedly capture the return commitment and ultimately divert unsettled accumulations (including other parties' unresolved-output shares) on expiration. Fixing the pair at creation ensures the residual balance always cascades to the creator's return chain regardless of who funded the Fork Address.

Activity rule. Every transaction the wallet participates in — credit, debit, or service payment — resets the wallet's last-activity timestamp. The effective expiration moves forward accordingly. A wallet that is actively used does not expire; it expires only when it has been idle for its full term. Exception: Demo Wallets. A Demo Wallet's expiration is fixed at creation and is not reset by activity. The Demo Wallet expires exactly at the end of its chosen term regardless of usage (see §5.7).

The dominance threshold is the system's mechanism for arbitrating ownership when a wallet is funded by multiple parties. A small top-up — for example, a friend adding a few hundred BIT to a wallet that already holds tens of thousands — does not displace the existing return commitment. Only a credit that constitutes the substantial majority of the wallet's post-credit balance earns the right to set the wallet's term and return destination.

The default term applied by a credit depends on the credit's source:

These defaults are the values requested by the credit. They take effect only if the dominance rule passes; otherwise the recipient's existing pair is preserved.

Cascade on expiration

When a wallet expires, the system performs the following steps in order:

1. Re-point inbound return references. Every other wallet whose return wallet pointed to the expiring wallet has its return wallet updated to the expiring wallet's own return wallet. (If the expiring wallet had no return wallet — i.e., it is a terminal wallet at the top of the chain — the inbound references are cleared.)

2. Transfer the expiring wallet's balance. The expiring wallet's remaining balance is transferred to its return wallet, or burned if it has none.

3. Sweep the expiring wallet. The expiring wallet is marked closed.

The cascade ensures that the return chain is continuously repaired as wallets expire. As long as some live wallet remains upstream in the chain — which is always the case while the Operator's wallet is alive — funds eventually flow up to the Operator through successive expirations. Funds are burned only when an Operator wallet itself expires with no live successor, which is a deliberate terminal condition for the chain.

Worked examples

The following examples involve Operator X, Reseller Y, and two End Users named Bob and Alice. All parties operate under the same Operator. We use the notation K = 3 × (existing balance + 1) for the dominance threshold throughout.

• Bob purchases 10,000 BIT at Operator X. Bob's wallet is empty before the purchase, so the dominance rule trivially passes. Bob's pair becomes (Operator X, 10 year term). His last-activity timestamp is now. Effective expiration: now + 10 years. Bob spends 8,000 BIT over the following months at various sites, leaving 2,000. Each spend resets his last-activity timestamp, so his effective expiration moves forward with each transaction.

• Bob tops up with 500 BIT at Reseller Y. Bob's wallet holds 2,000 BIT. The dominance threshold is K = 3 × 2,001 = 6,003. The credit (500) is well below K, so the dominance rule does not pass. Bob's pair stays (Operator X, 10 year term). The activity rule still applies: Bob's last-activity timestamp moves to this moment, so his effective expiration is now (this moment) + 10 years. The top-up has extended his expiration even though the term and return wallet were not rewritten. Note that on eventual expiration, even the BIT contributed by Reseller Y will flow back to Operator X, not to Reseller Y. This is the natural consequence of the dominance rule: a small contributor does not earn a return claim.

• Bob's wallet drains to 200 BIT; he tops up again with 1,000 BIT at Reseller Y. The dominance threshold is K = 3 × 201 = 603. The credit (1,000) exceeds K, so the dominance rule passes. Bob's pair is rewritten to (Reseller Y, 1 year term). Reseller Y now holds the return claim on Bob's entire 1,200 BIT balance, including the BIT originally purchased at Operator X. Bob's last-activity timestamp resets. Effective expiration: now + 1 year.

• Bob spends down to 100 BIT; Alice swipes a 50 BIT gift to Bob's wallet via his Receive Address. The dominance threshold is K = 3 × 101 = 303. The credit (50) is below K, so the dominance rule does not pass. Bob's pair stays (Reseller Y, 1 year term). However, the activity rule applies: Bob's last-activity timestamp resets, extending his effective expiration to now + 1 year. Alice's contribution is now part of Bob's balance, but Reseller Y retains the return claim.

• Bob purchases 5,000 BIT at Operator X. Bob holds 150 BIT. The dominance threshold is K = 3 × 151 = 453. The credit (5,000) far exceeds K, so the dominance rule passes. Bob's pair is rewritten to (Operator X, 10 year term). Operator X now holds the return claim on Bob's entire 5,150 BIT balance — including the residual BIT from Reseller Y and Alice's gift. Bob's last-activity timestamp resets. Effective expiration: now + 10 years.

• Bob transfers his full 5,150 BIT to a newly created wallet of his own via Receive Address. The new wallet is empty, so the dominance rule trivially passes. The new wallet's pair is set to (Bob's old wallet, 1 year term) — the Receive Address transfer defaults apply. Bob's old wallet is now empty but remains alive with its 10-year term; it will expire after 10 years of inactivity. The new wallet's effective expiration is now + 1 year. If Bob's new wallet eventually expires with balance remaining, the cascade transfers that balance to Bob's old wallet. If the old wallet has itself expired by then, the cascade rule (step 1) will have already re-pointed the new wallet's return reference to the old wallet's own return wallet — Operator X — so the funds ultimately flow up to the Operator.

5.9 Receive Addresses

Where a Gift Voucher (§5.6) requires the sender to create and hand over a fresh bearer voucher, a Receive Address lets an End User publish a compact, non-spending public identifier that other wallets can transfer BIT directly into. A wallet holder can print a Receive Address on a card, encode it in a QR, embed it in a webpage, or share it in a message, without ever exposing their Wallet Code and without the sender having to know anything about the recipient's wallet other than the address itself.

A Receive Address uses a Wallet Code with the FUND TYPE prefix in place of CASH, so the two cannot be confused at a glance:

FUND-{operator}-XXXX-XXXX-XXXX-XXXX-XXCC

The format is structurally identical to a normal Wallet Code (§3.3): same 4-char operator code, same 18 random body characters, same 2-character type-aware checksum, same 34-character total length. The FUND ordinal enters the checksum (§3.3), so a Receive Address lives in its own namespace disjoint from spending Wallet Codes — the same body cannot be simultaneously a CASH/GIFT/DEMO/AUTH code. Unlike a Wallet Code, possession of a Receive Address does not grant any ability to spend the wallet's balance — nor does it grant the ability to query the wallet's state (balance, activity, expiration, kind). The Operator resolves a Receive Address to the underlying wallet only when it is the destination of an inbound transfer; all other lookups on a wallet remain gated by the Wallet Code. Leaking a Receive Address is therefore harmless: an attacker who possesses it can at most send BIT to the wallet, never take BIT from it, and cannot learn the wallet's balance or activity.

Creation and cost

Receive Addresses are generated through the desktop wallet manager (§3.4) or through the in-browser wallet interface. Both paths authenticate the request with the wallet's Wallet Code: the holder queries the service to retrieve existing Receive Addresses, or to register additional ones, by presenting the Wallet Code as proof of ownership. Because a Receive Address grants no spending authority — possession allows only inbound transfers, not balance queries, state inspection, or withdrawals — the service can safely return it to the requesting client, where it may be displayed as a QR code for in-person funding. A user clicks a Receive button in the browser wallet, and the service responds with the address; a second party scans the QR code with their phone to initiate a transfer. This flow enables face-to-face and point-of-sale funding without requiring either party to use the desktop wallet manager.

The first Receive Address on any eligible wallet is free. Every subsequent Receive Address on the same wallet costs a flat 10 BIT, which is burned at the moment of creation. The 10 BIT fee is a soft cap on address proliferation rather than a revenue mechanism: a wallet holder may generate as many addresses as they wish, but each address beyond the first carries a small, visible economic cost, discouraging casual proliferation and bounding the per-wallet storage overhead.

A single wallet may hold up to 128 wallet extensions in total — Receive Addresses and Authorized-Spend Tokens (§5.10) share this cap — a hard limit enforced at creation time. A Receive Address may be explicitly disassociated from its wallet by the holder, authenticated by the Wallet Code: disassociation frees the extension slot and returns the FUND code to the unbound state. The FUND code itself is not destroyed; it may subsequently be rebound to any wallet — the same holder's, a different wallet the holder owns, or an incoming party to whom the holder has delivered the code. Disassociation is the mechanism by which a Fork Address share (§5.11) changes hands without the Fork Address's immutable output list being affected. A holder who merely wishes to stop receiving on a particular address may disassociate it outright; stopping distribution of the code, or creating a fresh wallet for a cleaner break, remain alternatives.

FUND code lifecycle and retroactive binding

Any 34-character FUND code with a valid format and checksum is a syntactically valid Receive Address, whether or not it is currently bound to a wallet. In the ordinary §5.9 generation flow the two steps — creating the code and binding it to a wallet — happen together, so a FUND code in public circulation normally corresponds to a live wallet. Two mechanisms produce FUND codes that exist unbound — real, checksum-valid strings that resolve to no wallet:

• Client-side generation by a Fork Address creator. A Fork Address creator (§5.11) may generate FUND codes client-side (same 104-bit body, FUND checksum) and include them as outputs of a new Fork Address before the recipients' wallets exist. Those codes are stored as part of the Fork Address's own internal state and are retained locally in the creator's desktop wallet manager. The service keeps no separate registry of such codes — outside the Fork Address DOs that list them and the wallet manager of the creator who generated them, a client-side-generated unbound FUND code has no representation anywhere in the system.
• Disassociation by a current holder. The holder of a bound FUND code may at any time release the binding, authenticated by their Wallet Code. The service unbinds the code, frees the wallet-extension slot on the previously-bound wallet, and stops resolving new inbound transfers to that wallet. The FUND code returns to the unbound state and is available to be rebound — to a different wallet (the typical case, used to transfer a Fork Address share to a new holder; see §5.11), to the same holder's own wallet (used to reset the binding or temporarily free extension capacity), or left unbound indefinitely (used to retire the address permanently). If the FUND code is listed as an output of one or more Fork Addresses, disassociation converts that output back to unresolvable from the next settlement onward: the share accumulates in the per-output accumulator until the code is rebound.

An unbound FUND code is not a delivery target: a direct inbound transfer naming it as destination simply fails to resolve. Its only operational function during the unbound interval is to reserve a share inside a Fork Address: at each settlement, the Fork Address's per-output accumulator for that output is credited with the output's share of the distributable balance, and the BIT remains on the Fork Address's balance until the output becomes resolvable.

A holder in possession of a FUND code — whether delivered by a Fork Address creator, received from a prior holder via disassociation, or otherwise come into possession of one — claims it by presenting the FUND code alongside their own Wallet Code to the service, authenticated by the Wallet Code in the usual way. The service binds the FUND code to the claimant's wallet through the ordinary §5.9 registration endpoint; from that moment, inbound transfers to the FUND code resolve to the claimant's wallet, and any Fork Address whose output list contains this code releases the accumulated share to the new wallet on its next settlement. No prior reservation check is performed — the first valid (FUND code, Wallet Code) pair to arrive while the code is unbound wins the binding. Binding consumes one of the target wallet's 128 extension slots and triggers the standard §5.9 per-extension burn (10 BIT beyond the first address on that wallet). Because FUND codes carry roughly 104 bits of entropy and are known only to the parties who have held or been shown the code, an unrelated party who has not been shown the code has no practical way to present it.

Because the Fork Address creator retains the FUND codes they generated in the desktop wallet manager, the creator may at any time bind any still-unclaimed output to their own wallet to reclaim an accumulated share — this is the creator's operational recourse when a recipient never materialises (§5.11). Outside of Fork Address creation, FUND codes continue to be created bound to a wallet at the moment of generation, and enter the unbound state only through explicit disassociation by their current holder.

Which wallets may hold a Receive Address

Receive Addresses may be held on normal (CASH) wallets — whether held by End Users, Resellers, or Operators — and on Demo Wallets (§5.7): any wallet that may legitimately receive inbound BIT from a third party. They are not available on Gift Voucher wallets, whose single-drain semantics (§5.6) would be broken by an inbound top-up: a Gift Voucher is intended to be created at a fixed value and drained in full exactly once, and allowing additional credits after creation would require extending both the dominance rule and the return-on-expiration cascade in ways that would compromise the voucher's bearer-instrument simplicity. They are also not available on Authorized-Spend Tokens (§5.10), which are not themselves wallets and hold no balance of their own, nor on Fork Addresses (§5.11), whose single-inbound-endpoint design treats the Fork Address code itself as the receive surface and admits no additional publishable addresses.

The typical use cases differ by wallet kind:

• End Users use Receive Addresses as donation and invoicing destinations — a content creator publishing a tip address on their site, a freelancer sending a single durable address to a repeat client, a household member giving family members a way to reimburse expenses without having to create and hand over fresh Gift Vouchers for every transfer.
• Demo Wallets use Receive Addresses to solve the top-up problem: a Demo Wallet is a bearer instrument that cannot normally be credited after creation, so a published Receive Address lets the issuer extend a trial or replenish an event allowance without having to create a fresh Demo Wallet (and a fresh Wallet Code) every time. The fee structure on the top-up is identical to creating a new wallet, so the choice between "top up the existing demo" and "create a new one" is purely operational.
• Resellers use Receive Addresses as tipping destinations — a site owner can publish a Receive Address on their homepage, above the fold, so readers can send BIT directly as a tip for content they enjoyed. Tips flow straight into the Reseller's inventory wallet without going through the Reseller's webshop purchase flow. This creates a low-friction discretionary-payment channel alongside the standard per-item metered access.
• Operators use Receive Addresses as the destination for inter-operator federation settlements — see §8.1 for the direction and mechanics.

Sending BIT to a Receive Address

To fund a Receive Address, the sender's wallet software issues a transfer request naming the Receive Address as the destination. The Operator validates the address format and checksum, resolves it to the recipient wallet internally, and processes the transfer through the regular transfer pipeline. The sender never sees or learns the recipient's Wallet Code or any internal identifiers — only the Receive Address they already knew. The recipient's list of Receive Addresses is accessible only to the recipient themselves through the wallet manager, authenticated by the Wallet Code.

The credit policy rules of §5.8 apply in the usual way: the transfer is subject to the dominance rule for return-wallet rewriting, and it updates the recipient's last-activity timestamp. Receive-address transfers are classified as peer-to-peer transfers of stored value, not as service consumption, and therefore incur only the 0.1% platform fee (burned) — not the 2% operator fee (see §6.6). This keeps direct transfers through a Receive Address as cheap as the equivalent Gift Voucher path. Inter-operator federation settlement (§8.1) carries the same 0.1% platform burn, borne by the selling Operator as a cost of settlement.

Eligibility of the sender

Receive-address transfers may be initiated by End Users and by Resellers, drawing from their own paid-for balance. Operators may initiate receive-address transfers for inter-operator federation settlement only (§8.1): the destination must be another Operator's wallet, and the transfer must represent a wholesale sale of accumulated foreign-consumption BIT against EUR consideration evidenced by a conventional invoice — not a gift, a reward, or an unconditional outflow. Operators may not use receive-address transfers to fund End User or Reseller wallets, because their inventory is allotment-sourced (§4.2) rather than purchased, and any such non-sale outflow to a non-Operator party would constitute free issuance in violation of the issuance discipline (§5.1). This restriction mirrors the existing prohibition on Operators issuing Gift Vouchers or Demo Wallets (§5.6, §5.7).

Why both Receive Addresses and Gift Vouchers exist

Receive Addresses and Gift Vouchers solve similar problems from opposite directions, and the choice between them is practical rather than economic. A Gift Voucher is an intermediate wallet the sender creates in advance and hands over, which means it works when the recipient has no wallet yet, when the recipient cannot or will not publish an identifier, and when the distribution channel is a physical object (a printed card, a sticker, a gift-wrapped token). A Receive Address is an identifier the recipient publishes in advance, which means it requires the recipient to already hold a wallet and to have shared the address through some channel, but once published it lets any sender fund the recipient's existing wallet directly, without either party having to create or redeem an intermediate wallet. Gift Vouchers are one-shot and single-drain; Receive Addresses are durable and can receive any number of deposits, from the same sender or different senders, over the wallet's lifetime.

The two mechanisms are not in competition: a wallet holder may use both, and in practice most active users will. A conference exhibitor might hand out Gift Vouchers at their booth while also publishing a Receive Address on their website for returning customers. A content creator might accept donations to a published Receive Address while sending individual Gift Vouchers as thank-you presents. Both mechanisms move existing BIT; neither creates new BIT, and neither changes the overall issuance discipline.

5.10 Authorized-Spend Tokens

A Wallet Code is a bearer secret: possession is authorization, and whoever holds the code can spend the entire balance in any way the wallet permits. This is appropriate for the holder's own operational clients — the desktop wallet manager, the browser wallet, a device the holder controls — but it sets a low ceiling on the set of flows the system can safely support for third-party spending. Anything that involves handing a spending secret to someone else — a vendor accepting recurring charges, a merchant running a point-of-sale transaction, a subscription service debiting a wallet month after month, or a household card issued to a family member — is unsafe with a raw Wallet Code, because nothing in the protocol confines what the recipient can do with the code once they hold it.

An Authorized-Spend Token ("AUTH token") solves this. In practical terms, issuing an AUTH token is like issuing your own credit card: you pick which services it works at, you pick the spending limits, you pick the expiration date, and you can cancel it at any time — but the BIT it spends comes from your own pre-funded wallet rather than a line of credit extended by a bank. The same mechanism lets a holder hand a capped, revocable spending card to a family member or friend so that they can access content and services under the holder's budget, without ever being given the underlying Wallet Code.

Under the hood, an AUTH token is a derived, revocable, scope-restricted code that authorizes a defined set of counterparties to debit a specific underlying wallet under specific constraints. An AUTH token is not itself a wallet. It has no balance, no spending address, and no independent existence — it is purely an authorization that points debits at an underlying wallet within the constraints the holder set at issuance. Losing or sharing an AUTH token can therefore expose no more than the limited debit authority the token itself grants.

The AUTH token is the outbound dual of a Receive Address (§5.9): where a FUND code is a non-spending identifier the holder publishes so that anyone can fund the wallet, an AUTH code is a bounded debit authorization the holder issues so that one or more named counterparties can charge the wallet. The two together let the wallet holder control both directions of traffic across the wallet boundary without ever having to share the Wallet Code itself.

An AUTH token uses the same 34-character layout as other TYPE codes, with the AUTH TYPE prefix:

AUTH-{operator}-XXXX-XXXX-XXXX-XXXX-XXCC

The format is structurally identical to a Wallet Code (§3.3): same 4-char operator code, same 18 random body characters, same 2-character type-aware checksum, same 34-character total length. The AUTH ordinal enters the checksum (§3.3), so an AUTH token lives in its own namespace disjoint from spending Wallet Codes and from Receive Addresses — the same body cannot be simultaneously an AUTH token and a CASH/GIFT/DEMO/FUND code. An AUTH token therefore travels through the same channels as any other code — transcribable on a card, encodable in a QR, pasteable into a payment form — with no new transport requirements. It is not, however, interchangeable with a Wallet Code: the Operator rejects any attempt to use an AUTH token where a spending Wallet Code is expected, and vice versa.

Constraints carried by the token

Each AUTH token carries the constraints under which the authorization is valid. The first version of the token keeps the configurable surface deliberately small — just enough to cover the common sharing cases without introducing mechanics that the initial implementation cannot enforce cleanly. Each constraint is registered with the Operator at the moment of issuance and is evaluated server-side on every debit attempt:

• Site list. One or more domain names at which the token may be used. An attempted debit from a site whose domain is not on the list is rejected. The list may be left open (no site restriction) where scoping by site is not required.
• Service-type list. One or more service categories from a fixed enumeration maintained by the Operator — for example, CONTENT for per-item content access, with further categories added as the platform grows. An attempted debit for a service whose type is not on the list is rejected. The list may be left open where scoping by service type is not required.
• Expiration. At creation the holder chooses either a date between 1 day and 10 years after issuance, or no expiration. If an expiration date is set, it is fixed from creation and is not reset by activity — the token expires exactly at the chosen time regardless of whether it has been used, after which it no longer authorizes any debit. A non-expiring token remains valid until the holder revokes it (below) and is bounded only by the site, service-type, and cap constraints. The dated form matches the fixed-expiration behavior of Demo Wallets (§5.7); Demo Wallets do not offer the non-expiring option, since their prefunded balance and bound-site scope make a perpetual demo instrument inappropriate.
• Daily cap. The maximum cumulative BIT the token may debit within a single calendar day. The counter resets at 00:00 CET each day. The holder sets this value at creation; there is no default.
• Monthly cap. The maximum cumulative BIT the token may debit within a single calendar month. The counter resets at 00:00 CET on the 1st of each month. Enforced independently of, and composably with, the daily cap: a debit is admitted only if it fits within both the current day's remaining allowance and the current month's remaining allowance.
• Revocation. The holder may revoke the token at any time through the desktop wallet manager. Once revoked, all further debits are refused, while debits already completed remain on the ledger.

An AUTH token grants only the authority to debit the underlying wallet for a service on the token's site and service-type lists, within the daily and monthly caps, before expiration, and before revocation. It confers no other authority: the counterparty cannot inspect the underlying wallet's balance or activity, cannot derive the Wallet Code, cannot create further AUTH tokens on the wallet, and cannot transfer BIT out of the wallet by any path other than an authorized debit. An AUTH token is not itself a destination — it has no balance and no Receive Address — so it cannot be funded; any attempt to transfer BIT to an AUTH token is rejected.

Richer constraint shapes — for example, per-counterparty Wallet Code or Catalog.ID targeting, per-transaction caps independent of the window caps, or more sophisticated rolling-window policies — are natural extensions of the same token and may be introduced in later revisions without changing the AUTH code format.

Relationship to Demo Wallets

A Demo Wallet (§5.7) is a prefunded AUTH: it shares the fixed-expiration and scope-restriction properties of an AUTH token, but it also carries its own prefunded balance and its own spending address, so it is a fully self-contained wallet rather than a pure authorization. A recipient holding a DEMO code can spend it at the bound site directly from the DEMO's own balance, and the wallet can publish a Receive Address to accept top-ups that extend the prefunded amount (§5.7). A recipient holding an AUTH token, by contrast, never holds BIT — every debit the recipient presents flows directly out of the underlying wallet under the AUTH constraints.

This is a useful unification. Demo Wallets are what you issue when you want to hand the recipient an endowment they can spend at a site; AUTH tokens are what you issue when you want to let a counterparty pull from your wallet under caps you control. The DEMO and AUTH prefixes are retained as distinct TYPEs because the external behavior differs (DEMO has a spending address and its own balance; AUTH does not), but both are implemented on the same scope-and-expiration engine.

Narrow and broad tokens

The site-and-service-type lists let a holder shape an AUTH token anywhere along the range between a single-site token and an unrestricted card:

• A narrow token names a single site and, typically, a single service type. It behaves as a virtual, single-site card — handy for a recurring subscription at one provider, and trivial to revoke without disturbing any other relationship.
• A curated token names a list of sites the holder trusts and a list of service types the holder is happy to fund. It behaves as a conventional credit card, usable at any of those sites for any of those service types up to the daily and monthly caps — appropriate for a card shared with a family member or friend whose access the holder wants to bound to a chosen set of sites.
• An open token leaves the site and service-type lists unrestricted and relies solely on the daily and monthly caps to bound exposure. This is the most permissive form and is appropriate only for highly-trusted contexts — for example, a short-lived token used across the holder's own devices.

The same primitive spans the full range; only the site and service-type lists encoded in the token change. A holder may issue any mix of narrow, curated, and open tokens on the same underlying wallet.

Which wallets may hold AUTH tokens

AUTH tokens may be issued on CASH wallets, Reseller wallets, and Operator wallets — any wallet whose holder may legitimately delegate bounded debit authority to a third party. They are not available on GIFT wallets (whose single-drain semantics, §5.6, leave no room for ongoing bounded spend), on DEMO wallets (whose bound-site restriction, §5.7, already fills the scoping role the token would otherwise provide), on other AUTH tokens (no recursion — a token cannot itself carry further tokens), or on Fork Addresses (§5.11), which have no discretionary spending surface — all outflows are predetermined settlement distributions to the configured output list.

Issuance and cost

AUTH tokens are issued through the desktop wallet manager (§3.4) or through the in-browser wallet interface. Both paths authenticate the request with the underlying wallet's Wallet Code, exactly as Receive Address creation does. The client submits the desired counterparty set and caps; the Operator registers the token and returns the token's 34-character code to the client. The client may then display the code as a QR for in-person handoff or transmit it to the counterparty through any ordinary channel.

The first AUTH token on any eligible wallet is free. Every subsequent AUTH token on the same wallet costs a flat 10 BIT, which is burned at the moment of issuance — a soft cap on token proliferation analogous to the per-address burn on Receive Addresses (§5.9). AUTH tokens share the per-wallet extension cap of 128 with Receive Addresses (§5.9), a hard limit enforced at issuance time; revoking a token frees a slot for a new one.

Debiting through an AUTH token

To debit an underlying wallet through an AUTH token, the counterparty submits a debit request to the Operator, naming the AUTH token as authorization, its own receiving wallet as destination, and the site and service type under which the debit is being made. The Operator validates the token's format and checksum, confirms the declared site matches the token's site list (or that the list is open), confirms the declared service type matches the token's service-type list (or that the list is open), checks that the requested amount fits within both the current day's remaining daily allowance and the current month's remaining monthly allowance (both measured in CET), verifies that the token is not expired or revoked, and — on all checks passing — processes the transfer from the underlying wallet to the destination. The counterparty never sees the underlying Wallet Code or any of its internal identifiers, only the AUTH token it was handed.

The credit-policy rules of §5.8 apply to the underlying wallet in the usual way: the debit counts as activity and resets the last-activity timestamp of the underlying wallet; the dominance rule applies to the destination wallet in the normal manner. Fees follow the ordinary schedule in §6.6: a debit classified as service consumption carries the full 2.1% (0.1% platform burn plus 2% operator fee), while a debit classified as a peer-to-peer transfer carries only the 0.1% platform burn. The AUTH-token wrapper does not change the fee classification; it only authorizes the debit.

A counterparty that needs to retry a debit after a transient transport failure — for example, a network timeout that prevented the Operator's response from being received — may include an opaque idempotency key on the request and present the same key on each retry. Within a short replay window after the first attempt, the Operator returns the cached original response to any retry carrying the same key, and the underlying debit is processed at most once regardless of how many times the request is sent. The key is optional and follows the standard idempotency-key pattern used by mainstream payment APIs; counterparties that do not need retry safety may omit it.

Disputes

Disputes over whether a particular AUTH-authorized debit was legitimate — for example, a vendor charging more than the holder expected, or a vendor failing to deliver the service paid for — are out of scope for the Bitcash protocol. BIT is not money, no party offers cash redemption, and peer-to-peer transfers settle on the internal ledger at the moment of transfer, so there is no mechanism analogous to a credit-card chargeback to reverse a completed BIT transaction. Where a vendor's conduct warrants a refund or reversal, it is handled commercially between holder, vendor, and Operator under the applicable service-level terms, not by forcing a ledger reversal at the protocol layer. The holder's operational recourse at the protocol layer is revocation: revoking cuts off all further debits through the disputed token immediately, while already-completed debits remain on the ledger pending commercial resolution.

5.11 Fork Addresses

Where a Receive Address (§5.9) routes inbound BIT to a single destination wallet, a Fork Address routes it to many — up to 128 direct outputs — in proportions the creator sets at the moment of creation. Outputs may themselves be Fork Addresses, to one level of nesting, so a single top-level Fork Address can ultimately fan payments out across up to 128 × 128 = 16,384 distinct FUND addresses. Incoming payments do not settle immediately; they accumulate on the Fork Address's balance and are distributed in batches, on a share-weighted basis, to the configured output addresses. The primary use cases are publication royalty splits (an edition royalty divided among author, editor, illustrator, and publisher), collaborative revenue pools (a band or a software project distributing income among members), and share-based content registries (an artwork with up to 128 — or, with one level of nesting, up to 16,384 — entitled holders each receiving a fractional payout on every sale or access).

Fork Addresses use a Wallet Code with the FORK TYPE prefix in place of CASH:

FORK-{operator}-XXXX-XXXX-XXXX-XXXX-XXCC

The format is structurally identical to other Wallet Codes (§3.3): same 4-char operator code, same 18 random body characters, same 2-character type-aware checksum, same 34-character total length. The FORK ordinal (5) enters the checksum (§3.3), so a Fork Address code lives in its own namespace disjoint from CASH, GIFT, DEMO, FUND and AUTH codes — the same body cannot be simultaneously any other type. A human reading the code can tell instantly that they are holding a Fork Address rather than a spending wallet or a single-destination receive address.

A Fork Address is not a spending wallet: it has no counterparty-facing spending authority, no AUTH tokens can be issued against it, and it does not publish its own FUND Receive Addresses — the Fork Address code itself is the receive endpoint. A Fork Address does hold a BIT balance, but only transiently, as an accumulation buffer between inbound payments and their eventual distribution to the configured outputs.

Outputs, shares, and unresolvability

A Fork Address is created with 1 to 128 outputs, each consisting of:

• A FUND code (§5.9) or FORK code (§5.11) identifying the destination; and
• An integer share weight from 1 to 65535.

The share weight determines the output's fraction of each settlement: an output with weight w_i receives floor(D × w_i / total_weights) BIT per settlement, where D is the Fork Address's current balance and total_weights is the sum of all outputs' weights. If every output has weight 1, the distribution is even; asymmetric weights produce asymmetric shares (1 and 2 yield 1/3 and 2/3, 1 and 3 yield 1/4 and 3/4, and so on). A single-output Fork Address is permitted but is of limited utility — it devolves to a receive-and-delay buffer between the Fork Address code and a single downstream address.

An output code must be valid (correct format and checksum). FUND outputs need not be bound to a wallet at the moment of Fork Address creation; FORK outputs must resolve to an existing, active Fork Address whose own output list contains no further FORK outputs. Three assignment patterns are supported:

• Bound FUND outputs. The FUND code is already a live Receive Address (§5.9) on a CASH or other FUND-hosting wallet. At each settlement, the output's share transfers directly to the wallet behind the FUND.
• Unresolvable FUND outputs. The FUND code is generated client-side by the Fork Address creator (same 104-bit body, FUND checksum) for a recipient whose wallet does not yet exist — for example, a publisher pre-allocating a royalty share to an author the publisher has not yet reached, or reserving a slot for a future collaborator. The code is listed as an output in the Fork Address's own internal state and retained locally in the creator's wallet manager, but does not resolve to any wallet until its recipient claims it (§5.9). No separate service-side registry of unbound FUND codes exists.
• Nested FORK outputs. The output targets another, already-existing Fork Address by its FORK code. At each parent settlement, the output's share transfers to the nested Fork Address as an ordinary inbound peer-to-peer payment, where it accumulates toward that Fork Address's own settlement threshold (see Nesting and staggered delivery below). Nesting is limited to one level: the service verifies at creation of the parent that every FORK output resolves to a Fork Address whose own output list contains no FORK outputs. A parent with 128 FORK outputs, each of which is in turn a Fork Address with 128 FUND outputs, fans payments out across up to 128 × 128 = 16,384 distinct FUND addresses.

An unresolvable FUND output does not block settlement. When the Fork Address settles, resolvable outputs receive their shares as normal; each unresolvable output has its calculated share added to an internal per-output accumulator on the Fork Address, and the BIT remains on the Fork Address's balance. When the recipient subsequently binds the FUND code to their wallet (§5.9), the accumulated amount is released to them on the next settlement.

Creation, immutability, and cost

A Fork Address is created by a CASH wallet (an AUTH token, §5.10, may pay the creation fee on the creator's behalf within its caps and scope). The creator submits:

• The desired list of outputs (each a FUND or FORK code paired with a share weight, 1 to 128 outputs in total);
• The chosen expiration term T, in whole years from 1 to 100.

For any FORK output in the list, the service verifies at creation that the nested Fork Address exists, is active, and itself contains no FORK outputs — enforcing the one-level nesting cap. A creation attempt referencing a nested Fork Address that itself contains FORK outputs is rejected.

A Fork Address is immutable after creation: no output may be added, removed, or reweighted, and the expiration term cannot be extended or shortened. A creator who needs to change the routing deprecates the Fork Address in the upstream system that directs payments to it — simply stops publishing or using the Fork Address code — and creates a fresh one. The deprecated Fork Address continues to settle any pending unresolvable-output accumulations as claims arrive, and cascades its residual balance to the creator's return chain at expiration.

Immutability is a deliberate design choice: a Fork Address is a commitment by its creator to a specific distribution that payers and output holders can rely on for the life of the wallet. Mutability would let a creator reweight a share downward after payments had already been accepted against the original weighting, undermining the trust the routing primitive is meant to establish.

The creation fee is a flat burn:

10 BIT base + 1 BIT per output + 10 BIT per year of term, all burned at creation.

Representative totals:

The 10 BIT base is a soft cap on Fork Address proliferation, analogous to the per-extra-Receive-Address burn in §5.9. The per-output component scales the cost with the complexity of the distribution — a 128-way split is costlier to maintain than a 2-way split. The per-year component reprices the storage commitment so that a creator who wishes the Fork Address to survive multiple decades of potential dormancy pays a proportionally larger upfront fee. At €0.0002 per BIT, even a 128-output 100-year Fork Address costs only about €0.23 — negligible for any legitimate publication or royalty use case, but enough to discourage casual abuse.

A creator who cannot confidently commit to a term long enough to outlive all realistic claim windows — for example, an art registry whose piece might only find its audience decades after creation — can in practice choose the maximum 100-year term, at the cost above. Shorter terms are appropriate for operational Fork Addresses where the routing is expected to be refreshed on a known cadence.

Inbound payments, accumulation, and settlement

Any BIT flow that may target a wallet may target a Fork Address: peer-to-peer transfers, service payments, content payments, tips, and donations. Fees on the inbound transaction follow the ordinary schedule of §6.6 by transaction type — a peer-to-peer transfer pays the 0.1% platform burn; a service or content payment pays the full 2.1% (platform burn plus operator fee); the net in each case is credited to the Fork Address's balance.

Inbound payments accumulate on the Fork Address's balance; they are not distributed on arrival. Settlement is triggered when the balance reaches the minimum settlement threshold of 1000 BIT, at which point the Fork Address automatically distributes according to the share weights. In practice the trigger is evaluated on every inbound: the credit that takes the balance across the threshold is followed immediately by a settlement pass.

Settlement proceeds as follows:

1. Let D be the Fork Address's current balance.
2. For each output i, compute the assigned amount a_i = floor(D × w_i / total_weights).
3. For each resolvable FUND output, transfer a_i to the bound wallet via the ordinary Receive Address transfer path. This is a peer-to-peer transfer and incurs the standard 0.1% platform burn per output (see §6.6).
4. For each FORK output, transfer a_i to the nested Fork Address as an inbound peer-to-peer transfer. The same 0.1% platform burn applies per output; the net credits the nested Fork Address's own balance, where it accumulates toward that Fork Address's own settlement threshold.
5. For each unresolvable FUND output, add a_i to the Fork Address's per-output accumulator for that output. The BIT remains on the Fork Address's balance and is recorded against that output in the Fork Address's internal ledger.
6. The rounding residual (D − Σ a_i) stays on the Fork Address's balance as dust, which participates in the next settlement.

When the holder of an unresolvable output later binds the FUND code to their wallet (§5.9), the output transitions to resolvable. The accumulated amount in the per-output accumulator is released at the next settlement — together with the output's share of whatever dust and freshly accumulated balance remains on the Fork Address at that point.

Nesting and staggered delivery. When a parent Fork Address settles to a nested Fork Address, the share arrives as an inbound credit on the nested Fork Address's balance; it does not immediately reach the nested Fork Address's FUND outputs. The nested Fork Address enforces its own 1000 BIT settlement threshold exactly as a top-level Fork Address does, and distributes only when that threshold is crossed (or forced; see below). Delivery across a two-level tree is therefore staggered: a payment to the root must first push the root across 1000 BIT — triggering settlement to its nested Fork Addresses — and each nested Fork Address must in turn accumulate across its own 1000 BIT threshold before its share of that payment reaches the leaf FUND addresses. Each level's settlement pass resets its own activity timer (see Expiration and cascade below) independently; a nested Fork Address that receives regular settlements from its parent stays alive for the life of the parent.

Design advantages of nesting. Beyond the raw 128 × 128 capacity lift, the two-level structure yields three structural benefits that a flat 128-way split cannot provide:

• Privacy by composition. The root Fork Address publicly exposes only its 128 direct outputs. The leaf recipients behind each nested Fork Address are known only to the party who created that nested Fork Address. A publisher with 128 imprints publishes one root FORK code on its catalog page; the individual authors, editors, and illustrators within each imprint remain invisible to payers, to casual observers of the root, and to sibling imprints. The sensitive part of the distribution — who gets what share of an imprint's revenue — stays local to that imprint.
• Distributed setup and custody. Each nested Fork Address is created, paid for, and populated with FUND codes by its own creator, not the root creator. The root creator needs to know only the 128 intermediate FORK codes of the parties it routes to — never the (up to) 16,384 leaves behind them. Each sub-tree's creation fee, unresolvable-output accumulators, dust, and eventual cascade-on-expiration belong to the nested creator's own return chain: the root creator is never in custody of other parties' unresolved shares. Immutability at both levels means lifecycle edits (a label adding an artist, a programme adding a grantee) still require recreating the path from the root downward, but the setup-time division of responsibility stands.
• Natural batching without application code. Each level's 1000 BIT threshold is a batching window that costs nothing to maintain — no scheduler, no queue, no application-layer accrual logic. A 16,384-way distribution that would otherwise generate per-payment dust at every leaf instead pays out in natural chunks, with forced settlement (at 10 BIT per level) available as the explicit pressure-release valve for any party that wants to accelerate a specific branch.

A forced settlement may be triggered explicitly for 10 BIT, paid by the caller's wallet and burned. Forced settlement is open to any party — creator, output holder, payer, or uninvolved third party — so that a below-threshold balance can be flushed whenever there is a reason to do so, without a gatekeeper list. Typical uses are closing an accounting period, releasing a staggered leg before a publication event, or unblocking a leaf recipient whose share is stuck in a partially-filled nested Fork Address. The 10 BIT fee (ten times the platform burn on a 1000 BIT at-threshold settlement) discourages casual or adversarial trigger pulls while remaining trivial for any party with a legitimate reason to flush. Forced settlement applies at the level at which it is invoked: triggering a settlement pass on a parent Fork Address does not force its nested Fork Addresses to settle, and vice versa; each Fork Address in a two-level tree is flushed independently, and a caller who wants a full cascade through both levels pays 10 BIT at each level they wish to force.

Claiming an unresolvable output

The holder of an unresolvable FUND code — whoever the Fork Address creator delivered it to — claims it through the ordinary §5.9 retroactive-binding flow: they present the FUND code alongside their own Wallet Code to the service, which binds the FUND code to the claimant's wallet with no prior reservation check (see §5.9, FUND code lifecycle and retroactive binding). From the moment of binding, inbound transfers to the FUND code resolve to the claimant's wallet in the normal way, and the Fork Address's next settlement pass releases the accumulated share to them.

Because the FUND codes used for unresolvable outputs are generated client-side by the Fork Address creator, the creator retains knowledge of the code and can at any time bind an unclaimed FUND code to their own wallet, reclaiming any accumulated share. This is the creator's operational recourse when a recipient never materialises. It is not a protocol-level reversal; it is the ordinary §5.9 binding flow invoked with a code the creator already holds.

Transferring a share via disassociation

A Fork Address's output list is immutable, but the wallet bound to each FUND output is not. A holder may disassociate the FUND code from their wallet — authenticated by their Wallet Code, per §5.9, FUND code lifecycle and retroactive binding — and deliver the now-unbound code to an incoming holder, who binds it to their own wallet in the ordinary claim flow. The beneficiary behind each Fork Address output can therefore rotate across holders over the life of the Fork Address, even though the output list itself — the FUND codes and their share weights — never changes. This is the mechanism by which share-based royalty pools, content registries, and revenue splits support secondary transfers without the Fork Address being touched.

Already-settled amounts remain in the outgoing holder's wallet; shares that accrue between disassociation and the incoming holder's rebinding accumulate in the Fork Address's per-output accumulator (exactly as for any unresolvable output) and are released to the incoming holder at the next settlement after their binding. Neither the Fork Address's share weights nor its output list are affected.

The same mechanism makes primary allocation frictionless. A common setup pattern: a publisher creates a Fork Address whose outputs are N FUND codes, binds all N codes to the publisher's own wallet at the moment of Fork Address creation (via the ordinary §5.9 generate-and-bind flow, reserving the shares en bloc), and subsequently delivers each share to its intended holder by disassociating the corresponding FUND code and delivering it through any off-protocol channel. Each holder binds the received code to their wallet and begins receiving their share. Secondary transfers follow the same pattern indefinitely: the current holder disassociates, hands the code to the incoming holder, and the incoming holder binds. The Fork Address is agnostic to all of this — it sees an output's wallet binding change state and settles accordingly.

Expiration and cascade

A Fork Address's effective expiration is last_activity + T, where T is the term chosen at creation and last_activity is the timestamp of the most recent inbound or outbound transaction. Any activity — an inbound payment, a settlement outbound, a forced settlement, or the accumulator release that follows an unresolvable-output claim — resets the timer. A Fork Address that is actively routing payments does not expire; it expires only when it has been idle for its full term. A creator or any output holder can therefore extend a Fork Address indefinitely by sending a token amount to it periodically; the paid term T is the worst-case idle tolerance, not a hard cap on total lifetime.

The dominance rule (§5.8) does not apply to Fork Addresses. The return wallet and term are fixed at creation by the creator's choice and are never rewritten by inbound credits, regardless of amount. This exception mirrors the Demo Wallet case (§5.8) and for the same reason: a Fork Address holds other parties' accumulating shares as well as the creator's residual dust, and a large inbound payment must not let a third party capture the return commitment.

On expiration, the standard cascade of §5.8 applies: the Fork Address's remaining balance — residual dust plus every unresolvable output's accumulator — transfers to the creator's return wallet, or, if that wallet has itself expired and cascaded, to whichever wallet the return reference now points to under §5.8 step 1. A FUND code left unresolvable on an expired Fork Address remains bindable as a §5.9 Receive Address on a wallet; the binding has no effect on the expired Fork Address (no further settlements occur), but the FUND code itself is not invalidated.

What a Fork Address cannot do

• A Fork Address cannot host FUND Receive Addresses of its own (§5.9 excludes Fork Addresses from the list of FUND-hosting wallets).
• A Fork Address cannot host AUTH tokens (§5.10 excludes Fork Addresses from the list of AUTH-issuing wallets).
• A Fork Address output may target another Fork Address, but nesting is limited to one level: the nested Fork Address's own output list must contain no FORK outputs, and the service verifies this at creation of the parent. A FUND output must still bind to a wallet capable of hosting FUND addresses, which excludes AUTH tokens and GIFT vouchers.
• A Fork Address cannot be modified after creation.
• A Fork Address cannot be spent by its creator through any channel other than settlement to the configured outputs, a reclaim via binding an unresolvable FUND to the creator's own wallet, or cascade at expiration.

Fee treatment

Inbound transfers targeting a Fork Address follow the fee matrix of §6.6 by transaction type, exactly as for any other destination: a peer-to-peer transfer pays the 0.1% platform burn; a service or content payment pays the full 2.1% at the moment of payment. Settlement outbound to each output — whether a bound FUND Receive Address or a nested Fork Address — is a peer-to-peer transfer paying the 0.1% platform burn per output; across a two-level tree the burn is paid once at each level on the amount settled at that level. The creation fee is a separate flat burn per the schedule above. A forced settlement is a separate 10 BIT flat burn on the caller's wallet, charged per Fork Address at which settlement is forced. The fee matrix of §6.6 is extended with dedicated rows for these Fork-Address-specific events.

5.12 Service payment finality

BIT service payments settle on the ledger at the moment of transfer: the payer's balance is reduced and the receiving inventory's balance is increased. Settlement is independent of whether the underlying service is subsequently delivered successfully.

The Bitcash system does not track service delivery. It is a payment engine, not a service-performance registry. It has no awareness of whether a video streamed without error, a download completed, a file transcoded correctly, or an API call returned a valid response. Recording such outcomes — and handling their consequences — is the responsibility of the service provider that accepts BIT as payment: the Operator for its own services, or a Reseller for services on its own platform.

Where a service provider determines that it has failed to deliver a service for which BIT was already paid, the remedy is handled in the provider's own systems, not by returning BIT. Two reasons:

1. Issuance discipline (§5.1). The Operator may not transfer BIT to a non-Operator party except by sale; refunding BIT from inventory for a failed service would be a non-sale outflow from allotment-sourced inventory and is not permitted.
2. No protocol-level reversal. Transfers that have settled on the Bitcash ledger are final. There is no chargeback or reversal mechanism, in line with the analogous rule for AUTH-authorized debits (§5.10).

The intended remedy pattern is a service-level credit ledger maintained by the service provider, independent of Bitcash. When the provider's systems register a failed delivery, the provider records a credit against the affected user — keyed to the user's Wallet Code, account, session, or any other identifier the provider controls — in its own internal ledger. Subsequent eligible requests from that user are fulfilled against this internal credit instead of making a new call to the Bitcash service, until the credit is exhausted. No BIT moves, and the Bitcash payment path is not re-engaged.

Where applicable consumer law obliges a service provider to refund the monetary price paid, the refund is issued as an EUR refund through the original payment provider used at the point of sale. No BIT is transferred, and §5.1 is not engaged.

Economically, a BIT service payment is therefore payment for the service provider's best-effort attempt to deliver the service. Successful delivery is a service-provider obligation settled outside the Bitcash ledger.

5.13 Ledger integrity and signed transactions

Because the Operator holds the ledger, a wallet holder who later contests a balance, a charge, or the presence of a specific debit would — in the absence of any other mechanism — be relying entirely on the Operator's own records. To make such disputes tractable, every transaction appended to a wallet's ledger is signed by the Operator at the moment of commit, and the signed form is exposed to the wallet holder so they can keep an independent, tamper-evident copy.

The signing scheme has three parts:

• Per-transaction Ed25519 signature. Each ledger row is signed by the Operator over the canonical byte string of the row's durable fields: the wallet identifier, the monotonic per-wallet sequence number (§5.10 already establishes the seq), the transaction type, the signed amount, the post-transaction running balance, the commit timestamp, the fee breakdown (see below), and — where applicable — the content path, content type, and the AUTH token through which the debit was routed. The signature is stored alongside the row and is returned by every ledger-read endpoint. The Operator publishes its Ed25519 public key at a well-known URL so any holder, counterparty, or arbiter can verify signatures offline.

• Implicit chain via the running balance. The signed row commits to the post-transaction balance. Because balance is a running sum of all prior signed amounts, any retroactive rewrite of earlier rows must preserve the running balance at every signed row thereafter. The signature over (seq, amount, balance) is therefore an attestation to the entire history up to and including that row, without a separate chain-hash field: a single unchanged signed row anchors everything before it. For this anchor to be sound every ledger row must be signed — including wallet-creation rows, fee-bearing rows, and administrative events — so there is no gap through which an Operator could shift value between rows while keeping later balances intact. Wallets enrolled in the optional privacy mode still record every row and still sign it; only the contentPath field is stripped before the row is written, so an auditor inspecting the signed ledger sees the financial flow and the coarse content category (tile, video-chunk, thumbnail, …) but cannot determine which specific resource the holder consumed. The integrity of the chain is therefore independent of whether privacy mode is on.

• Mirror-as-transparency. The wallet manager replicates signed rows into the holder's local storage on every sync, using the seq cursor to fetch only the delta since the last known position. Mirrored rows are never overwritten: if the Operator later returns a row at a given (walletKey, seq) whose signature differs from the locally stored signature, the manager surfaces the conflict as a fork-detection event rather than silently replacing the row. In effect, every holder's local cache is a transparency log of their own history. Once a signed row has been mirrored to any holder, it is outside the Operator's control — the Operator can no longer rewrite it without breaking a signature that the holder can produce on demand. Holders are encouraged to back up the local mirror, for the same reason they back up their Wallet Codes.

Fee visibility on the signed row

To make the fee structure (§6.4, §6.5, §6.6) auditable at the ledger level, and to give the signing scheme complete coverage of the wallet's cash flow, every fee-bearing row carries its fee breakdown as explicit columns on the same row rather than as separate ledger entries. A content payment or a peer-to-peer transfer therefore produces one signed row on the payer's wallet whose amount is the full gross deduction, and which additionally exposes a platformBurn column (the 0.1% that is burned) and an operatorFee column (the 2% credited to the Operator, zero on peer-to-peer rows). The corresponding credit row on the recipient's wallet carries amount equal to the net received, with its own platformBurn and operatorFee fields set to zero — fees are charged against the payer, not the receiver. Receive-address and AUTH-token issuance fees (§5.9, §5.10) likewise appear as their own signed rows, with the fee amount reflected in the row's amount field. The sum of amount over a wallet's rows therefore equals the net change to its balance by construction, and the per-row fee columns let a holder auditing their history reconstruct the gross and fee components of every transaction directly from signed data, without having to trust an aggregated summary.

What this does and does not prove

Per-row signatures with implicit chaining are sufficient to prove, against the Operator's own published key, that the Operator attested to the exact figures on every signed row at the moment of commit. The Operator cannot retroactively alter a balance, hide a debit, or invent a credit against a holder who holds the original signed row. Disputes about historical state therefore reduce to producing the signed row; the arbiter verifies the signature and the running balance arithmetic mechanically.

What this scheme does not by itself catch is equivocation — an Operator quietly maintaining two parallel signed chains for the same wallet and presenting a different view to different parties. Each chain is self-consistent, and the fraud surfaces only when two holders compare rows out-of-band and discover a seq at which their locally mirrored signatures diverge. The mirror makes this detection possible (because each holder has a verifiable signed copy to exchange), but the detection itself requires an out-of-band comparison. Stronger guarantees — for example, periodic publication of a (walletKey, latestSeq, latestSig) head to an external transparency log or an independent auditor — are natural extensions of the same scheme and may be introduced in later revisions without changing the per-row signature format.

6. Economic Model

6.1 The Founder's cost-offset mechanism

The financial arrangement between the Founder and the first Operator works as follows:

1. The Founder pays the Operator €25,000 per year for managing his archives and operating servers with his software installed.

2. The Founder purchases BIT from the Operator's webshop to access his own archives and services, like any other End User. This BIT expenditure is in addition to the annual €25,000 payment.

3. The Operator operates the servers, sells BIT to users (including the Founder), and collects BIT as micropayments for service access.

4. Half (50%) of all BIT revenue collected by the Operator — including revenue from the Founder's BIT purchases — is credited against the Founder's annual payment. This credit accumulates until the Founder's payable amount for that year has been reduced to €0.

5. Once the Founder's annual payment has been fully offset, the Operator keeps all remaining BIT revenue for that period.

6. The Founder never receives cash payments from BIT. The mechanism only reduces what he owes. If BIT revenue is low, the Founder still pays the full €25,000 (minus whatever credit accrued). If BIT revenue is high, the Founder pays nothing and the Operator retains the surplus.

6.2 Why this is fair

This structure is designed to be equitable for both parties:

• For the Founder: He is paying for a service (archive management and server hosting). As the software he created generates revenue for the Operator through BIT sales, it is reasonable that this revenue reduces his costs. He does not profit — he only pays less for a service he is already consuming.

• For the Operator: The Operator receives software at no license cost, receives BIT at no cost, and keeps all revenue beyond the Founder's cost offset. As usage grows, the Operator's revenue grows without bound while the Founder's benefit is capped at €25,000 per year.

• For users: The pay-per-use model means users pay only for what they consume. There is no subscription, no minimum commitment, and no data monetization. The micropayment structure keeps individual costs low while collectively funding the infrastructure.

6.3 Pricing of services in BIT

Service consumption is priced in BIT according to a Fee Schedule controlled by the Founder. The fee schedule defines the cost in BIT for each type of operation — for example:

• Asset Registry write operations: 1 BIT per kilobyte of payload (see: Asset Registry Whitepaper §13.1);
• Asset Registry read operations: Free, with a ceiling of 1 BIT per request if pricing is introduced in the future (see: Asset Registry Whitepaper §13.2);
• Other services: Priced per the Fee Schedule published at the bit.cash website.

The fee schedule is designed so that integrators and users can purchase BIT in advance at a known cost, securing guaranteed access at a predictable price. This removes the risk that pricing could be changed retroactively to an unacceptable level.

6.4 Internal ledger transfer fee

A fixed fee of 0.1% applies to each eligible BIT transaction on the internal ledger. This is a structural design parameter of the Bitcash system, not an illustrative example. The set of eligible transactions is defined in §6.6: broadly, the fee applies to peer-to-peer movements of BIT between holders (Gift Voucher creation, Demo Wallet creation, and Receive Address transfers) and to service/content consumption (End User → Reseller content payments, Demo Wallet → bound site spending, End User → Operator service payments). It does not apply to sales-for-EUR flows through the distribution chain, to the Founder → Operator allotment, or to the drain of a Gift Voucher into the recipient's wallet (which was already taxed at creation). The deducted BIT is burned (permanently removed from circulation), not credited to any account. The fee must be disclosed in the applicable fee schedule and terms of service.

Purpose

Because the platform fee is burned rather than accumulated, it creates continuous attrition in the circulating BIT supply. This attrition ensures that Operators — and any Resellers — must periodically request fresh allotments or purchase new inventory, keeping the Founder structurally relevant as the sole issuer of BIT. Since the Founder is the only party that can create BIT and the total supply is not hard-capped, there is no need to return fee BIT to the Founder; destroying it achieves the same economic effect more cleanly. This supports the system's broader goals: affordable micropayments, sustainable infrastructure funding, and independence from advertising, subscriptions, or speculative token appreciation.

Decay characteristics

Because the fee is proportional and applied on each transfer, the remaining value of a given BIT amount decreases exponentially. Starting from an amount of 1, the fraction remaining after n eligible transfers is:

R(n) = (1 − 0.001)^n = 0.999^n

The number of transfers required for the remaining fraction to fall to a target level R is:

n = ln(R) / ln(0.999)

The decline is gradual. For reference:

In practice, this means BIT can circulate through thousands of eligible transactions before the majority of its value has been burned away.

Why 0.1%

A substantially higher fee would shorten the useful transactional lifetime of BIT and conflict with its positioning as a low-cost prepaid micropayment instrument. A substantially lower fee would weaken the attrition effect. The rate of 0.1% is therefore adopted as a fixed design parameter. It must be reflected consistently in the technical implementation, this whitepaper, the fee schedule, operator documentation, and user-facing terms.

6.5 Operator fee

A 2% operator fee applies to each eligible service or content payment in which the Operator is not already a party — payments from End Users to Resellers for content, and services consumed at the bound site of a Demo Wallet. The full set of fee-bearing transactions is listed in the fee matrix in §6.6; critically, the operator fee does not apply to peer-to-peer transfers of stored value (Gift Voucher creation, Demo Wallet creation, or Receive Address transfers), which carry only the 0.1% platform burn. The deducted BIT is credited to the Operator's wallet. This fee must be disclosed in the applicable fee schedule and terms of service.

Purpose

The operator fee funds the infrastructure that all participants — including Resellers and their End Users — depend on. While the Operator covers its own costs through direct BIT sales to End Users (§5.2), Reseller-mediated activity generates load on the Operator's servers and network without the Operator receiving direct sale revenue. The 2% operator fee ensures that the Operator receives ongoing compensation proportional to actual transactional activity across the system.

Effect on Reseller economics

The operator fee applies specifically to service consumption: when an End User pays a Reseller for content (directly from their wallet or from a Demo Wallet at the Reseller's bound site), the platform fee (0.1%) is burned and the operator fee (2%) is credited to the Operator — a combined 2.1% deduction from the content payment. Sales for EUR are fee-free, and peer-to-peer transfers of stored value between holders (Gift Voucher creation, Demo Wallet creation, Receive Address transfers) carry only the 0.1% platform burn — they do not trigger the operator fee, because no operator service has yet been delivered. In a closed loop — where a Reseller sells BIT fee-free, End Users spend all of it on the Reseller's content, and each content payment flows back minus 2.1% — the Reseller's inventory gradually diminishes. This guarantees that Resellers must periodically purchase fresh inventory from the Operator, sustaining the Operator's revenue model even when BIT circulates primarily within a Reseller's ecosystem.

6.6 Fee applicability

Fees apply at the moment a transaction requires the Operator to actually deliver service infrastructure. Transfers of stored value between holders are cheap; service consumption funds the Operator. The three categories are:

Sales for EUR are fee-free. No BIT fees are charged on flows that bring BIT into circulation against EUR payment: the Founder → Operator allotment, Operator → End User direct sales, Operator → Reseller inventory sales, and Reseller → End User retail sales. The Operator's revenue on these flows is captured in EUR rather than in BIT fees. Each of these flows delivers the full purchased amount to the recipient.

Peer-to-peer transfers of stored value pay only the platform burn. Gift Voucher creation (§5.6), Demo Wallet creation (§5.7), and Receive Address transfers (§5.9) each incur only the 0.1% platform fee, burned. The 2% operator fee does not apply to these flows, because they do not consume any operator-delivered service — they simply move already-purchased BIT between holders' balances. Claiming from a Gift Voucher (draining the full balance into the recipient's wallet) is fully fee-free: the platform burn was paid at creation. This keeps peer-to-peer transfers cheap enough that a conference organizer can pre-fund a large Demo Wallet, a content creator can publish a Receive Address for tips, or an End User can gift BIT to a friend, all at negligible cost. All peer-to-peer paths cost exactly the same 0.1% regardless of which mechanism the parties pick, which closes the historical arbitrage in which repeatedly exchanging Gift Vouchers between the same two parties could sidestep the operator fee on direct transfers.

Service and content payments carry the full 2.1%. When an End User consumes content at a Reseller's site — whether paying directly from their own wallet or by drawing from a Demo Wallet at its bound site — the 0.1% platform fee is burned and the 2% operator fee is credited to the Operator. This is where the 2% operator fee actually applies: at the moment the Operator is called on to deliver infrastructure, not when value simply moves between holders' balances. Direct spending on an Operator's own service incurs only the 0.1% platform fee — the Operator is already the counterparty for the operator fee.

The fees fund infrastructure and create the supply attrition that keeps the Founder structurally relevant as the sole issuer of BIT.

The resulting fee matrix:

Whether a given fee is additive (charged on top of the transaction amount) or extractive (deducted from the delivered amount) may vary by transaction type and is defined in the fee schedule.

Separately from the proportional fees above, creating a Receive Address beyond the first on a given wallet incurs a flat 10 BIT burn fee per address (§5.9). This is a soft cap on address proliferation, not a proportional transaction fee, and it is not credited to any party — the 10 BIT is destroyed at creation, contributing to the same supply attrition as the 0.1% platform fee.

Cross-Operator transactions

In a federated environment (§8), the fee treatment depends on whether a cross-Operator transaction represents service consumption or pure value transfer.

A cross-Operator service or content payment — where an End User holding BIT under Operator A consumes content or services delivered by infrastructure under Operator B — is a fee-bearing service consumption. Both Operators are involved in the experience (A issued the BIT and supports the user; B delivered the service), so the service-payment fee schedule is doubled on the operator-fee side:

• 0.1% platform fee (burned — once, as this is system-wide);
• 2% operator fee to Operator A;
• 2% operator fee to Operator B.

The total overhead on a cross-Operator service payment is 4.1%. This reflects the real cost of both Operators' infrastructure and discourages fee arbitrage while remaining feasible for legitimate cross-Operator use.

A cross-Operator peer-to-peer transfer — a Gift Voucher, Demo Wallet, or Receive Address transfer that moves stored value from a wallet under Operator A to a wallet under Operator B without consuming any service — follows the peer-to-peer rule from the main §6.6 matrix and incurs only the 0.1% platform burn. Neither Operator has delivered a service at that moment, so neither collects an operator fee. The cross-Operator boundary crossing is an accounting event, not a chargeable infrastructure use.

The detailed mechanics of cross-Operator settlement — how accumulated cross-Operator consumption fees are netted between Operators, and whether such settlement transfers themselves carry additional fees — are defined in the federation addendum, not this whitepaper.

7. Compliance and Legal Posture

7.1 Prepaid payment services, not investment products

Bitcash provides prepaid digital payment services. BIT is a payment instrument — not an investment, security, savings product, or deposit. No party may promise appreciation, yield, or profit from holding BIT. The financial services provided through the Bitcash system are limited to payment processing, stored-value management, and transaction settlement for digital services and content access.

7.2 No cash redemption

BIT is not redeemable for fiat currency. The Operator does not offer cash-out facilities unless the parties execute a separate written amendment and confirm legal compliance.

7.3 Consumer protection

BIT is a prepaid service credit subject to applicable consumer protection laws. Each Operator is responsible for ensuring that its sale and distribution of BIT complies with applicable laws in each jurisdiction where it operates, including tax obligations, consumer rights, and any licensing requirements for prepaid value instruments.

7.4 Fraud and abuse controls

The Operator may freeze wallets and balances where required by law, court order, or where it reasonably suspects fraud, theft, or abuse. Reasonable logging and controls are maintained for investigation purposes while respecting privacy by design.

8. Federation

Federation is a mandatory feature of the Catalog/Bitcash ecosystem. Each licensed Operator runs its own servers running Catalog software, with its own BIT allotment and webshop, and accepts BIT issued by any other licensed Operator as payment for services delivered on its own infrastructure, subject to the scope and carve-outs described below. Mutual acceptance makes BIT a network-wide prepaid credit rather than a per-Operator credit, so an End User can consume services anywhere in the Catalog ecosystem from a single wallet.

Federation features:

• Are mandatory among licensed Operators as a condition of the license, subject to §8's scope limitation and jurisdictional carve-out;
• Are documented in this whitepaper and the BIT Issuance & Distribution Addendum, and may be elaborated by technical specifications;
• Must not imply cash redemption, transferability to fiat, or investment characteristics;
• Are paired with the mandatory settlement mechanism in §8.1 — an Operator cannot accept foreign-issued BIT and then refuse to settle out the resulting surplus.

Scope cap on BIT acceptance. Mandatory federation applies only to services within the Catalog ecosystem service catalog — digital content access, cloud services, storage, delivery, metered APIs, and related digital services delivered through the Operator's Catalog installation. An Operator shall not accept BIT as payment — whether foreign-issued or issued by itself — for any service outside that catalog. This boundary is load-bearing for BIT's non-e-money characterization under the "limited network / limited range of services" exemption (EMD2 art. 1(4)(k), PSD2 art. 3(k)(i)) on which §7.1 depends: because BIT is fungible across the federation, a single Operator accepting BIT for out-of-scope services would expose the entire ecosystem's BIT supply to a non-limited range of services, jeopardizing the exemption for every Operator.

Jurisdictional carve-out. An Operator may suspend acceptance of BIT issued by a specific counterparty Operator where acceptance would violate applicable law binding on the Operator — AML/sanctions listings, licensing constraints in the accepting Operator's jurisdiction, or a binding court order. A suspension under this carve-out must be narrowly tailored to the legal obstacle, documented in writing, and disclosed to the Founder on request. It is not a general opt-out from federation.

The Operator ID at position 2 of the Wallet Code format ({TYPE}-{operator}-XXXX-XXXX-XXXX-XXXX-XXCC) makes cross-operator flows unambiguous: each Operator's wallets are clearly scoped, and every service payment carries its issuing Operator on its face.

The settlement mechanism for federated cross-operator consumption is Receive Addresses (§5.9): each Operator publishes one or more Receive Addresses on its treasury wallet, and federated Operators use those addresses as the destination for settlement transfers. This keeps Operator Wallet Codes out of inter-Operator operational channels and gives each Operator a stable, durable settlement endpoint that can be rotated without exposing any bearer material.

8.1 Monthly inter-operator settlement

Over any period of federated activity, flows between Operators are rarely symmetric. If End Users whose wallets were issued by Operator A consume more services at Operator B's infrastructure than the reverse, Operator B's inventory wallet accumulates a surplus of foreign-consumption BIT — BIT that entered circulation through Operator A's webshop but has now been spent into Operator B's inventory. Without a settlement mechanism, that surplus would remain stranded in Operator B's inventory (and Operator A's circulating supply would deplete without replenishment), even though each individual service payment was legitimate.

Inter-operator settlement resolves this asymmetry on a fixed monthly cadence shared across the entire federation, through the following conventional-commerce mechanism:

1. Reconciliation. At the end of each calendar month, each participating Operator computes its net accumulated surplus of BIT attributable to foreign-user consumption — i.e., the BIT in its inventory that originated from service payments by End Users whose wallets were issued by other Operators, less any reciprocal consumption by its own End Users on those other Operators' infrastructure.
2. BIT transfer. Promptly after reconciliation, the surplus Operator transfers the reconciled quantity of BIT to the counterparty Operator via the counterparty's published Receive Address (§5.9). The BIT leg is unconditional: it follows from the mandatory-federation commitment (§8) between the Operators and is not withheld pending EUR payment. The transfer returns the BIT to the issuing Operator's inventory, replenishing its circulating-supply capacity.
3. Invoice. The surplus Operator issues a conventional EUR-denominated invoice to the counterparty Operator, priced at the platform-wide BIT retail price (§5.3) or at such other rate as the Operators have agreed in writing. The invoice is a normal commercial document: VAT-handled according to the Operators' respective tax obligations, paid by bank transfer or similar conventional means. EUR non-payment is a commercial matter between the Operators and is addressed through the late-payment remedy in the Addendum — it does not reverse or delay the BIT transfer in step 2.

Economically, this is the Operator → Operator wholesale counterpart of the Operator → Reseller sale in §5.4: BIT moves inventory-to-inventory against an EUR consideration, with no new BIT created and no BIT crossing into or out of circulation. It does not conflict with the issuance discipline (§5.1), because no non-sale outflow from allotment-sourced inventory to a non-Operator party occurs — both counterparties are Operators, and EUR consideration is exchanged.

Participation is binding. Settlement is not optional for Operators that have accepted foreign-issued BIT. An Operator that accepts BIT from another Operator's users (as mandatory federation requires, §8) undertakes the corresponding obligation to reconcile and settle. Invoices issued under this mechanism are due within 30 days of invoice date unless the Operators agree otherwise in writing. Where a counterparty fails to pay a settlement invoice within that period, the surplus Operator may (a) charge commercial late-payment interest at the statutory B2B rate applicable in its jurisdiction, (b) suspend further acceptance of BIT issued by the defaulting counterparty until the arrears are settled — with disclosure to affected End Users and to the Founder — and (c) escalate the matter to the Founder for resolution under the Main Agreement. A suspension for non-payment is a commercial remedy and is distinct from the jurisdictional carve-out in §8.

Disputes over the quantity, pricing, or classification of accumulated foreign-consumption BIT are resolved first between the counterparty Operators directly, referring to each party's ledger records. Protocol-level reversal is not available; settlement adjustments take the form of a netting entry or a corrective invoice in a subsequent cycle.

Fee treatment follows the peer-to-peer rule of §6.6: a settlement transfer between Operator wallets via a Receive Address incurs the 0.1% platform burn and no operator fee, matching the fee line "Operator → Operator (federation settlement, Receive Address)" in the fee matrix. The platform burn is borne by the transferring Operator as a cost of settlement.

The settlement cadence is fixed at one calendar month across the entire federation and is not subject to bilateral variation. A uniform cadence is a prerequisite for multilateral netting (below): if Operator pairs settled on different cycles, no common reconciliation moment would exist at which the full bilateral matrix could be netted.

Where the sum of net bilateral imbalances across three or more Operators would otherwise produce redundant invoicing and BIT movement, participating Operators may net multilaterally: each Operator computes its position against all others, and a single netting pass reduces the set of invoices and BIT transfers to the minimum required to zero every bilateral balance. Multilateral netting is an accounting optimization; it does not change the per-transfer fee treatment.

9. Trademark

Bitcash® is a registered trademark of Roberto Bourgonjen in the United States, the European Union, and the United Kingdom.

Licensed Operators may use the Bitcash mark only as expressly licensed under the Catalog Server and Client Software License Agreement and must follow any brand guidelines provided by the Founder.

10. Records, Reporting, and Audit

Each Operator maintains accurate records of:

• BIT received from the Founder (allotments);
• BIT sold to End Users;
• BIT sold to Resellers;
• BIT received as payment for cloud services;
• BIT received as operator fees;
• BIT resold to End Users;
• Outstanding End User and Reseller BIT liabilities;
• Total BIT burned via platform fees.

The Founder may request monthly summary reports and may audit BIT-related records once per year (with 14 days' written notice), with scope limited to BIT transactions, service metering, and fee schedule compliance.

11. Summary

Bitcash is a prepaid micropayment system designed for one purpose: to make independently developed digital services and content sustainably available to the public through licensed Operators.

The system operates at the intersection of software and financial services:

• As software: Bitcash comprises payment processing applications, wallet client software (desktop, mobile, browser), ledger and settlement server components, and data processing systems for recording and managing digital payment transactions.

• As financial services: Bitcash provides prepaid digital payment services — issuance of stored-value credits, wallet management, micropayment processing and settlement, balance accounting, and financial transaction infrastructure.

The key principles are:

1. Pay-per-use. End Users pay only for the server capacity they consume. No subscriptions, no data monetization, no advertising.

2. Responsible issuance. BIT is issued by the Founder in quantities that reflect actual server capacity, circulating supply, and demonstrated demand — preventing overselling and ensuring service quality.

3. Hierarchical distribution. BIT flows strictly downward — Founder → Operator → Reseller → End User. Only the Founder can create BIT; all other participants transfer from their own balance. This ensures accountability and prevents inflation at every level.

4. Cost offset, not profit. The Founder's only financial benefit is a reduction in the fees he pays for archive management and hosting. He does not receive income from BIT sales.

5. Operator-operated. The infrastructure is operated by licensed Operators (typically non-profit foundations), not by the Founder personally. Each Operator has its own revenue model and keeps all BIT revenue beyond the Founder's cost offset.

6. No speculation. BIT is a prepaid payment instrument — it buys server capacity, nothing more. It has no secondary market, no exchange listing, and no investment characteristics. The Bitcash financial services are limited to payment processing and stored-value management.

7. Privacy by design. The Bitcash wallet system uses bearer-style codes that do not require personal identification to hold or spend. Bearer Wallet Codes are held at rest inside the OS-level secret store by the Secure Desktop Wallet Manager (§3.4), never in plaintext. Public Receive Addresses (§5.9) let users accept inbound transfers without ever disclosing their Wallet Codes or their internal wallet state. Combined with the privacy-preserving architecture of Catalog.ID, End Users can transact and access services without surveillance.

The system is deliberately focused. It provides the payment software and financial services infrastructure needed to fund operational costs through the people who use the services, in amounts proportional to their usage, with a financial structure that is fair to all parties involved.

End of Bitcash Whitepaper.