Ledger Model

This document defines the core ledger data model and invariants required for conformance.

Entities

Account

An account represents a balance-holding entity.

• Each account MUST have a stable identifier (account_id).
• Each account MUST declare a type from the account type registry.
• Each account MUST have a creation timestamp.
• Each account MUST maintain balances per unit of account.
• Each account MAY have a registered Public Key (Ed25519) for offline transaction verification.
• Each account MAY be navigable via a human-readable Alias (Financial Identity).

Transaction

A transaction represents an atomic state transition.

• Each transaction MUST have a stable identifier (transaction_id).
• Each transaction MUST record a type from the transaction type registry.
• Each transaction MUST record from_account_id, to_account_id, unit of account, amount, optional fee amount, and created timestamp.
• Each transaction MUST have a monotonically increasing sequence number.
• Each transaction MAY include a cryptographic signature verifying the sender's intent.

Liquidity Ad

A liquidity ad represents a commitment to exchange currencies.

• Each ad MUST specify base_currency and quote_currency.
• Each ad MUST specify an exchange_rate.
• Ads enable the Liquidity Routing protocol ("Financial BGP").

Entry

An entry (posting) represents a debit or credit for an account.

• Each entry MUST reference a transaction identifier.
• Each entry MUST record an account identifier, unit of account, amount, and created timestamp.
• Entries MUST be immutable once committed.

Units of Account

• Units of account MUST be explicit identifiers (ASCII uppercase letters and digits are RECOMMENDED).
• An implementation MUST support at least one unit of account.
• The reference implementation uses a single unit named QAZ.
• Implementations MAY support multiple units of account; when they do, balances and entries MUST be partitioned per unit.

Account Types

The base profile defines three account types:

• user: standard participant accounts.
• issuer: system account that debits for mint operations.
• treasury: system account that receives fee credits.

Implementations MUST support these types for conformance to the base profile. Implementations MAY define additional types in the account type registry.

Invariants

Implementations MUST enforce the following invariants:

• Double-entry balance: For every transaction, the sum of entry amounts across all accounts MUST equal zero.
• Atomicity: Either all entries and balance updates for a transaction are committed, or none are.
• Determinism: Given the same ordered inputs and initial state, the runtime MUST produce the same ledger state.
• Immutability: Committed transactions and entries MUST NOT be mutated.

Ordering and Sequencing

• The ledger MUST define a total order over committed transactions.
• The sequence value MUST increase monotonically and uniquely with each committed transaction.
• Entries MUST be associated with the sequence of the transaction they belong to, either directly or via derived ordering.

Balances

• Balances MUST be representable as signed 64-bit integers of minimal units.
• User accounts MUST NOT have negative balances after any committed transaction.
• Issuer accounts MAY have negative balances to represent issuance.