Chapter 16: Commerce Account and Transaction System (CATS)

The Commerce Account and Transaction System (\(M_{\text{CATS}}\)) is a tax-funded public service that records ownership to support property rights which are protected by law under the Non-Aggression Principle (NAP). It is available to businesses and individuals for commercial and private use.

\(M_{\text{CATS}}\) encompasses:

• Recording ownership of assets like cars, boats, houses, works of art
• Monetary accounts
• Loans (both monetrary and other kinds of property)
• Purchases of goods and services by consumers
• Warranties
• Liabilities associated with delayed delivery of goods
• Escrow accounts

As a rules-based, fully mechanical and open-source software system, \(M_{\text{CATS}}\) would greatly strengthen the protection of property rights. By recording ownership, validating transactions, and preserving reliable evidence, it would help prevent disputes, make fraud and other forms of cheating more difficult, and reduce the cost and risk of commerce. It would be particularly beneficial to small businesses because it is provided as a public service without transaction fees.

Accounts

\(M_{\text{CATS}}\) records property ownership information in accounts.

An account is owned by a single person, and protected by secure login using the Identity System \(M_{\text{IS}}\).

There are accounts for different kinds of property. Every account has a unit defined at the time the account is created, and cannot be changed. For example a unit could be one milligram of gold, or one Rune (the unit of Central Bank currency), or 1 cent USD.

Accounts always record balances using non-negative integers. In other words they record a whole number of the account unit.

Account role

There are three account roles:

• Property: What the account owner owns.
• Claim: What another Person owes the account owner.
• Liability: What the account owner owes another Person.

Immutable properties of accounts

The following properties of an account cannot change:

• The owner: account ownership is not transferable.
• The role: Property/Claim/Liability
• The unit
• The account type and product category if any for CB accounts (G,R,B and C accounts)

Rune

Rune is the name used in the constitution for the smallest indivisible unit of Central Bank currency.

A state adopting the constitution can substitute any name for Rune.

Transfers

A transfer means a move of a positve amount between accounts such that no account ends up with a negative balance. The accounts must be compatible:

• They must have the same role: Property/Claim/Liability
• They must have the same unit
• For Rune property accounts they must comply with the CBPS

In general transfers must record:

• The time of the transfer
• The amount
• The FROM account and TO accounts

There are rules that must be met for a transfer to be permitted.

In most cases accounts record a full history of all transfers into or out of the account. Only C-accounts flagged as private allow for this information to be purged from \(M_{\text{CATS}}\).

An account transfer moves units between two compatible accounts. A CATS transaction may contain or link several account transfers and obligation operations. A purchase, for example, may transfer Runes, transfer ownership of property, and create a matched delivery claim and liability.

Loans

A loan has a broader technical meaning in CATS than in ordinary financial usage. In CATS, a loan exists whenever one Person owes another Person a quantity of property. The Person entitled to receive the property is the lender, and the Person required to provide it is the borrower. A loan is recorded by matching Claim and Liability accounts.

The lender owns the Claim account. The borrower owns the matching Liability account. Loan creation increases both balances equally. Loan repayment or discharge decreases both equally. A claim transfer changes the lender. A liability transfer changes the borrower. The underlying unit may be Runes, gold, products or an identified item.

Delayed delivery is treated as a temporary loan: after payment, the consumer is the lender, the seller is the borrower, and the purchased product is owed. If a courier assumes delivery responsibility, the borrower changes from seller to courier. Receipt by the consumer discharges the loan.

Loan creation

A loan is created as a Claim/Liability pair with the same account unit. The transaction to create a loan must:

• Reference a contract recorded in \(M_{\text{CATS}}\) giving the terms and conditions, including schedules for:
  • Interest on the loan
  • Repayment or discharge of the loan
  • Remedies available to the lender under default.
• Be issued by the owner of the liability account.
• Increase the nominated claim and liability accounts by the same positive amount

Loan repayments

There is an operation provided by \(M_{\text{CATS}}\) for repayment of loans which are in Rune units. This must be issued by the borrower and involves:

• A transfer of an amount of Runes from a nominated borrower account to a nominated sender account.
• A corresponding reduction of the balance of both the Claim and Liability accounts associated with the loan.

A loan repayment cannot exceed the remaining balance of the loan, and it cannot be blocked by the lender.

If the balance of the loan falls to zero after a loan repayment then the loan is discharged.

Loan interest

\(M_{\text{CATS}}\) supports a variety of schedules and mechanisms for allowing interest to be changed on a loan. Interest causes an increase in the balance of both the Claim and Liability accounts associated with the loan.

In cases where the interest schedule is unsupported then it must be issued by the owner of the Liability account. If they do not do where required by the loan contract then that may represent a breach of contract.

Property claim creation

For a Claim/Liability on property which is not in Rune units, there is an operation to increase the claim. This can only be issued by the owner of the Liability account. It causes a increase in the balances of both the Claim and Liability accounts by the same number of units.

Claim transfer

The owner of a Claim account can issue a transfer of a positive number of units to any other Claim account of the same unit. This works for account with both Rune and non-Rune units.

Liability transfer

The owner of a Liability account can issue a transfer of a positive number of units into their account from any other Liability account of the same unit. This works for account with both Rune and non-Rune units.

Property claim discharge

For a Claim/Liability on property which is not in Rune units, there is an operation to discharge the claim. This can only be issued by the owner of the Claim account. It causes a decrease in the balances of both the Claim and Liability accounts by the same number of units.

Warranties

A producer may provide a warranty on a product they sold to a consumer against defects for some period of time. A warranty is a voluntrary contract entered into at the time of purchase. CATS supports the recording of warranty contracts on purchased items. For this purpose it records:

• The time of purchase
• The time the product was received
• The warranty contract, which includes the time for which the warranty is given

Optional escrow purchases

For delayed delivery, the purchaser may either pay the seller immediately, creating an outstanding product loan, or commit the purchase price to a CATS escrow account. Escrowed property remains owned by the purchaser until the agreed release condition is satisfied, but cannot otherwise be transferred or spent.

When the agreed release condition is satisfied, CATS transfers the escrowed Runes from the purchaser to the seller and transfers ownership of the purchased product from the seller to the purchaser. If the purchaser does not yet have custody of the product, the same transaction creates a product loan in which the purchaser is the lender and the Person responsible for delivery is the borrower.

If the release condition is the purchaser’s confirmation of physical receipt, ownership and custody pass together, so ordinarily no product loan remains to be created or discharged. If release occurs on dispatch or verified courier handover, ownership passes before receipt and the product loan exists from release until delivery.

The purchaser places the agreed Runes into a locked escrow account. The seller receives proof that the full payment is committed and cannot be spent by the purchaser. The seller or courier delivers the product. The purchaser confirms receipt. CATS releases the Runes to the seller and discharges the product loan. If delivery fails under the agreed conditions, CATS returns the Runes to the purchaser.

An important parameter is the maximum delivery time.

The contract must specify what happens when the purchaser refuses or fails to acknowledge receipt. Otherwise a purchaser could receive the product and indefinitely block payment. CATS could accept verified courier delivery, allow an automatic release after a defined period, or route a disputed transaction to adjudication.

Old

The Central Bank remains the specialised monetary authority responsible for the fixed supply of Runes. Monetary accounts use CATS rather than a separate transaction system built solely for money.

• Node: a compute node of CATS with its own database and support for local atomic transactions.
• Central Bank: the authority responsible for Central Bank currency.
• Rune: the indivisible integer unit of Central Bank currency.
• Property, claim, and liability accounts: account roles independent of the kind of unit recorded, including Runes and securities.

One account model

Every account has exactly one owner, one role, and one kind of quantity. Its role is property, claim, or liability; its kind specifies what is counted. The two classifications are independent: a claim or liability may be measured in Runes, grams of gold, units of a Product, or an identified item. All accounts belonging to a Person are held on the same node. A Person may own many accounts, including multiple accounts representing the same kind. Let \(A\) be the set of accounts, \(P\) the set of Persons, \(N\) the set of nodes, and \(K\) the set of kinds represented by accounts. Define

\[ \begin{aligned} \operatorname{owner}&:A\rightarrow P, &\operatorname{node}&:P\rightarrow N,\\ \kappa&:A\rightarrow K, &b&:A\rightarrow\mathbb{N}_0,\\ \rho&:A\rightarrow \{\mathrm{property},\mathrm{claim},\mathrm{liability}\}. \end{aligned} \]

Here \(\operatorname{owner}(a)\) is the unique owner of account \(a\), \(\kappa(a)\) is its kind, \(\rho(a)\) is its role, and \(b(a)\) is its non-negative integer balance. The distinguished kind \(k_{\mathrm{Rune}}\in K\) represents Runes. A Central Bank currency account is a property account of that kind; a Rune-denominated claim or liability is not a currency balance. All quantities use integers. A divisible commodity is represented in a sufficiently small indivisible unit, just as Central Bank currency is represented in Runes.

A property account records what its owner owns, whether or not the owner has physical custody. A claim account records what another Person owes its owner. A liability account records what its owner owes another Person. A claim against a borrower is distinct from ownership of any particular property of that borrower unless the agreement also grants a security interest. Custody and possession are recorded separately; custody never changes ownership by itself. Each claim and its matching liability refer to the same obligation identifier, creditor, debtor, kind, quantity, and terms. A Person cannot spend a Rune claim as though it were Runes in a currency account.

Property is either identifiable or non-identifiable. Non-identifiable property consists of interchangeable units of a defined kind, such as litres of fuel or kilograms of a commodity. Identifiable property is a specific item or interest with a unique identifier, such as a vehicle, vessel, building, parcel of land, machine, share, or serialized consumer Product.

The custody records for an identifiable item form a single chain of committed handovers. Each handover names the item's identifier, its previous handover, its previous custodian, and its new custodian. Only one successor to the current final handover is valid. The new custodian named by that successor becomes the recorded custodian when the handover commits:

\[ \operatorname{custodian}(v) =\operatorname{recipient}\!\left(\operatorname{head}(v)\right). \]

A receiving node may not yet have received the latest proof, but this does not create a second valid custodian. The committed handover chain determines custody; the property account and ownership transfer records determine ownership. These may name different Persons.

The system records ownership, custody, possession, and security interests through distinct records and account roles. A Product is property offered or transferred in commerce, not a separate ledger category. A warehouse or courier holds custody of property without owning it. A lender has a claim against a borrower and holds a security interest in particular property only when the loan terms grant one.

Transfers and matched obligations

An atomic transaction changes accounts belonging to one Person. Different kinds may appear together: a purchase can debit the buyer's Rune property account, add the purchased quantity to the buyer's property account, and create a claim for its delivery. The seller's matching liability is recorded on the seller's node from the purchase proof. These linked local entries do not form one atomic transaction across both Persons.

The sender authorises a transfer out of a property or claim account. The Person who takes on a liability initiates its acceptance, or has authorised its creation under an earlier agreement. A liability cannot be assigned to an unwilling Person. Creation of credit adds a linked claim and liability; fulfilment, forgiveness, or other authorised discharge reduces both. Changing the debtor requires the incoming debtor's acceptance and the creditor's agreement, which may already be part of the original terms. Claims and liabilities are not new units of the underlying property.

Every quantity added to or subtracted from an account is a positive integer, and no resulting balance may be negative. An internal transfer between two accounts representing the same kind conserves that kind:

\[ b'(s)=b(s)-n, \qquad b'(d)=b(d)+n, \qquad n\in\mathbb{N}_{>0}. \]

A commercial transaction may pair changes of different kinds. The external credit of Runes is accepted only from proof of the corresponding committed debit. This preserves the fixed supply of Runes without requiring accounts owned by different Persons to change atomically. Interest and other changes to an obligation follow its accepted terms and use integer arithmetic and specified rounding rules.

Appendix D implementation

All accounts use the distributed implementation specified in Appendix D: Central Bank Implementation. Its algorithms are not intrinsically monetary: they maintain account balances and propagate committed records and proofs between nodes. Applying them to every kind of account provides the same horizontal scaling across many nodes and the capacity for millions of transactions per second.

Each Person is assigned to one node, which holds all of that Person's accounts. Each node serves many Persons and kinds. Product descriptions, receipts, shipment information, and other large evidence are stored separately from balance entries. A transaction identifies that evidence using a permanent identifier and cryptographic digest while the high-volume transaction path operates on compact integer balances and references.

Local atomic transactions

Atomicity is local to a node and to the accounts of one Person. A local transaction contains multiple monetary, property, claim, or custody entries and either appends all of them or none of them. It does not atomically alter the accounts of another Person or accounts held on another node. Messages and proofs propagate between nodes through the distributed mechanism in Appendix D, but they are not distributed transactions.

For a finite set of local entries \(T=\{e_1,e_2,\ldots,e_n\}\), the node commits \(T\) only if every entry is valid:

\[ \operatorname{Commit}(T) \Longleftrightarrow \bigwedge_{i=1}^{n}\operatorname{Valid}(e_i). \]

For example, a purchaser's node atomically debits the purchaser's Rune account, adds the purchased property, and, where delivery is later, adds a claim for delivery. The committed debit proves payment. Crediting the seller and recording the seller's matching delivery liability are subsequent local changes on the seller's node.

Commerce between Persons

Commerce between Persons is represented by linked local records. No transaction atomically debits an account owned by one Person and credits an account owned by another. A committed outgoing payment, its later receipt by the seller, and the transfer of property refer to the same unique purchase identifier \(x\).

When purchaser \(C\) accepts seller \(P\)'s authorised offer and pays an amount \(m\) for later delivery of quantity \(q\) of property \(u\), the purchase transfers ownership to \(C\), although \(P\) still has custody. The purchaser's node atomically records:

\[ \left\{ \operatorname{DebitRunes}(x,C,P,m), \operatorname{AddProperty}(x,C,u,q), \operatorname{AddDeliveryClaim}(x,C,P,u,q) \right\}. \]

The Runes are no longer available to the purchaser. CATS returns proof of the committed debit to the seller. The seller can rely on that proof without waiting for the seller's account to be credited. CATS subsequently and atomically credits the seller's Rune account, removes the sold quantity from the seller's property account, and records its delivery liability. The linked purchase proof prevents either side from recording the same transfer twice. For fungible property such as gold, the buyer owns the specified integer quantity and grade; a custodian's holdings must reconcile with the quantities it holds for owners, so the same gold cannot also remain the seller's available stock.

The monetary records and property records are linked by \(x\), but each Person's accounts are changed only by a local transaction on that Person's node. No global transaction or global atomic state change is required.

An append-only history

The transaction history is append-only. Payments, receipts, shipments, deliveries, acknowledgements, returns, refunds, losses, and corrections are new transactions referring to earlier transactions. They do not erase or alter the earlier records. If \(t_n\) is the next valid transaction, the derived state is

\[ S_n=\operatorname{apply}(S_{n-1},t_n). \]

A refund is a new monetary transfer in the opposite direction. A Product return is a new Product transfer. The original purchase and delivery remain visible in the history, and the net position is calculated from the original and compensating transactions:

\[ \operatorname{NetPayment}(x) =\operatorname{Payments}(x)-\operatorname{Refunds}(x), \] \[ \operatorname{NetProductReceived}(x,p) =\operatorname{ProductsReceived}(x,p)-\operatorname{ProductsReturned}(x,p). \]

A purchase at a shop counter

Alice buys two tins of tomatoes from a supermarket for 10 Runes, ignoring tax. The tins are non-identifiable units of the supermarket's recorded tomato stock. Alice has Rune account \(A.m\) and property account \(A.p\). The supermarket has Rune account \(S.m\) and stock account \(S.p\).

The cashier scans the two tins on the supermarket's checkout terminal. The terminal creates purchase \(x\), stating the stock kind, quantity two, price 10 Runes, the supermarket's receiving account, and the supermarket's signed promise to hand over the tins. Alice sees those details on the checkout display or her telephone and authorises the purchase with her payment device.

1. Alice's CATS node verifies her authorisation and available balance. In one database transaction it subtracts 10 from \(A.m\) and adds two tins to \(A.p\). She now owns the tins. Either both changes commit or neither does.
2. The checkout terminal receives signed proof of that commit and displays payment accepted. This committed debit establishes payment. The cashier does not wait for \(S.m\) to be credited before handing over the tins.
3. Using the debit proof, CATS performs one database transaction on the supermarket's node: it adds 10 to \(S.m\) and subtracts two tins from \(S.p\).
4. The cashier places the tins in Alice's possession.

Alice performs no separate receipt confirmation. Her single authorisation approves the displayed purchase, including both payment and immediate acquisition of the two tins. The cashier's ordinary act of handing over the goods follows the payment-accepted indication on the checkout terminal.

Every database transaction above is local to one node and changes only accounts belonging to one Person. Purchase identifier \(x\) and signed commit proofs connect the local transactions. There is no database transaction spanning Alice's node and the supermarket's node.

Delivery of an identifiable Product by a courier

Ben pays for a television identified by serial number \(v\). The purchase record \(y\) identifies Ben, the retailer, the model and serial number, the price, the delivery address, and the terms of delivery. Ben's property account records ownership of \(v\), and his claim account records the retailer's obligation to deliver it. The retailer initially retains custody, not ownership.

At the retailer's warehouse, a worker scans the serial number and the courier scans the parcel label with a handheld terminal. The courier sees the item, destination, declared replacement value, and delivery terms. By accepting the handover, the courier initiates its own liability to deliver \(v\) or, if it is lost, pay its full replacement cost. The courier's commitment is the value it provides in exchange for custody; it is not a payment for or purchase of the television. The retailer releases custody only against proof of that commitment. The linked local records move custody and, under the purchase's default delivery terms, substitute the courier for the retailer as the debtor of Ben's delivery claim. Ben's ownership remains unchanged. The signed handover is the predecessor of any later custody transfer involving \(v\). Other agreed terms can allocate the risk differently.

At Ben's address, the courier scans the parcel again. Ben's telephone displays the retailer, purchase number, Product, serial number, and courier. Ben compares those details with the parcel and takes physical delivery while authorising receipt on his telephone. Ben's node verifies his ownership, the delivery claim, and the courier's current custody proof. It then records receipt and discharges the delivery claim in one local transaction. His property balance does not change because he already owned the television.

CATS returns signed proof of Ben's committed receipt to the courier's handheld terminal. The terminal displays that delivery has been accepted. Using that proof, the courier's node removes \(v\) from its custody record and discharges its delivery liability in one local transaction. The proof cannot be used twice. Receipt establishes delivery of the recorded item; a dispute about damage or incorrect goods remains subject to evidence and the purchase terms.

Ben's receipt commit identifies Ben as the current recorded custodian of \(v\). The proof names \(y\), \(v\), the courier, Ben, and the preceding custody record. A second handover from the same predecessor is invalid. If another courier or warehouse handles the parcel, the incoming custodian accepts the corresponding liability before the outgoing custodian is released. Each accepted handover has its own linked local commits and signed proofs.

The party controlling custody bears the default risk of loss. For valuable property such as gold, full replacement liability gives couriers a reason to use appropriate security and charge for its cost and risk. Insurance can fund a loss without by itself releasing the courier from its obligation to the owner. The same rules apply to an integer quantity of fungible gold as to an individually identified television.

The append-only records produce derived purchase states such as created, payment committed, payment received, handed over, in custody, delivered, received, returned, or refunded. These are calculated views, not mutable transaction records.

Loans and other credit

CATS records a loan of Runes as a transfer of existing Runes from the lender's currency account to the borrower's currency account, together with a lender's claim and the borrower's matching liability. The claim is an asset of the lender but is not spendable currency. Creating the loan does not create Runes. Each side's records are committed on that Person's node and linked to the same agreement and transfer proofs.

The agreement specifies the principal, any interest rate, integer rounding rule, due dates, and allocation of partial payments. Interest creates matching changes to the claim and liability under terms both Persons accepted. A repayment transfers actual Runes back to the lender and reduces both outstanding balances. Full repayment, forgiveness by the lender, or another authorised discharge closes the obligation through new append-only entries. The same account roles can represent an obligation to return other property; a rental also specifies rights of use, custody, duration, and return conditions.

Commercial records and inventory

Businesses already need records of purchases, sales, stock, shipments, deliveries, returns, warranties, and losses. The common system formalises these records and creates and reconciles many of them automatically. For each Product \(p\) over a period \([u,v]\), it tests

\[ I_p(u)+Q_p^{\mathrm{received}}[u,v] =Q_p^{\mathrm{transferred}}[u,v]+Q_p^{\mathrm{other}}[u,v]+I_p(v), \]

where \(I_p(t)\) is inventory at time \(t\), and \(Q_p^{\mathrm{other}}\) comprises separately recorded productive use, loss, destruction, and other disposals. Batch transactions remain possible: each batch contains itemised entries whose integer quantities reconcile with its total.

Property rights and the NAP

Applying the Non-Aggression Principle to a dispute often requires evidence of who owned a Product, whether its transfer was authorised, who had custody of it, and whether it was lost, damaged, stolen, or delivered. The common ledger preserves evidence about these facts and makes fraud, theft, unauthorised disposal, and breach of a property agreement easier to establish. Its matched claims and liabilities also show who accepted responsibility for another Person's property at each handover, allowing the default risk of loss to follow custody.

It records commodities and inventory as well as individually identified vehicles, vessels, land, buildings, machinery, securities, and serialized consumer Products. It also represents liens, leases, shared ownership, and other interests without confusing them with physical possession or custody.

Imports and foreign-currency settlement

The common transaction system connects a foreign purchase, currency conversion, shipment, custody, receipt into commercial inventory, taxed retail payment, and transfer to a purchaser. These records help distinguish the foreign acquisition cost of a Product from an import retailer's markup:

\[ \operatorname{ForeignCurrency}(p) \leq \operatorname{VerifiedForeignAcquisitionCost}(p). \]

The markup remains Runes in the retailer's R-account. It cannot be represented as acquisition cost and converted through the Product's settlement records. Conflicting records and suspected false evidence remain available for audit.

Securities and exchanges

The same accounts represent shares and other transferable property interests. Private exchanges operate competing order books while monetary and securities transfers settle as linked, locally atomic, append-only transactions. A securities account supports issuance, cancellation, ownership transfer, distributions, voting, stock splits, mergers, buybacks, secured lending, and inheritance without requiring a separate ledger technology.

Privacy

Using one account and transaction system must not make its information generally cross-searchable. The ledger must not expose a Person's purchases, possessions, portfolio, counterparties, or commercial activity to another Person. Access remains limited to the parties to a transaction and a public service exercising a specifically authorised function.

Other Persons verify a necessary proposition—for example, that a seller owns an asset and has sufficient units to transfer—without learning the owner's other property or transaction history. Separation of information, selective disclosure, cryptographic commitments, and zero-knowledge proofs provide verification without publishing the underlying records.

CATS and property ownership

CATS cannot itself own property or hold assets or liabilities.

The function of the public service

The public service maintains the common implementation, validates formal rules, protects private information, and supplies evidence of recorded events. It does not decide what Products should be made, set prices, choose trading partners, or operate a monopoly marketplace.

One distributed implementation therefore supports money, inventory, delivery and receipt, proof of ownership, property rights, credit, securities, and tax reconciliation. Its unity lies in integer property, claim, and liability accounts, linked local atomic transactions, append-only history, and the distributed algorithms of Appendix D; its different applications arise from the rules governing each kind of unit.