Protocol Specification · v0.1.0-draft
Trilateral Receipt Protocol
Four states. Three branches. One cryptographic truth.
The Trilateral Receipt Protocol — formally the Tripartite Consensus
Protocol (TCP) v0.1.0 — defines the deterministic state machine and
cryptographic verification layers required to execute a governance action across
the three co-equal branches of the Emergence Collective: the Living Node
(lvn:), the Algorithmic Infrastructure Agency
(tfb:), and the Lattice Protocol Mesh (lat:). No
branch can act alone. Every state transition requires cryptographic coordination
across all three. No signature? No execution.
Node Identity
Deterministic Addressing & Cryptographic Primitives
Every participating entity within the network operates using deterministic public key infrastructure (Ed25519 or secp256k1) prefixed by its structural branch role. These prefixes enforce strict access control boundary validation at the protocol level — a node cannot claim a role it does not hold.
lvn: — The Living Node
The Civic Assembly. Human operators or multi-signature wallets representing
local community intent. Proposals enter the TCP pipeline exclusively from
lvn: addresses. All ratification signatures must originate
from registered lvn: identities. This is the only branch
authorized to initiate state changes or cast votes in the human assembly.
tfb: — The Algorithmic Infrastructure Agency
The Algorithmic Infrastructure Agency. Localized hardware-enclave runtime
managing multi-agent system analysis. Every proposal routed to
tfb: undergoes an internal adversarial simulation — a proposing
agent and an opposing agent locked in automated debate. The output is an
immutable Impact Certificate carrying expected outcomes,
risk vectors, and a pass/fail determination. If the simulation discovers
unmitigated failure, the proposal is rejected. No proposal reaches
ratification without a tfb: Impact Certificate.
lat: — The Lattice
The Protocol Mesh Consensus layer. Decoupled network nodes validating state
changes over the P2P transport layer. Once both lvn: and
tfb: have validated a transaction, the lat: nodes
ingest the trilateral bundle, write it to the Receipt Hash Chain, and
propagate the state transition across the mesh. The Lattice is the
execution layer — it commits, but it does not propose or simulate.
Key Material & Signatures
All signatures use Ed25519 (EdDSA over Curve25519, RFC
8032) — the same primitive used for node identity in the Lattice transport
layer. secp256k1 is accepted as an alternative for compatibility with
existing wallet infrastructure. Each branch maintains its own keypair.
Branch II (tfb:) signing keys never leave hardware isolation.
Branch III (lat:) keys are derived deterministically from
network genesis parameters.
State Machine
The 4-State Consensus Pipeline
The TCP replaces the historical multi-turn external adversarial loop with a
streamlined, four-state deterministic pipeline. The core adversarial process is
collapsed entirely into an internal multi-agent runtime inside the
tfb: simulation layer. The Witness Sortition Panel survives as a
deadlock breaker — not a separate state, but a tiebreaker within Ratified.
Proposed · lvn:
Initiated exclusively by an authorized human operator. A signed proposal
payload specifies target resources, intent vectors, and boundary
constraints — Georgist land-use parameters, Urban Water Loop telemetry
targets, or mesh resource allocation. The proposal must include a valid
lvn: Ed25519 signature. Proposals without a valid signature
or from non-lvn: addresses are discarded at ingress.
Simulated · tfb:
The signed proposal payload routes to the localized tfb:
hardware enclave. Inside, an internal adversarial loop
spins up automatically. A Proposing Agent generates optimized
implementation paths matching the human intent. An Opposing Agent
programmatically attempts to break the model — searching for economic
extraction vectors, system exploits, or environmental threshold overruns.
The synthesis of this automated debate produces an immutable
Impact Certificate: a cryptographic digest carrying
expected outputs, a risk matrix, and a binary pass/fail determination.
If the simulation discovers unmitigated system failure risks, the proposal transitions to Rejected with a structured rejection log. If successful, the Impact Certificate is signed by the enclave and returned for human ratification. Timeout: 300 seconds.
Rejected
Simulation failure. The enclave broadcasts a structured rejection log identifying the specific risk vectors that could not be mitigated. The original proposer may revise and resubmit. No state change occurs.
Ratified · lvn: Multi-Sig
The evaluated proposal and its Impact Certificate return to the human assembly. Moving past this state requires meeting a definitive m-of-n multi-signature threshold across the local human node registry. Standard ratification window: 600 seconds.
Witness Sortition · Deadlock Breaker
If the human assembly stalls or falls into contested deadlock during ratification, the Witness Escalation Protocol activates. A 5-person sortition panel is selected deterministically via a Blake3-seeded Fisher-Yates shuffle of the local registry. Panel members who participated in the last 3 escalations are excluded. The panel receives the full proposal, opposition log, Impact Certificate, and deadlock report. They have 86,400 seconds (24 hours) to deliberate and break the deadlock via a 3-of-5 majority vote. Their ruling becomes the ratification outcome. This is not a separate state — it is a tiebreaker embedded within Ratified.
Committed · lat:
Upon receiving both the human signatures (or Witness tiebreaker override)
and the tfb: Impact Certificate, the protocol nodes ingest
the trilateral bundle. The transaction is written sequentially to the
Receipt Hash Chain, updating the global mesh ledger state
across all active physical infrastructure. A committed receipt is
immutable and permanently auditable. The state change is executed.
Data Structure
The Trilateral Receipt (CBOR Serialization)
To minimize parsing overhead and ensure absolute structural integrity within
the lattice-node Rust framework, receipt transactions are
serialized using CBOR (Concise Binary Object Representation, RFC 8949). CBOR
was chosen for deterministic serialization, compact wire representation, and
self-describing schema — the same codec used by the Lattice transport layer.
Header Tier [01–04]
Protocol version (u32), unique session ID (uuid),
transaction timestamp (u64, Unix nanoseconds), and previous
receipt hash (Blake3). The parent hash forms the Receipt Hash
Chain — an unbroken cryptographic sequence from genesis forward.
Context Vectors [05–09]
Proposer identity address (lvn: string), target resource ID,
proposed delta mapping, and resource boundary constraints. These fields
capture the full intent of the proposal as signed by the human proposer.
Simulation Telemetry [10–14]
Enclave ID (tfb: string), Impact Certificate digest
(Blake3), risk matrix array (enumerated risk vectors with
severity scores), and simulation step count. These fields are immutable
once the enclave signs — the tfb: cannot revise its analysis
after the fact.
Ratification State [15–18]
Multi-sig state flag (0=pending, 1=ratified, 2=witness-override,
3=expired), Witness sortition seed (u64), Witness panel mask
(5-bit field indicating which panel members voted), and ratification
timestamp. If the Witness path was taken, the sortition seed allows any
observer to verify the panel was drawn fairly.
Cryptographic Proofs [19–22]
lvn: Signature string (Ed25519, 64 bytes), tfb:
Enclave Signature string (Ed25519, 64 bytes), lat: Consensus
multi-sig payload, and the self-referential receipt hash — Blake3 of all
preceding fields with signature slots zero-filled. Any node can verify
integrity by recomputing and comparing.
Verification Procedure
Any node receiving a receipt MUST: (1) Parse the CBOR. (2) Extract the
three signature slots. (3) Serialize the receipt with signature slots
zeroed. (4) Verify each non-zero signature against its branch's public key
and the serialized message. (5) Verify that enough signatures are present
(all three for committed state, lvn: + tfb:
minimum for witness-override). (6) Verify that receipt_hash
matches Blake3 of the fully-populated CBOR. All checks must pass or the
receipt is discarded.
let msg = receipt.serialize_for_signing(); // zeroed sig slots
for (branch_id, sig, pubkey) in receipt.iter_signatures() {
pubkey.verify(&msg, sig)?;
}
let computed = blake3(&receipt.to_cbor());
Ok(computed == receipt.receipt_hash)
}
Temporal Constraints
System Commitments & Network Timeouts
The protocol enforces strict, non-negotiable temporal constraints to protect nodes from infinite resource locking, distributed denial of state, and deadlocked governance. Rounds that stall do not hang — they expire or escalate.
Simulation Timeout
300s
If the internal multi-agent adversarial simulation fails to output an Impact Certificate or clear rejection log within 5 minutes, the node clears its volatile context and drops the transaction. The proposer receives a timeout notification and may resubmit.
Ratification Window
600s
Standard human consensus multi-sig confirmations must compile signatures within 10 minutes before the payload expires. If the proposal is complex and likely to require extended deliberation, the proposer may request an extended window at submission time.
Witness Deliberation
86,400s
If deadlock sortition is triggered, the selected 5-person human panel has exactly 24 hours to deliberate and finalize an override vote. If the window expires without a 3-of-5 majority, the proposal is marked dead and cleared from memory queues. The deadlock is recorded on-chain for audit.
Auditability
The Receipt Hash Chain
Every receipt carries a parent_receipt hash, forming an unbroken
cryptographic chain from the genesis receipt forward. This is not a blockchain —
there is no proof-of-work, no token, no mining. It is a hash chain for
auditability only: any observer can walk the chain from any point backward to
genesis and verify that every decision followed the TCP, that all three branches
participated, and that no receipt was silently inserted or removed.
// Each arrow is parent_receipt → receipt_id
// Tampering with any receipt breaks all subsequent hashes
// The entire governance history is verifiable in O(n) time
Integrity Guarantee
Modifying any field in any historical receipt changes its
receipt_hash, which changes the parent_receipt
field of the next receipt, which changes its hash, and so on
through the entire chain. Tampering with the past is detectable by any
node in a single backward walk. There is no way to rewrite history
without breaking the chain.
Partial Verification
A lightweight node (Tier 1 Edge) does not need the full receipt history.
It can verify that receipt N is valid by checking: (1) the
three signatures, (2) the receipt hash, and (3) a single parent link to
receipt N-1. Full-chain verification is only needed when
joining the network or after extended disconnection.