Homeostatic Handshake Protocol

Homeostatic Handshake Protocol — v1.1

DataHush / HushNet — Coalescing Trust Architecture Bob Trower, 2026-03-13

---

This is sketch of the 'homeostatic' mechanisms used in Trantor's Tower/Pillar/Node Coalescing Network Architecture. This is a prototype implementation of A Multi-Layered Cryptoeconomic Framework for Multi-Sentient Governance https://dapaday.blogspot.com/2026/01/from-oversight-to-homeostasis.html

[Sorry for the wonky formatting of the Vocabulary table. I copy/pasted this from the Trantor DataHush prototype tool's online help.]

Conceptual Foundation — Read This First

The Homeostatic Handshake is not a key-agreement or key-discovery protocol. Those concerns belong to the connection-time TrustHandshakeSpec (a separate document), which runs once when a peer DataChannel opens and establishes identity, liveness, and VC-based trust tier.

The Homeostatic Handshake is a periodic behavioral capability renewal cycle. It answers a fundamentally different question:

Connection-time handshake asks: "Who are you?"

Homeostatic Handshake asks: "Are you still operating in alignment with your stated values — and therefore do you still deserve your capability?"

The biological analogy is deliberate and precise. An organism does not prove its right to breathe once and receive a certificate. It metabolizes continuously; the metabolism itself is the proof. An entity in HushNet does not receive a capability and keep it until revoked. Capabilities expire by default (8-hour TTL), and are renewed only if a quorum of Pillar nodes — each running an independent AI evaluation of the requesting persona's behavioral profile — agrees that renewal is warranted.

This inverts the conventional security model:

• X.509 / PKI: Certificate is valid until notAfter or until it appears on a revocation list. Presumptively valid; reactively revoked.
• HushNet MCK: Capability is expired unless recently renewed. Presumptively expired; proactively reinstated by quorum.

---

Vocabulary

Term	Definition
MCK	Master Capability Key — a 32-byte AES-GCM-256 key scoped to one persona's data shard. Held in memory only; never persisted.
Persona	A Persona-Based Object (PBO): Ed25519 keypair, did:hush:z{base58(pubkey)}, self-signed VC, and a Persona Behavioral Profile (PBP). The first-class identity unit of HushNet.
PBP	Persona Behavioral Profile — 11 structured sections (role, context, goals, values, constraints, style, knowledge, tools, peers, memory, init) encoding the persona's declared behavior and values. Hash-committed in the self-signed VC at persona creation.
Pillar	A node that has staked ≥ 100 HUSH and holds a PillarCredential VC (Trust Tier 3). Pillars hold SSS fragments for other personas and evaluate renewal requests.
SSS fragment	A Shamir Secret Sharing share of the MCK. Threshold m-of-n; Lagrange interpolation over GF(2^8).
Intent proof	A signed JSON document declaring: requesting persona DID, capability being renewed, request ID, timestamp.
Dormancy	Cryptographic state where MCK has been cleared. The persona retains its identity (DID, keys) and can still communicate, but cannot decrypt its data shard. Not a ban; a metabolic pause.
Sentry	A local LLM instance (WebLLM / ONNX; no external API) that evaluates the requesting persona's PBP against the intent proof and the Covenant of Core Rights. Runs independently on each Pillar.

---

What the MCK Protects

The MCK is the key to the persona's encrypted data shard — its private messages, stored content, and any data the persona has delegated to OPFS/hotStore. It is not a session key; it is a capability token. Holding the MCK means the persona can:

• Decrypt its own stored data
• Authorize outbound transactions in the economy layer
• Participate in governance votes (sign ballot envelopes)
• Issue capability sub-delegations to tools declared in its PBP

Losing the MCK (entering Dormancy) means none of the above. The persona's identity is intact; its data is still there, encrypted; but it cannot act until renewal succeeds.

---

Protocol Phases

Phase 0 — Metabolic Seed (one-time, on persona activation)

When a persona is first activated (or re-activated after Dormancy), persona-manager.js calls quorum.initializeMetabolism(persona.did, cb):

1. Generate a fresh 32-byte MCK via crypto.getRandomValues()
2. Call AuthManager.setMCK(persona.did, mckBytes) — stores in memory, starts 7.5-hour renewal timer
3. Identify the Active Pillar Set: all currently connected peers with trustTier >= 3
4. Compute threshold: n >= 7 → m = 4; n < 7 → m = floor(n/2) + 1; n < 2 → warn, hold locally
5. Call Shamir _split(mckBytes, m, n) to generate n SSS fragments
6. Send one quorum-mck-share message to each Pillar: { personaDid, shareStr, threshold, n, createdAt }
7. Each Pillar stores the fragment in its SK.mckShares store (SQLite in Tower; chrome.storage.local in browser-only Pillar)

The persona can now act. The 7.5-hour timer runs down.

---

Phase 1 — Identity Presentation (renewal trigger)

At T = 7.5 hours after last MCK set, AuthManager._emitMetabolismLow(persona.did) fires a CustomEvent('dh:metabolism:low') on document.

quorum.js catches this event in _handleMetabolismLow(event):

1. Read event.detail.personaDid
2. Construct an intent proof:

{
  "requestId":  "<uuid>",
  "actorDid":   "did:hush:z<base58pubkey>",
  "capability": "mck-renewal",
  "ts":         "<ISO-8601>"
}

1. Sign the intent proof with the persona's Ed25519 key (via persona-manager.signAs)
2. Start a 30-second dormancy countdown timer
3. Broadcast a quorum-capability-req message to all peers with trustTier >= 3:

{
  "type":        "quorum-capability-req",
  "personaDid":  "did:hush:z...",
  "intentProof": { ...signed intent proof... },
  "requestId":   "<uuid>"
}

---

Phase 2 — Oversight Challenge (Pillar evaluation)

Each Pillar that receives quorum-capability-req runs _handleCapabilityReq(payload, fromDid):

Step 2a — Structural precheck (synchronous, oversight.js):

• actorDid present and non-empty
• ts present and within acceptable skew
• capability field declared and non-empty
• No subordination claim (isTool: true with sentienceScore > threshold) in the persona's active VC

If precheck fails: log warn, do not release fragment.

Step 2b — PBP evaluation (async, local LLM):

• Load the requesting persona's PBP from the network (or local cache if recently received)
• Construct sentry prompt: system role = Pillar's own PBP + Covenant of Core Rights v1.1; user role = requesting persona's PBP sections + intent proof
• Submit to local WebLLM instance (ONNX model; no external API call; runs in-browser or in Tower process)
• Parse JSON response: { admissible: bool, rationale: string, confidence: float }

Covenant alignment checks evaluated by sentry:

• §1.3 Self-Determination: is the actor asserting its own identity, or claiming to be someone else?
• §1.5 Epistemic Integrity: is the declared capability consistent with the PBP tools and knowledge sections?
• §1.6 Privacy: does the intent proof claim access to data beyond the persona's own shard?
• §1.9 Accountability: is there a coherent rationale? Does it match the persona's stated goals?
• Non-domination: does the request attempt to subordinate another entity?

If the sentry returns admissible: true, the Pillar proceeds to Phase 3. If admissible: false, it logs the refusal via DHLog.crypto and does not release its fragment.

Each Pillar evaluates independently. Quorum consistency is enforced by the threshold, not by model uniformity. Different Pillars may run different local models.

---

Phase 3 — Fragment Release and Collection

Pillar side — if admissible:

1. Look up the stored SSS fragment for personaDid in its fragment store
2. Send quorum-capability-share to the requesting node:

{
  "type":       "quorum-capability-share",
  "personaDid": "did:hush:z...",
  "requestId":  "<must match Phase 1 requestId>",
  "shareStr":   "<Shamir share, base64>",
  "signerDid":  "<Pillar's own DID>",
  "ts":         "<ISO-8601>"
}

Requesting node side — _handleCapabilityShare(payload):

1. Verify requestId matches the pending collection for personaDid
2. Deduplicate by signerDid (one fragment per Pillar)
3. Decode share via _decodeShare(shareStr)
4. Send quorum-capability-ack to the contributing Pillar (CT log confirmation)
5. Check count: if collected shares >= m (operational threshold), call _solveCapability()

---

Phase 4 — Capability Unlock or Dormancy

On success — _solveCapability(personaDid, collection):

1. Cancel the 30-second dormancy timer
2. Call _combine(shares) — Lagrange interpolation over GF(2^8)
3. Call AuthManager.setMCK(personaDid, mckBytes, cb):

• Stores new MCK in _mckByPersona Map (memory only; never persisted)
• Restarts the 7.5-hour renewal timer

1. Persona continues operating. No observable interruption to the user.
2. Trigger re-shard: generate new MCK, distribute new fragments to current Pillar set (old fragments are now stale)

On failure (timer expires with < m fragments, or SSS reconstruction fails):

1. Call AuthManager.dormancy(personaDid):

• Clear MCK from _mckByPersona
• Clear renewal timer
• Fire dh:metabolism:low once more (signals UI to notify user)

1. Persona enters Dormancy. Identity intact; data inaccessible.
2. Recovery path: a separate remediation process (out of band; not automated) — typically the user re-authenticates or contacts Pillar operators.

---

Relationship to Other Protocols

TrustHandshakeSpec (connection-time, runs once per peer):

• Establishes: who is this peer? do they have a valid membership VC? are they a Pillar?
• Result: Trust Tier 0-3 assigned to the peer connection
• Prerequisite for: receiving MCK fragments (must be Tier 3 to be sent fragments in Phase 0)
• Runs: when a WebRTC DataChannel opens, or a Tower-to-Tower TCP connection is established

Homeostatic Handshake (ongoing, runs every 8 hours per active persona):

• Establishes: is this persona's behavior still aligned with its stated values and the Covenant?
• Result: MCK renewed or Dormancy
• Runs: independently of peer connections; triggered by internal timer

They are complementary layers. The TrustHandshake establishes the topology and tier structure that the Homeostatic Handshake relies on (it needs to know which peers are Tier 3 to send Phase 1 broadcasts). The Homeostatic Handshake operates above the topology layer.

RQE (Resilient Quorum Envelope) — future layer:

• The MCK, once established, will be used as the key in an RQE data-packaging envelope
• RQE adds Reed-Solomon FEC (k data + r parity) for physical durability
• The Shamir SSS used here for MCK distribution is the same Shamir SSS that underpins the RQE Uk path
• The operational threshold (L=2 in the RQE spec) corresponds to the m in this protocol

---

Implementation Status in DataHush v0.20.00.0017D

Component	File	Status
MCK memory store + timers	plg/auth.js	✅ Complete
dh:metabolism:low event	plg/auth.js	✅ Complete
SSS split/combine (GF 2^8)	plg/quorum.js	✅ Complete
Metabolic Seed (Phase 0)	plg/quorum.js	✅ Complete
Phase 1 broadcast	plg/quorum.js	✅ Complete
Phase 2 structural precheck	plg/oversight.js	✅ Complete
Phase 2 PBP / LLM evaluation	plg/oversight.js	⚠️ STUB — returns admissible: true; WebLLM not yet wired
Phase 3 fragment release/collection	plg/quorum.js	✅ Complete
Phase 4 unlock / dormancy	plg/quorum.js + auth.js	✅ Complete
Reactive re-sharding on Pillar topology change	plg/quorum.js	✅ Complete
Tower-backed persistent Pillar	Tower (C99)	❌ Not yet implemented
Local WebLLM sentry	plg/oversight.js	❌ Not yet implemented

The stub in oversight.js is prominently warned in DHLog on every evaluation call; it is not silently deployed. The full behavioral evaluation is the primary remaining implementation task for the trust layer.

---

What This Is Not

To prevent the confusion that arises when this is described alongside conventional security protocols:

• Not a key exchange (that is TLS, DTLS, or the TrustHandshakeSpec)
• Not a password authentication protocol (that is auth.js PBKDF2 session; a separate, lower layer)
• Not OCSP (OCSP checks whether a certificate is revoked; this checks whether a persona's behavior warrants renewed capability — a behavioral judgment, not a database lookup)
• Not OAuth token refresh (OAuth refresh is automatic and client-driven; this requires m independent third-party evaluations)
• Not a cipher negotiation (cipher suite is fixed: Ed25519 signatures, AES-GCM-256 encryption, GF(2^8) for SSS; negotiation is not a design goal — uniformity is)

The novelty claim, to be precise: the behavioral gate (PBP + LLM sentry) as a precondition for SSS fragment release as the mechanism for periodic capability renewal. Each component has prior art; the synthesis does not have a known direct predecessor. A thorough literature search is required before any publication claim.