BitLedger: A 40-Bit Protocol for Financial Transactions

Most financial data formats were not designed from the ground up—they evolved through layers of abstraction, readability requirements, and system compatibility. The result is predictable: large payloads, heavy parsing, and application-level enforcement of accounting rules.

BitLedger takes a different approach. It defines a financial transaction at the bit level, encoding a complete double-entry record in:

40 bits (5 bytes)

No compression. No schema lookup. No ambiguity. Every bit has a fixed meaning.

Repository

Source code and full specification: → bitledger https://github.com/babbworks/bitledger

What BitLedger Is

BitLedger is a binary-native financial transmission protocol designed from first principles.

It encodes:

  • both sides of a transaction (debit and credit)
  • value and quantity
  • accounting classification
  • settlement status
  • precision and rounding metadata

…all within a fixed 40-bit structure.

The defining property is that double-entry accounting is enforced at the encoding level, not left to application logic.

Why This Matters

A direct comparison highlights the difference:

Format Size (100 transactions) Parsing Accounting Logic
BitLedger ~512 bytes None (fixed positions) Built-in
Fixed binary ~2–5 KB Schema required No
CSV ~10–20 KB Required No
JSON ~50–200 KB Required No
XML ~200 KB+ Required No

The reduction is structural:

  • no string parsing
  • no field delimiters
  • no schema interpretation

Decoding is deterministic: read bits → interpret directly.

The 40-Bit Record Structure

Each transaction is split into two logical sections:

1. Value and Flags (Bits 1–32)

  • Encodes the numeric value

  • Includes flags for:

    • rounding
    • direction
    • status
    • quantity presence

2. Accounting Classification (Bits 33–40)

  • Defines the account relationship

  • Includes:

    • account pair type
    • debit/credit direction
    • settlement status
    • completeness/continuation

This separation allows the protocol to represent both what happened numerically and what it means in accounting terms.

Account Relationships as First-Class Data

Instead of treating accounts as external labels, BitLedger encodes their relationship directly.

Examples:

  • Operational Expense ↔ Asset
  • Income ↔ Liability
  • Asset ↔ Equity
  • Correction / Netting
  • Compound continuation

This removes ambiguity and ensures consistency across systems.

Value Encoding

BitLedger uses a split integer encoding:

N = A × (2^S) + r

Where:

  • A = primary value component
  • S = split factor (from session settings)
  • r = remainder

This allows every integer in the range:

0 → 33,554,431

to be represented exactly.

Scaling

A separate scaling factor extends this to real-world values:

Scaling Max Value (2 decimal places) Step Size
×1 $335,544.31 $0.01
×1,000 $335M $10
×1,000,000 $335B $10,000
×1,000,000,000 $335T $10M

Maximum theoretical value:

~$33.5 quadrillion

No Floating Point

All values are:

  • integer-based
  • precisely scaled
  • explicitly rounded when needed

Rounding is encoded using dedicated bits:

Bits Meaning
00 exact
10 rounded down
11 rounded up
01 invalid (reject)

There is no silent precision loss.

Protocol Layers

BitLedger operates within a structured transmission model:

Layer 1 — Session (8 bytes)

  • sender identity
  • permissions
  • CRC-15 checksum

Layer 2 — Batch (6 bytes)

  • currency
  • scaling factor
  • decimal precision

Layer 3 — Transaction (5 bytes)

  • the 40-bit record

Control Records (1 byte)

  • parameter updates
  • acknowledgments
  • batch boundaries

Each layer is transmitted only when needed.

Error Detection

BitLedger combines multiple mechanisms:

1. CRC-15 (Session-Level)

Detects burst errors in session configuration.

2. Cross-Field Validation

Certain bits must match across sections. If they don’t, the record is invalid.

3. Structural Invalid States

Some bit patterns are explicitly illegal (e.g., invalid rounding flag combinations).

4. Accounting Invariant

At the batch level:

sum(debits) = sum(credits)

If this fails, the dataset is invalid—regardless of bit integrity.

Compound Transactions

Multi-step events are supported using a continuation marker:

  • initial record: partial
  • continuation record: completes the transaction

A special account pair code (1111) links records together.

This allows:

  • multi-leg transactions
  • grouped accounting events

without increasing base record size.

Control Records

Control records use a distinct leading bit and provide:

  • scaling updates
  • currency changes
  • batch closing
  • acknowledgments
  • compound grouping

All in a single byte.

Human Readability

Despite being binary, BitLedger can render into standard accounting format:

DEBIT    Operational Expense      1,247.50
CREDIT   Accounts Payable         1,247.50

This makes it suitable for:

  • machine transmission
  • human auditing

without loss of fidelity.

Implementation

The reference implementation is a Python CLI tool using only the standard library.

Capabilities:

  • encode transactions
  • decode records
  • simulate sessions
  • manage profiles
  • audit rounding behavior

Example:

bitledger encode
bitledger decode 04D00518 14
bitledger simulate --profile retail

Design Characteristics

Fixed Size, No Overhead

  • every transaction is exactly 5 bytes
  • no optional fields in the core record

Self-Contained Semantics

  • no external schema required
  • interpretation is built into the bits

Deterministic Parsing

  • no delimiters
  • no variable-length fields
  • no ambiguity

Low Resource Requirements

Designed for:

  • embedded systems
  • low-bandwidth links
  • constrained devices

Why It’s Different

Most systems treat accounting as:

data + rules applied later

BitLedger encodes it as:

data that already obeys the rules

This shift has practical consequences:

  • invalid states are unrepresentable
  • errors are caught earlier
  • systems become simpler

Final Perspective

BitLedger starts from a minimal premise:

What is the smallest possible representation of a valid accounting transaction?

The answer—40 bits—produces a system that is:

  • compact
  • precise
  • verifiable
  • portable

It does not optimize existing formats. It replaces them with a structure where correctness is intrinsic, not enforced after the fact.