BitLedger Protocol

Balance is structural, not checked

The foundational commitment of BitLedger: a record that does not balance cannot be encoded. This is not validation that runs when you submit. It is a property of the encoding itself. The BitLedger format cannot represent a transaction where debits and credits fail to balance — the same way a correctly designed lock cannot be opened by the wrong key. The balance invariant is structural. Every release must preserve this, and no future extension may introduce a partial-validity state where an unbalanced record might slip through.

The Pacioli commitment

Luca Pacioli formalized double-entry bookkeeping in 1494 as a structure in which a record cannot lie without revealing the lie. Debit and credit are not moral categories — they are structural positions. BitLedger encodes this same invariant at the binary wire level, five hundred and thirty years later. Every release of BitLedger must deepen the fidelity to this lineage, not depart from it. New features that require weakening the balance invariant, introducing optional fields that compromise structural completeness, or allowing records that require external context to validate are not compatible with this commitment.

Audit trail by construction

A BitLedger record preserves the complete transaction by construction. There is no separate audit log, no secondary record, no external ledger required to reconstruct what happened. The encoding is self-describing: account, amount, direction, timestamp, and the structural relationship between entries are all present in the payload. An auditor with the specification document can decode any BitLedger record without access to any external system. Every release must maintain and extend this self-describing property.

Lean enough to travel anywhere

Financial records must coordinate across constrained channels — satellite links, SMS, intermittent connections, air-gapped environments. BitLedger is designed so that a complete, auditable double-entry transaction can travel as a compact binary payload over any channel that carries bits. The encoding does not assume a database on either end. It does not require a persistent connection for delivery confirmation. It does not depend on a central authority to validate what was sent. Each release must be evaluated against the minimum-channel assumption: does this change make the payload larger without proportional gain in expressiveness or structural integrity?

Interoperability with the double-entry ecosystem

BitLedger is designed for interoperability with hledger and the broader plain-text accounting ecosystem. BitLedger encodes what hledger stores — it is a compact binary transport for records that hledger can natively represent. This relationship is a commitment: each release must maintain or improve the fidelity of the round-trip between BitLedger encoding and hledger-compatible plain-text format. BitLedger is not a replacement for plain-text accounting. It is a transport that makes those records transmissible everywhere.

Open standard, no custodian required

BitLedger is an open standard. The specification is the standard; any developer may implement it; no license is required. The governance model follows BASICS: community review, documented migration impact for changes, explicit replacement for deprecated requirements, and public maintenance. The standard does not belong to Babb — it belongs to the community that implements and relies on it. Each release is a public document, version-controlled, with a complete changelog. No change is made silently.