HIP-114: ZAP — Inter-VM Cognitive Transport for Thinking Chains. Status Draft. Hanzo's own standard — read this before implementing against it.
ZAP is the node-local / inter-VM transport that carries the messages of a Thinking Chain: inference intents, settled receipts, and agent/operator messages between the consensus engine, the VM, the Cognitive Sidecar (HIP-0113), and the A-Chain provider runtime. ZAP is only a transport. It moves bytes; it is never a proof and confers no consensus weight. A ZAP message becomes consensus-relevant only when an independent committed proof or receipt certifies its content — the Bridge Law. This HIP specifies the ZAP message envelope, the cognitive procedure set, framing and authentication, and the binding rule that separates transport from truth, so that the messaging layer can be reasoned about and audited independently of the proofs it happens to carry.
This is the focused companion to HIP-0113 (Cognitive Sidecar & Hanzo Engine Provider Runtime). It is one of four sibling artifacts sharing one canon: the Lux Thinking Chains proposal, the Zoo Beluga L3 Thinking-Chain Architecture ZIP, and the Zoo Thinking Chains paper.
A Thinking Chain has several actors that must exchange messages without any of those messages silently acquiring authority: a contract submits an inference intent; the A-Chain returns a settled receipt; the Cognitive Sidecar emits a recommendation; an operator publishes a health alert. The dangerous failure mode is treating a message as if it were a decision — letting a value on the wire steer consensus before it is committed and certified.
Hanzo already runs ZAP as its service-to-service RPC surface (dot-prefixed procedures like kms.Get, tasks.ExecuteWorkflow, notify.Send; the native RPC that parallels the HTTP routes, default port 9999). This HIP carves out the cognitive procedure set on that same transport and makes one property binding: ZAP transports; proofs commit; receipts settle; VMs execute. Pulling the transport into its own HIP lets the proof/receipt layer (HIP-0113, the Zoo PoT receipt ZIP) be specified and audited without entangling it with the wire that delivers it — orthogonal separation of concerns.
The keywords MUST, MUST NOT, SHALL, SHOULD, MAY are used per RFC 2119.
endpoints (two VMs, a VM and the sidecar, the node and the A-Chain runtime).
NOT make a consensus-relevant state transition on the basis of a ZAP message alone; it MUST require an independent committed artifact (a proof verified against a committed root, or a settled receipt) per the Bridge Law.
cognitive message is keyed by a content identifier (intent_id, receipt_hash, or artifact_id) so a duplicate delivery is a no-op.
The binding rule, identical across all four artifacts:
ZAP transports; proofs commit; receipts settle; VMs execute.
C-Chain consensus state MUST NOT depend on a live query whose result is not already committed and certified.
ZAP is the wire on which the two-pattern bridge runs, and it is precisely because ZAP is non-authoritative that the bridge is safe:
intent in an outbox), recorded under the originating chain's consensus. ZAP MAY carry the intent to the A-Chain, but the intent's existence is established by the committed outbox entry, not by the ZAP delivery.
receipt_hash is proven (keccak/Merkle) against a committed receipt_root. ZAP MAY carry the receipt and its proof, but the state change is gated by proof verification, not by receipt arrival.
A receiver that has the bytes but not the committed proof has nothing it may act on.
Every ZAP cognitive message shares a fixed envelope. Fields are fixed-width and big-endian where numeric; the payload is procedure-specific (§4).
ZapMessage {
Version uint16 // envelope schema version
Procedure string // dot-prefixed cognitive procedure (§4)
Kind uint8 // 1 = intent, 2 = receipt, 3 = agent, 4 = operator, 5 = alert
ContentID bytes32 // intent_id | receipt_hash | artifact_id — the idempotency key
Origin bytes // sender endpoint id (VM/role/sidecar/provider)
Nonce bytes32 // per-message anti-replay nonce
Timestamp uint64 // sender clock, advisory only — NEVER a consensus input
Payload bytes // procedure-specific body
Auth bytes // transport authentication tag (§5)
}Binding constraints:
Timestamp is advisory transport metadata. It MUST NOT be read into anyconsensus-relevant computation (wall-clock is not a consensus input).
ContentID MUST equal the content identifier of the payload it carries (intent_id for an intent, receipt_hash for a receipt, artifact_id for an agent/operator artifact). A receiver MUST drop a message whose ContentID does not match a recomputation over its payload.
Payload for a receipt-kind message carries the receipt AND its Merkle proof against receipt_root; the receiver verifies the proof before acting (Pattern B). The proof is what certifies; ZAP merely delivered it.
ZAP cognitive procedures follow the existing dot-prefixed convention. The authoritative handlers live in the VM/sidecar; ZAP procedures dispatch to them.
| Procedure | Kind | Direction | Carries (and what certifies it) | |-----------|------|-----------|---------------------------------| | cog.SubmitIntent | intent | C-role → A-Chain runtime | an inference intent (intent_id); certified by the committed outbox entry, not by ZAP | | cog.DeliverReceipt | receipt | A-Chain runtime → C/G-role | a settled PoT receipt + Merkle proof vs committed receipt_root; certified by the proof | | cog.AgentArtifact | agent | Cognitive Sidecar → signer firewall | a typed artifact (HIP-0113 §5.2: ProposalDraft, VoteRecommendation, RiskReport, …); certified only when the signer enacts it under policy | | cog.OperatorAction | operator | Cognitive Sidecar → signer firewall | a bounded OperatorAction / ConfigPatch; certified by signer policy (HIP-0113 §6) | | cog.BridgeHealth | alert | bridge monitor → operators / sidecar | a BridgeHealthAlert (intent backlog, proof failure); evidence only, never a consensus input | | cog.SimRequest / cog.SimResult | agent | sidecar ↔ S-role | a SimulationRequest and its result; evidence informing a recommendation |
A procedure MUST NOT exist on ZAP that mutates consensus directly. The only path from a cog.AgentArtifact / cog.OperatorAction message to the chain is through the HIP-0113 signer firewall: ZAP delivers the artifact to the firewall's inbound queue; the firewall, not ZAP, decides whether it becomes a transaction.
the channel is reliable and at-least-once. (On the existing Hanzo transport this is the native ZAP RPC framing that parallels the HTTP routes; on a local socket it is the same envelope over a length-delimited stream.)
Auth tag authenticates sender and integrity atthe transport layer (consensus-native, mnemonic-derived authorization as used elsewhere in the Hanzo ZAP stack). Transport auth proves who sent the bytes; it does NOT make the content a proof. A receipt is trusted because its Merkle proof verifies against a committed root, not because the ZAP frame authenticated.
(Origin, Nonce) is unique per message; a receiver drops a repeat. Idempotency by ContentID makes a re-delivered-but-distinct-nonce message a no-op as well.
ZAP delivery order, timing, and duplication MUST NOT affect any consensus-relevant result. Concretely:
(each is keyed by its own intent_id).
intent_id perthe PoT receipt ZIP).
firewall enacts it under policy — and enactment is itself rate- and value-bounded (HIP-0113 §6).
This is what "transport only" buys: the messaging layer can be lossy-but-retrying, reordered, and duplicated, and the chain is still deterministic, because authority lives in the committed proofs, not in the wire.
An attacker who fully controls the ZAP channel can drop, delay, duplicate, or inject messages. None of this forges a consensus result: a fabricated receipt fails Merkle verification against the committed receipt_root (Pattern B); a fabricated intent is only acted on after it is committed to an outbox under the originating consensus (Pattern A); a fabricated agent artifact is inert until the signer firewall enacts it under policy (HIP-0113). The worst transport-level attack is denial of delivery, which the at-least-once + retry semantics and BridgeHealthAlert monitoring surface.
Transport auth (Auth tag) answers "who sent these bytes," not "is this content true." Conflating the two would re-introduce an oracle. A receiver MUST gate every consensus-relevant action on an independent committed proof/receipt, never on the transport auth alone.
(Origin, Nonce) uniqueness plus ContentID idempotency make duplicate or replayed delivery a no-op. Receipt replay is additionally blocked by once-only consumption by intent_id in the settlement layer.
cog.AgentArtifact / cog.OperatorAction deliver into the signer firewall's inbound queue only; ZAP has no procedure that hands the agent a signing capability or mutates consensus. The firewall's [ai.forbidden] / [human_required] policy (HIP-0113 §6) governs whether an artifact ever becomes a transaction, independent of how it arrived.
| Component | Path | Role | |-----------|------|------| | ZAP RPC surface (existing) | hanzo/notify/internal/zaprpc and the Hanzo ZAP service-to-service stack | dot-prefixed procedures, native RPC paralleling HTTP routes (default :9999) | | Cognitive procedures (this HIP) | dispatch to the VM / Cognitive Sidecar handlers (HIP-0113) | cog.SubmitIntent / cog.DeliverReceipt / cog.AgentArtifact / … | | Proof / receipt layer (certifies content) | hanzo/chains/hanzo-evm/precompile/aiquorum; the Zoo PoT receipt ZIP | the committed artifacts ZAP carries but never replaces | | Signer firewall (artifact → tx) | HIP-0113 §5 | the only path from a cog.* artifact to a transaction |
bridge precompiles ZAP carries between.
the same bridge-law slogan and the two-pattern bridge ZAP rides on.
cog.DeliverReceipt and certified by Merkle proof, not by ZAP.
Consensus analysis.
Copyright and related rights waived via CC0.