BitLedger v3.0 · Design Note
Compound
Mode
The 1111 account pair code — normally a protocol error — becomes a continuation marker that links records into one logical multi-leg transaction.
Compound mode is a session-level permission flag. When it is off, 1111 in the account pair field (bits 33–36) is an unambiguous corruption signal. When it is on, 1111 is a valid continuation marker that binds the current record to its predecessor as part of one indivisible logical event.
Real-world transactions frequently require more than one accounting entry to be described completely. A retail sale simultaneously generates revenue and removes inventory. An engine firing simultaneously consumes propellant and creates a thermal load obligation. Without compound mode the protocol cannot enforce that both records post together — or not at all. With compound mode, the wire format enforces the link.
Session-level only: Compound mode cannot be activated per-record or per-batch in standard v2 operation. It must be declared in the Session Config Extension byte at session open. The per-batch toggle capability from v1 is available via a Category 1101 Context Declaration workaround — at a cost of 3 bytes per toggle versus 1 in v1.
Account Pair Field · Bits 33–36
The 1111 Continuation Marker
The account pair field occupies bits 33–36 of the 40-bit BitLedger Layer 3 record. It encodes one of 16 possible values. Values 0000 through 1101 represent the 14 defined standard account pairs. Value 1110 is the Correction/Void pair. Value 1111 is reserved — normally a protocol error — and becomes the Compound Continuation marker when compound mode is active.
The 1111 marker carries a single semantic instruction to the decoder: do not post this record independently. Link it to the record that preceded it. Post both together, or neither. When a 1111 record arrives, the decoder holds it against the pending compound group and waits for the group to close before any record in the group is posted.
Pair
Pair
Pair
Pair
Type
Type
lete
A 3-record compound transaction: an opening debit leg declares itself partial (completeness = 1, account pair ≠ 1111), a 1111 continuation follows (also partial if more legs are pending), and a final closing record (completeness = 0, account pair ≠ 1111) closes the group and triggers posting of all held records.
Bits 37–38 When Account Pair = 1111
Continuation Sub-Types
When the account pair field is 1111, bits 37–38 carry the continuation sub-type rather than their standard role as direction/status mirrors. Four sub-types are defined. The sub-type qualifies the nature of the link between the current record and its predecessor — whether it is a standard additional leg, an error correction, a reversal, or a cross-batch continuation.
| Bits 37–38 | Sub-type | Meaning |
|---|---|---|
00 ▾ |
Standard | Normal linked entry — next leg of the same event. COGS entry, contra, paired leg. |
Standard ContinuationThe most common sub-type. This record is the next required leg of the same economic or physical event that opened the compound group. The records share one logical identity and must post together. Example: Record A = Sale revenue recognised. Record B (1111, sub-type 00) = COGS debit. Both legs of one retail transaction. Bit Pattern1
1
1
1
0
0
·
1
Bits 33–36 = 1111. Bits 37–38 = 00. Bit 39 = completeness (0=close, 1=more). Bit 40 = reserved. |
||
01 ▾ |
Correcting | Error correction leg — this record corrects a specific error in the preceding record. |
Correcting ContinuationThis record directly corrects a field error in the preceding record. The compound group holds both the errored record and its correction. Neither posts independently. When the group closes the decoder applies the correction before posting the corrected value. Distinct from account pair 1110 (Correction/Void) which operates at the single-record level. This sub-type operates within a compound group. Bit Pattern1
1
1
1
0
1
·
1
Bits 37–38 = 01. This is the error correction leg of the compound group. |
||
10 ▾ |
Reversal | Full reversal — this record fully reverses the preceding record in the group. |
Reversal ContinuationThe current record is a full reversal of the immediately preceding record in the compound group. The sign of all value fields is inverted. The compound group holds both the original record and its reversal. When closed, both records post together, netting to zero for the reversed quantity. Used when a transaction must be partially unwound within the same posting cycle without losing audit trail of what was done. Bit Pattern1
1
1
1
1
0
·
1
Bits 37–38 = 10. Full reversal of the preceding group record. |
||
11 ▾ |
Cross-batch | Continuation spans a batch boundary — this record links to the prior batch's open compound group. |
Cross-Batch ContinuationThe rarest sub-type. A compound group that opened in a previous batch — whose records are already held by the decoder — is continued by this record in a new batch. The batch boundary does not close the group. The group identity from the prior batch is carried forward. Required when a long-running multi-leg transaction spans batch boundaries. The decoder must be stateful across batches when this sub-type is present. Bit Pattern1
1
1
1
1
1
·
1
Bits 37–38 = 11. Cross-batch continuation — decoder must carry group state across the batch boundary. |
||
Cross-layer validation note: In standard (non-1111) records, bits 37–38 mirror bits 29–30 as a cross-layer integrity check. In 1111 records these bits carry sub-type data instead. The cross-layer check does not apply to 1111 records. This is the specific weakening of error detection that compound mode ON introduces.
Layer 3 Bit 39
The Completeness Bit
The Completeness bit (Layer 3 bit 39) works in conjunction with the 1111 account pair to create unambiguous group boundaries. It is the primary signal the decoder uses to determine whether a compound group is open, ongoing, or closed.
When a standard record (account pair ≠ 1111) has Completeness = 1 (Partial), the decoder enters compound watch — it holds that record pending and waits for a 1111 continuation. When a 1111 record has Completeness = 0 (Full), the group closes and all held records post together.
The two bits interact across the four possible combinations to produce four distinct decoder actions:
| Completeness (bit 39) | Account Pair | Decoder Action |
|---|---|---|
0 — Full |
Any standard pair (≠ 1111) | Standalone record. Post immediately. |
1 — Partial |
Any standard pair (≠ 1111) | Enter compound watch. Hold record. Expect 1111 next. |
0 — Full |
1111 (Compound Continuation) | Group closed. Post all held records atomically. |
1 — Partial |
1111 (Compound Continuation) | Compound continues. Append to group. More 1111 records follow. |
Conservation check timing: In standard (non-compound) records the conservation invariant — debits equal credits — is checked per record. In compound mode the conservation invariant is checked per logical transaction, not per record. Each individual record in a compound group is permitted to be unbalanced. The balance check runs when the group closes (completeness = 0 on a non-1111 record). This is the correct behaviour: a sale record showing $499.90 of revenue is not balanced on its own; it only balances when the $499.90 COGS record is included in the same posting.
Full Bit-Field Traces
Worked Examples
Two worked examples showing compound mode in use: a financial payment split across three accounts, and an engineering power transfer between satellite nodes. Both use the same wire format. The semantic interpretation differs only in the account pair field and quantity type.
Financial Compound — Sale with COGS
A retail sale simultaneously generates revenue (credit to Op Income / Asset pair) and removes inventory (debit to Op Expense / Asset pair). These are one economic event that requires two accounting entries. Compound mode links them: either both post, or neither does.
Engineering Compound — Satellite Power Transfer
In the Universal Domain, a power transfer between satellites via a relay node requires three flow records: a debit from the source satellite, an intermediate relay node record, and a credit to the destination satellite. The same 1111 marker and compound mode permission apply. Only the semantic interpretation of the account pair field changes — here it encodes Universal Domain flow archetypes.
Layer 1 Session Config Extension Byte
Session Config Extension
Compound mode is activated by setting bit 4 of the Session Config Extension byte. This byte is transmitted once at session open, triggered when Layer 1 bit 12 (Session Enhancement Flag) is set or when the opposing convention is non-default. Once transmitted, the compound mode state is fixed for the entire session.
The Session Config Extension byte also carries nesting level, opposing convention, and the BitLedger block optional flag. All session-level configuration is read from this single byte at session open — the decoder builds its complete session picture in one step.
Lvl
Lvl
Conv.
Mode
Opt.
| Bit | Field | 0 = OFF | 1 = ON |
|---|---|---|---|
1–2 |
Nesting Level Code | 00 = no nesting (flat) | 01/10/11 = nesting depth |
3 |
Opposing Convention | Default (debit left) | Opposing convention active |
4 |
Compound Mode Active | 1111 is a protocol error (free sentinel) | 1111 is a valid compound continuation |
5 |
BL Block Optional | BL block required in every record | BL block may be omitted on some records |
6–8 |
Reserved | Transmit as 1. Receiving 0 in reserved bits = protocol error. | |
Architecture Decision
v1 vs v2 Tradeoff
In BitPads Protocol v1.0, compound mode was declared in the BitLedger Context Control byte — a per-batch control record triggered by the Value expect flag. In v2.0 this byte was removed. Compound mode moved to the Session Configuration Extension byte, making it a session-open declaration only.
The v1 per-batch byte allowed compound mode to be toggled on a batch-by-batch basis — ON for a batch containing sale+COGS pairs, OFF for the next batch of routine single-entry records. The v2 session-level flag is all-or-nothing for the session.
v1 — Per-Batch Control Byte (Removed)
The Four Tradeoffs
| Dimension | v1 Behaviour | v2 Behaviour | Net impact |
|---|---|---|---|
| Granularity | Per-batch toggle | Per-session only | Real constraint for mixed sessions. Most deployments unaffected. |
| Overhead | 1 byte per batch (even if compound unused) | 1 byte per session total | Net saving in most sessions. Overhead was universal in v1. |
| Flexibility | Higher — can toggle mid-session | Lower — all-or-nothing | Loss of per-batch error detection on non-compound batches in compound-ON sessions. |
| Decoder complexity | Higher — BL context spread across Layer 1 and per-batch ctrl byte | Lower — single read at session open | Cleaner decoder. Complete session picture from one byte position. |
Why v2 chose session-level: The v1 per-batch BL ctrl byte added 1 byte of overhead to every batch that contained Value records — whether compound mode was used or not. In sessions where compound mode was never needed (the majority of deployments), this was unconditional overhead on every batch. Moving compound mode to the Session Config Extension byte reduced this to one byte per session, paid once. The per-batch toggle capability is recoverable via Category 1101 for the deployments that genuinely need it.
Layer 2 Compound Prefix — Per-Batch Ceiling
The Layer 2 batch header carries the Compound Prefix (bits 46–47), which limits how many compound groups are permitted within a specific batch. This is a capacity ceiling, not a mode toggle — it operates even when session compound mode is ON. Setting bits 46–47 = 00 in a batch header forbids compound groups in that batch without changing session-level mode state.
1111 is a protocol error in this batch even if session compound mode is ON.
NACK is sent after the 3rd compound group closes within this batch.
NACK is sent after the 7th compound group closes within this batch.
No ceiling within this batch. All compound groups permitted.
Enhancement Sub-Protocol · Category 1101
Category 1101 Workaround
The per-batch compound mode toggling capability removed in v2 can be restored using the Category 1101 Context Declaration mechanism from the Enhancement Sub-Protocol. Category 1101 declares a session parameter update with a specified scope. By setting the scope to "next stream unit" (next batch) and the parameter to compound mode ON, the effect of the v1 per-batch toggle is reproduced within the v2 architecture.
The cost is 3 bytes (Meta byte + 2 declaration bytes) versus the v1 approach of 1 byte per batch. This 2-byte overhead is the direct cost of the v2 design choice — recoverable only for deployments that specifically need per-batch compound toggling.
Four-Scenario Comparison
The table below shows the four deployment patterns and their compound mode detection behaviour. The Category 1101 workaround (row 4) is the only pattern that achieves per-batch control with strong error detection on non-compound batches in v2.
| Scenario | Session Compound Mode | Batch Compound Prefix | 1111 Detection | Compound Records |
|---|---|---|---|---|
| Always-on compound session | ON | 11 (unlimited) | Weak — 1111 always valid | YES — all batches |
| Never compound (full off) | OFF | Any | Strong — 1111 always error | NO — entire session |
| Prefix 00 on simple batches | ON | 00 on simple / 11 on compound | Medium — batch-level rejection, not session-level sentinel | Selective per batch |
| Category 1101 workaround | OFF at session, ON via 1101 | 11 for compound batches | Strong on simple batches / normal on compound batches | Per-batch control restored |
Recommendation: For the large majority of deployments, compound mode is a session-level concern and the v2 behaviour is correct and simpler. Declare compound mode at session open. Leave it fixed. The Layer 2 Compound Prefix already provides per-batch ceiling control. Use the Category 1101 workaround only for deployments that specifically need per-batch compound toggling with maximum error detection on non-compound batches — typically high-reliability financial systems on challenged channels. Document it as a named pattern in the deployment profile.
Three-Layer Integrity System
Error Detection in Compound Mode
BitLedger v3.0 uses three independent error detection layers. Compound mode interacts with each layer differently. Understanding these interactions is essential for deploying compound mode on high-reliability or noise-prone channels.
Layer 1 — CRC-15 Session Integrity
The CRC-15 covers the entire session including all compound records within it. Compound mode has no effect on CRC-15 operation. The session checksum is computed over all bytes transmitted in the session regardless of whether individual records are 1111 continuations or standard entries. CRC-15 detects all burst errors of 15 bits or fewer, all single-bit and double-bit errors, and all odd-count errors, with no modification for compound mode.
CRC-15 is session-wide: A corrupted compound group record will be caught by CRC-15 at session close just as any other record would be. The CRC-15 layer is equally strong in compound and non-compound sessions. The error detection tradeoff discussed in this document applies only to the cross-layer and sentinel layers below.
Layer 2 — Cross-Layer Flag Validation
The cross-layer flag validation checks that bits 29–30 in the session header mirror bits 37–38 in each Layer 3 record. In standard records, bits 37–38 carry direction and status flags that must match their Layer 2 counterparts. This redundancy provides per-record integrity at zero wire cost — any mismatch is a protocol error.
In a 1111 compound continuation record, bits 37–38 carry the continuation sub-type (00=standard, 01=correcting, 10=reversal, 11=cross-batch) rather than direction/status mirrors. The cross-layer check therefore does not apply to 1111 records. The second error detection layer is absent for continuation records. This is the specific, bounded weakening that compound mode introduces.
Layer 3 — The 1111 Sentinel
When compound mode is OFF, the value 1111 in bits 33–36 is unreachable by any valid transmission. If it appears, it is unambiguously the result of a transmission error — a free error detection sentinel that costs nothing in overhead. Any record with bits 33–36 = 1111 is rejected without further analysis.
When compound mode is ON, 1111 is a valid code. The sentinel function is surrendered. A corrupted record whose account pair bits happened to flip to 1111 will be processed as a compound continuation. The cross-layer sub-type bits (37–38) may reveal the corruption if the flipped bits produce an inconsistent sub-type, but the strongest form of this layer is gone.
| Compound Mode | 1111 in bits 33–36 | Cross-layer check | CRC-15 |
|---|---|---|---|
| OFF | Unambiguous error — reject | Applies — bit29=bit37, bit30=bit38 | Active — full session coverage |
| ON | Valid continuation — process as 1111 | Absent for 1111 records (sub-type in 37–38) | Active — full session coverage |
Conservation Checking — Per Logical Transaction
In standard (non-compound) mode, the conservation invariant — the sum of all signed flows in a record set must equal zero — is checked per record. Each record is a complete double-entry transaction and must balance on its own.
In compound mode, individual records in a group are permitted to be unbalanced. The conservation check is deferred to group close. When the final leg closes the group (completeness = 0 on a non-1111 record), the decoder runs the conservation check across all records in the group together. This is the correct behaviour for multi-leg transactions: a $499.90 revenue record does not balance by itself. It only balances when the $499.90 COGS record is included.
Why per-logical-transaction checking is correct: Checking conservation per-record in compound mode would reject every valid compound transaction. The conservation law applies to the complete economic or physical event — not to individual legs of that event. The compound group is the unit of conservation, not the record. The decoder enforces this by holding all group records pending until the group closes and then checking the aggregate balance.