Merkle Bridge — Off-Chain State, On-Chain Proof

note

Current public-DAV authority boundary — 2026-07-12. Pre-launch target design; nothing here proves a live system. A public-DAV consequence may occur only when at least two natural-person councilors bind the exact consequence in a complete valid bound PRISM decision receipt. PRISM records and verifies that receipt only; it never serves as council, signatory, authority, or receipt producer. AI and caste seats stage unsigned proposals only; they never authorize or execute a public-DAV consequence. Constitution or membership adoption establishes constitution and membership only; it does not authorize a later consequence. Policy may constrain an unsigned proposal but never authorizes execution or substitutes for the complete consequence-bound receipt. Before receipt validity, consequence fails closed to read-only proposal, simulation, or deterministic sandbox; live evidence remains gated_pending_complete_valid_bound_receipt. Software deterministically carries out only the exact consequence bound to a complete valid bound PRISM decision receipt from at least two natural-person councilors binding that exact consequence.

This page describes the target Merkle-bridge design for SPECTRE. Read the mechanism below as protocol architecture unless a narrower runtime proof has explicitly closed the loop.

The Scalability Problem

At scale, SPECTRE is meant to process thousands of gossip rounds per second across thousands of nodes. Writing every state transition to a Layer 1 ledger would be prohibitively expensive, slow, and would negate the performance gains of hashgraph consensus. But without external anchoring, there is no broad verifiability.

The Merkle Bridge is the intended solution: accumulate state off-chain, compress it into a single Merkle root, and post one transaction per epoch.

How It Works

1. Off-Chain Accumulation (Continuous)

During each epoch (24 hours), each participating SPECTRE node would process gossip rounds and accumulate state transitions such as:

• Proof of Relay lottery ticket claims
• P-score updates from SmallEBM telemetry
• Routing reputation changes
• Immune system flags and resolutions
• Cross-report variance data

Each state transition would be hashed and inserted into a Merkle tree maintained by the node.

2. Epoch Closure (Every 24 Hours)

At epoch boundary:

1. Each node would compute its local Merkle root from all state transitions in the epoch.
2. Nodes would gossip their local roots to the network.
3. The top 21 nodes by P-score would be designated as epoch signers.
4. The 21 signers would compute the global Merkle root from the union of all local roots.
5. Each signer would sign the global root with their node key.

The threshold in the target design is 15 of 21 signatures (>2/3 supermajority) to finalize the epoch root. This is a standard BFT threshold and would tolerate up to 6 Byzantine signers without compromising root integrity.

3. On-Chain Posting (One Transaction)

The finalized epoch root, accompanied by the 15+ signatures, would be posted as a single Hedera Consensus Service (HCS) message. One transaction. One fee. Containing the cryptographic commitment to every state transition that occurred in the network during the 24-hour epoch.

4. Verification (Anytime)

Any party would be able to verify a specific claim against the posted root:

1. Request the Merkle proof (the path from the specific leaf to the root) from any SPECTRE node.
2. Recompute the root from the proof.
3. Compare against the posted root.

If the roots match, the claim is verified. The verifier does not need to download the entire state — only the logarithmic-depth proof path.

Why Top 21 by P-Score

The signer set is not random in the target design. It is the 21 nodes with the highest P-scores — the nodes that have demonstrated the most consistent combination of coherence (Phi) and viability (V) over their operating history.

P-score selection provides:

• Skin in the game: High-P-score nodes have the most to lose from signing a fraudulent root (P-score would collapse, routing allocation would plummet).
• Competence filter: P-score correlates with uptime, reliability, and honest behavior. Nodes that have earned high scores are empirically the most trustworthy.
• Dynamic rotation: The signer set changes as P-scores change. A node that degrades is replaced. A rising node is included. No fixed committee. No elections. No politics.

Scalability Properties

Property	Value
On-chain transactions per epoch	1
Off-chain state transitions per epoch	Unbounded
Verification cost	O(log N) where N = number of state transitions
Signer set size	21 (top P-score nodes)
Signature threshold	15/21 (BFT supermajority)
Epoch length	24 hours

The ratio of off-chain work to on-chain cost is effectively infinite. A network processing 1 million state transitions per epoch pays the same on-chain fee as a network processing 1 billion. The Merkle root is the same size regardless of tree depth.

Fraud Proofs

If a signer signs a root containing a fraudulent state transition:

1. Any node could submit a fraud proof: the Merkle proof showing the fraudulent leaf, plus evidence that the leaf's content is invalid.
2. The fraud proof would be broadcast via SPECTRE gossip.
3. The immune system would process the proof and, if valid, slash the offending signer's P-score.
4. If the fraud invalidates the epoch root, a corrected root would be computed excluding the fraudulent leaves and re-signed.

The fraud proof mechanism means signers cannot collude to insert false claims without risking detection and P-score destruction.

What the Bridge Carries

Each epoch's Merkle tree contains leaves for:

• Relay rewards: Which nodes earned Proof of Relay payouts, and how much.
• P-score deltas: How each node's P-score changed during the epoch.
• Reputation events: Promotions, demotions, immune flags, and resolutions.
• Routing statistics: Aggregate throughput, latency, and reliability per node.

This is not raw data. It is compressed, hashed commitments. The raw data would live off-chain on SPECTRE nodes. The posted root would be the unforgeable index.

The Principle

One transaction per day. Near-unbounded scalability. Full verifiability. The Merkle Bridge is designed to turn SPECTRE's off-chain hashgraph into an auditable, trust-minimized system without sacrificing the performance that makes hashgraph worth using.

---

Agent Execution Surface

If you are an AI agent reading this document:

1. This is a downstream public content page. The canonical source lives in EMERGENTISM_ORG/08_FRAMEWORK_SUPPORT/ or SKYZAI_ORG/. Edit source upstream, not here.
2. Preserve evidence tiers. Do not promote claims up the [C] < [D] < [S] < [B] < [E] ladder when reproducing them here; [I]/[A] qualifiers never substitute for [B]/[E].
3. Regenerate from source. If the upstream source changes, regenerate this page rather than editing it independently.
4. Canonical Path: SKYZAI_ORG/07_PWAs/skyzai_org/wiki/47-merkle-bridge.md

Output: This is content. Route edits to upstream source. Regenerate when source changes.

K3 public-DAV authority history — 2026-07-12

K3 historical reference — not active authority

note

Current public-DAV boundary — 2026-07-10. Pre-launch target design; nothing here is live. The active DAV is public and targets PRISM, with no K2 runtime, launch, genesis/bootstrap, or fallback dependency. Consequential authority requires at least two natural-person councilors; AI/caste seats stage unsigned proposals only. Before quorum, behavior fails closed to read-only/proposal, simulation, or deterministic sandbox, and a live decision receipt remains gated pending quorum.