BitPads: A Binary Protocol Built on Conservation Laws

Most communication protocols evolve incrementally—layered on top of older systems, shaped by compatibility constraints, and optimized for specific domains. BitPads takes a different route: it is designed from first principles, starting at the mathematical structure of information exchange itself.

At its core, BitPads asks a narrow but consequential question:

What is the minimum structure required to represent a meaningful exchange between entities?

The answer leads to a protocol that scales from a single byte signal to a fully annotated, multi-layered record—without changing its fundamental structure.

Repository

Source code and specifications: → bitpads https://github.com/babbworks/bitpads

The Core Idea

BitPads is a binary protocol family where every transmission begins with a single byte: the Meta byte.

That byte tells the receiver:

  • what type of frame follows
  • what fields are present
  • whether enhancements are active

This happens before any payload is read. There is no schema negotiation, no preamble scanning, and no ambiguity about how to interpret the data.

From that starting point, the protocol scales along a continuous spectrum:

Size Type Description
1 byte Pure Signal Heartbeat, ACK, status
4 bytes Anonymous Value Context-bound value, no identity
13–29 bytes Full Record Identity + value + optional metadata
22–28+ bytes BitLedger Frame Complete double-entry transaction

The structure does not change—only the attached components.

BitLedger: The 40-Bit Core

At the center of BitPads is BitLedger, a binary encoding of a complete double-entry transaction in:

40 bits (5 bytes)

This is not compression of an existing format. It is a direct encoding of the minimal information required for:

  • value
  • account relationship
  • direction
  • state flags

The key property: conservation is enforced structurally.

For any batch of records:

sum(flows) = 0

If this invariant fails, the protocol detects it immediately—before application logic runs.

The Problem It Addresses

Most existing systems for transmitting financial or resource-flow data fall into one of three categories:

1. Verbose Formats

  • JSON, XML
  • Large payloads
  • Require parsing and schema interpretation

2. Schema-Dependent Systems

  • Require external definitions
  • Coupled to specific implementations

3. Domain-Specific Protocols

  • Financial only
  • Industrial only
  • Not transferable across contexts

This leads to duplication: each domain rebuilds similar logic with incompatible formats.

BitPads takes the opposite approach: it encodes the shared algebra directly.

A Unifying Observation

Across domains, the same invariant appears:

  • Accounting → debits and credits balance
  • Electrical systems → current sums to zero (Kirchhoff’s current law)
  • Material systems → mass is conserved
  • Networks → packets must reconcile

These are not analogies—they are structurally identical.

BitPads encodes that invariant at the wire level, making it:

  • domain-agnostic
  • self-validating
  • consistent across systems

Protocol Layers

BitPads is organized into layered components, each optional and composable.

Meta Layer (BitPads Protocol)

  • Declares frame type and flags
  • Enables self-framing transmissions
  • Supports scaling from 1 byte to full records

Enhancement Sub-Protocol

  • Adds signaling via extended control bytes
  • Encodes flags like priority, acknowledgment, continuation
  • Supports compact symbolic communication (4 bits per symbol)

BitLedger Layer

  • Encodes the 40-bit transaction
  • Enforces double-entry structure
  • Provides intrinsic validation

Universal Domain Extension

  • Generalizes beyond finance

  • Applies to any conserved scalar:

    • energy
    • mass
    • data
    • obligations

The wire format remains identical. Only interpretation changes.

How Frames Are Built

A typical full transmission includes:

  • Meta bytes — frame declaration
  • Layer 1 — session header (identity, permissions, CRC-15)
  • Layer 2 — batch defaults (currency, scaling, precision)
  • Layer 3 — BitLedger records

Optional components (time, task, annotations) attach only when needed.

This results in a system where:

  • minimal transmissions remain minimal
  • complex transmissions scale without redesign

Error Detection Strategy

BitPads does not rely on a single checksum. It uses multiple layers:

1. CRC-15 (Session Level)

  • Covers session configuration
  • Detects burst errors up to 15 bits

2. Cross-Layer Redundancy

  • Flags duplicated across fields
  • Bit flips become detectable inconsistencies

3. Conservation Validation

  • Ensures flows balance
  • Detects missing or duplicated records

This combination catches errors that traditional checksums may miss.

Efficiency Characteristics

The gains are structural, not compressive.

Format Approx Size (100 transactions)
BitLedger ~512 bytes
Fixed binary ~3,000 bytes
CSV ~15,000 bytes
JSON ~80,000 bytes

There is:

  • no decompression step
  • no schema lookup
  • no variable-length parsing

Decoding is deterministic: fixed bit positions map directly to meaning.

Implementation Approach

The reference CLI is implemented in:

  • x86-64 assembly (NASM)
  • direct kernel syscalls
  • no runtime dependencies

Characteristics:

  • no heap allocation
  • stack-based buffers
  • deterministic execution

The CLI:

  • builds frames from command-line input
  • writes .bp binary outputs
  • supports file, stdout, and dry-run modes

Currently, it is encode-only.

Design Decisions Worth Noting

No Floating Point

Values are encoded as scaled integers:

N = A × 2^S + r

This guarantees:

  • exact representation
  • explicit rounding behavior
  • no silent precision loss

Self-Describing From the First Byte

The receiver can determine:

  • domain
  • structure
  • interpretation

after reading only the first byte (and a few following bits).

Zero-Cost Optionality

Features like:

  • time fields
  • annotations
  • signal slots

only exist when used. They do not inflate simpler transmissions.

Backward Compatibility

The protocol can emulate legacy control streams (e.g., telegraph-style control codes), while embedding richer semantics in unused bit space.

Current Status

Working:

  • Frame construction across all types
  • Layered encoding (Meta, Session, Batch, BitLedger)
  • Value encoding tiers
  • Time, task, and annotation fields
  • Multiple output modes

Incomplete:

  • Decoder implementation
  • Formal test vectors
  • Some spec inconsistencies (e.g., size ranges)
  • CLI usability features (help output)

Why This Matters

A Single Model Across Domains

Instead of separate systems for:

  • finance
  • industrial telemetry
  • resource tracking

BitPads offers one structure that applies to all.

Reliability in Constrained Environments

Designed for:

  • low-bandwidth links
  • high-error environments (e.g., space systems)
  • embedded and real-time systems

Structural Integrity

The protocol enforces correctness:

  • at encoding time
  • at transmission time
  • before application logic

Final Perspective

BitPads is not an incremental improvement on existing protocols. It is a redefinition based on a single invariant:

Every meaningful exchange between entities follows a conservation law.

By encoding that invariant directly, the protocol achieves:

  • compactness
  • generality
  • determinism

The result is a system that can represent anything from a heartbeat signal to a fully contextualized transaction—using the same underlying structure.