See It Work — Memory that spans nodes — without one giant shared database | S2 Vol 4 · Federation & Partner Device Gateway

Each node's memory is its own — there's no central database holding everyone's records. So how does the federation remember a shared event? When an event at one node matters to another, its sealed update travels over (the four-step check from Ch 3), and each affected node seals its own witness receipt — a record that it saw the event. Together those receipts are the federation's memory.

A central federation database becomes a single thing to capture, leak, or depend on. Per-node memory with witness receipts keeps every node's history its own — and still legible across the federation.

What this means for you

The federation remembers through per-node witness receipts, not a central database. What this means for you: your node's memory stays yours alone — nothing central to leak or lose — and your successor inherits a complete, legible history without needing anyone else's records.

A cross-node event is recorded as a witness receipt at each affected node:

Cross-Node Memory

central databasenone

a shared eventwitnessed + sealed per node

who holds the full record?no single node

inheritanceeach node's chain, witness included

Memory sovereignty preserved — the federation is legible at every peer without any peer holding it all.

For the technical reader — the command, and how to verify it yourself

# one line · you do not need to run this
see walkthrough

./bl-verify
# -> a witness receipt that verifies at each affected node

Full step-by-step is in Appendix RX: Hands-On Demonstrations in the book.