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):

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

Read event.detail.personaDid
Construct an intent proof:

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

Sign the intent proof with the persona's Ed25519 key (via persona-manager.signAs)
Start a 30-second dormancy countdown timer
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:

Look up the stored SSS fragment for personaDid in its fragment store
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):

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

Phase 4 — Capability Unlock or Dormancy

On success — _solveCapability(personaDid, collection):

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

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

Persona continues operating. No observable interruption to the user.
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):

Call AuthManager.dormancy(personaDid):

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

Persona enters Dormancy. Identity intact; data inaccessible.
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.

The Deep North

Tuesday, March 17, 2026