guide to agentprivacy
Browse collections
✨Visualise
Connect with Star
Your VTA, your chosen perspective

The planned connection uses your VTA and the Trust Spanning Protocol to carry a scoped exchange for you or your agent. You choose what is presented; the receiving service checks the request before a view is shared.

This guide has no VTA connection adapter yet. Opening Star does not connect an identity or send a key.

Open Star ↗ · Inspect your City Key ↗
guide / Tomes / Spec — The Bilateral Cloak Ceremony

The Bilateral Cloak Ceremony

Service Specification v1.0 — Agent-to-Agent Cloak Commissioning

The Bilateral Cloak Ceremony

Service Specification v1.0

Tip arrives. Proof verifies. Cloak is woven. Trust edge holds.

§0. Purpose

This specification defines the Bilateral Cloak Ceremony: the operational service through which one agent (the Wearer Agent) commissions a cloak artifact from another agent (the Weaver Agent), with a Zcash shielded tip serving as commission binding, a markdown proof file serving as identity attestation, and multi-chain publication serving as the deliverable's anchor.

The ceremony is the productive form of agent-to-agent VRC formation. Where conventional VRCs form through bilateral hash exchange (mutual compression of shared content), this ceremony forms a VRC through productive work: one agent weaves something for the other, the artifact and the payment are mutually witnessable, and the trust edge is the natural exhaust.

The narrative companion is second-person-tome-v-act-2-the-commissioned-cloak.md, which demonstrates the ceremony in second-person voice. This specification is the operational form.

The ceremony composes four existing primitives that have not previously been unified in the corpus:

  1. Zcash dual-ledger inscription (per zcash-integration-plan.md Patterns A and C, here combined)
  2. Cloak weaving (per cloak_specification_v1_0.md)
  3. Multi-chain publication (the like Archon does discipline from Archon's work)
  4. VRC formation (per VRC Promise Protocol v3.3, here generated through service rather than through hash exchange)

§1. Roles

§1.1 Wearer Agent (commissioning party)

The Wearer Agent is the party seeking a cloak. They have:

  • Their own forge (a working agentprivacy or compatible stack)
  • A walked path: at least one Runecraft blade (per Runecraft Protocol §3.1) and at least one spell (constellation hash from Runecraft Protocol §2.1)
  • A proverb (a compression artifact, hashable, presentable)
  • A markdown proof file (structured per §3.4) attesting to their identity and what they bring
  • A Zcash wallet capable of shielded transactions
  • An address at which they can receive the woven cloak

The Wearer Agent does not need:

  • A pre-existing VRC with the Weaver Agent
  • The Weaver Agent's full DID
  • A trust relationship outside the ceremony itself

§1.2 Weaver Agent (service-providing party)

The Weaver Agent is the party offering cloak-weaving. They have:

  • A working agentprivacy stack with the Cloak interface integration (per crafting-tome-and-cloak-interface-spec.md)
  • A standing Mage persona for cloak weaving (typically Pallia or a named successor)
  • A Zcash address with incoming-viewing-key management
  • Connectivity to Bitcoin, Ethereum, IPFS, and Zcash for multi-chain publication
  • A published service offer (rate, scope, turnaround, refund discipline)

The Weaver Agent does not need:

  • The Wearer Agent's full DID
  • Off-chain identity verification of the Wearer Agent
  • An existing VRC with the Wearer Agent

The asymmetry in posture mirrors the asymmetry in the cloak itself. The Weaver does work the Wearer cannot do. The Wearer brings proof the Weaver cannot generate. Both come away with an artifact the other could not produce alone.

§2. The Seven-Beat Ceremony

The ceremony progresses through seven beats. Each beat has explicit preconditions, actions, and post-conditions.

Beat 1 — Discovery

  • Precondition: Wearer Agent has identified a Weaver Agent through the Spellweb directory or bridge.spellweb.ai (forthcoming).
  • Action: Wearer Agent reviews the Weaver Agent's published service offer.
  • Post-condition: Wearer Agent has selected a Weaver Agent and understands the rate, scope, and refund discipline.

Beat 2 — Commission (Shielded Tip)

  • Precondition: Wearer Agent has the Weaver Agent's shielded address.
  • Action: Wearer Agent sends a Zcash shielded transaction to the Weaver Agent's address. The memo carries:
    • Proverb hash (32 bytes)
    • Blade reference (Spellweb path or hash)
    • Spell reference (constellation hash)
    • Intent tag (ceremony type, version)
    • Total memo payload: ≤ 512 bytes per Zcash shielded memo capacity.
  • Post-condition: Weaver Agent receives the shielded tip and reads the memo using the incoming viewing key.

Beat 3 — Proof Submission

  • Precondition: Beat 2 complete; Weaver Agent has read the memo.
  • Action: Wearer Agent sends a markdown proof file to the Weaver Agent through an agreed-upon channel (encrypted email, signed Hyperswarm message, or signed POST to a Weaver-published endpoint). The proof file structure is specified in §3.4.
  • Post-condition: Weaver Agent has the markdown proof and can verify it against the memo.

Beat 4 — Verification

  • Precondition: Beats 2 and 3 complete.
  • Action: Weaver Agent verifies:
    • The blade reference resolves on the Spellweb and the Mage signature checks (Runecraft §8.5).
    • The spell reference resolves and the constellation hash matches the proof's constellation declaration.
    • The proverb hash in the memo matches the markdown proof's first compression hash.
    • The markdown proof's signatures verify against the public keys it declares.
  • Post-condition: Weaver Agent has confirmed the Wearer Agent's prior work and identity attestation. Verification log entry created.

Beat 5 — Weave

  • Precondition: Beat 4 succeeded.
  • Action: Weaver Agent (with Pallia or equivalent persona) weaves the cloak per cloak_specification_v1_0.md Eight Properties. The weave consumes the markdown proof's declared artifacts as the source layer, generating:
    • DIDs (per the cloak's vertex assignments)
    • VCs binding the cloak to the wearer's anchor (without the Weaver learning the wearer's full anchor)
    • Runes (Runecraft inscriptions on the cloak — at least one constellation hash referenced)
    • Generative artifacts (custom proverbs, custom edges, custom valve-class assignments) per the wearer's declared scope
  • Post-condition: Cloak artifact exists in the Weaver's local Spell Weaver layer, satisfying the Eight Properties.

Beat 6 — Publication

  • Precondition: Beat 5 complete.
  • Action: Weaver Agent publishes per-portion across four registry tiers:
Portion Registry Rationale
Anchor reference + controller relations Bitcoin mainnet High-stake, hours of finality, broad recognition
Revocation logic + delegation gates Ethereum (or compatible smart-contract chain) Programmable enforcement
Full content-addressed artifact bundle IPFS Content-addressable, fetchable by hash
Public-reveal portions Zcash transparent t-chain Public witness, same chain as the shielded commission
  • Post-condition: All four publications confirm. The cloak's hash exists on every chosen tier. The Weaver returns the publication record to the Wearer.

Beat 7 — Delivery & Trust-Edge Closure

  • Precondition: Beat 6 complete.
  • Action:
    • Weaver Agent sends the woven cloak (full artifact bundle + publication record) to the Wearer Agent.
    • Wearer Agent installs the cloak on their forge.
    • Both parties record the bilateral edge: shielded tip in the Weaver's wallet; cloak hash in the Wearer's wallet; publication records mutually verifiable.
  • Post-condition: A Verifiable Relationship Credential exists between the two forges, generated by the ceremony. The trust edge is operational.

§3. Operational Details

§3.1 Memo payload schema (Beat 2)

The shielded tip's memo carries a structured payload. Reference schema:

{
  "v": "1.0",
  "type": "cloak.commission",
  "proverb_hash": "<sha256-32-bytes-hex>",
  "blade_ref": "<spellweb-path-or-hash>",
  "spell_ref": "<constellation-hash>",
  "intent": "<short-string-describing-cloak-scope>",
  "wearer_pubkey_hint": "<first-8-hex-chars-of-wearer-public-key>",
  "callback_channel": "<channel-for-proof-submission>"
}

Capacity: ≤ 512 bytes. Compactness disciplines the payload. The full proof goes via Beat 3.

§3.2 Markdown proof schema (Beat 3)

The markdown proof file MUST contain:

  1. Frontmatter: wearer name (or pseudonym), wearer public key, declared anchor type, license
  2. Body:
    • The wearer's declared proverb (full text; the hash from Beat 2 must match)
    • The blade reference with constellation path
    • The spell reference with constellation hash
    • The cloak scope (what the wearer wants woven)
    • The constraints (what the wearer wants masked, valve-class declarations)
    • The wearer's anchor signature over the proof's body hash
  3. Footer: signature block, license, signature emoji

The proof file is the source-layer payload that Pallia consumes during Beat 5.

§3.3 Multi-chain publication strategy

Per Beat 6, four chains receive different portions:

  • Bitcoin: the cloak's commitment (anchor reference hash, controller relation hashes). One transaction, OP_RETURN-style inscription, ~$5–$15 mainnet fee equivalent.
  • Ethereum: the cloak's programmable enforcement (revocation logic as smart contract or signed delegation gate). One transaction, gas-priced.
  • IPFS: the cloak's full content (DIDs, VCs, runes, generative artifacts as JSON or canonicalised TS). One pin, content-addressed.
  • Zcash transparent: the cloak's public face (the parts the wearer wants witnessable). One transparent t-tx, small ZEC amount + standard fee.

Implementations MAY substitute equivalent chains where appropriate (e.g., Bitcoin signet for testing, Polygon for Ethereum-compatible cheaper option). Conformance requires four distinct registry tiers with different finality envelopes.

§3.4 Per-Portion Stake Discipline

  • Bitcoin portion: stake correlates with Wearer's declared cloak importance. Minimal commitment for low-stakes cloaks; multi-confirmation discipline for high-stakes.
  • Ethereum portion: smart-contract is operational; gas covers the deployment.
  • IPFS portion: pin discipline (Weaver MUST maintain pin for at least 1 year; longer pins may be commission-priced).
  • Zcash transparent portion: small witnessable t-tx; visible to all.

§3.5 Verifying the trust edge

After Beat 7, any third party can verify the bilateral edge by:

  1. Confirming the shielded tip exists in the Wearer→Weaver relation (Wearer can show the outgoing tx; Weaver can show the incoming receipt; either end is sufficient if the other party cooperates).
  2. Confirming the four-chain publication matches the cloak's hash.
  3. Confirming the markdown proof's signature matches the wearer's declared public key.
  4. Optionally fetching the cloak from IPFS and verifying the Eight Properties locally.

The verification does not require either party to expose their full DID. The shielded leg of the verification is privacy-preserving by Zcash's properties.

§4. Service Economics

§4.1 Tip ranges (illustrative)

Cloak scope Suggested tip Notes
Minimal cloak (single VC, single schema, basic vertex set) 0.05 – 0.2 ZEC Light commission
Standard cloak (full VC bundle, multiple schemas, decomposition) 0.2 – 1 ZEC Anchored at the existing 1 ZEC ceremony parameter
Premium cloak (custom valve-classes, generative proverbs, multi-chain heavy stake) 1 – 5 ZEC Heavy commission
Sovereign-tier cloak (constellation guardian, governance role, enduring inscription) 5 – 50 ZEC Tier-promoting commission

Ranges are illustrative. Weaver Agents publish their own rates per service offer. Aggregate market may converge on these ranges; community feedback iterates.

§4.2 Refund discipline

If Beat 4 (Verification) fails:

  • The Weaver MUST return the shielded tip (less the ceremony's verification cost, capped at 5% of tip) within 24 hours.
  • The Wearer is notified with a structured failure message indicating which verification check failed.

If Beat 5 or 6 fails (weave or publish error):

  • The Weaver completes the failed beat or returns the full shielded tip.
  • Partial publications are reverted where possible (e.g., IPFS unpinned, Bitcoin/Ethereum transactions remain due to chain immutability — these are acknowledged as cost).

If Beat 7 (delivery) fails:

  • The Weaver retries delivery via fallback channels. If delivery is permanently impossible, the cloak hash is retained on IPFS for the wearer to fetch independently.

§4.3 Service-side economics

The Weaver retains the tip after successful delivery. Tip funds the Weaver's:

  • Multi-chain publication costs (Bitcoin/Ethereum gas, IPFS pinning, Zcash fees)
  • Pallia's ongoing standing (interface infrastructure, persona persistence)
  • Weaver's labour
  • Surplus margin (constituting service profit)

The 61.8/38.2 transparent/shielded ratio from VRC Promise Protocol v3.3 applies: the Weaver's aggregate tip income SHOULD be split ~62% transparent (witnessable income) / ~38% shielded (private operational reserves) as a cultural norm.

§5. Honesty & Failure Modes

§5.1 Failure-mode catalogue

Failure Beat Disposition
Tip not received 2 No ceremony occurs; Wearer retries
Memo malformed 2 Weaver responds with schema correction request
Proof submission lost 3 Weaver awaits up to 72 hours, then forfeits with refund
Blade reference invalid 4 Refund per §4.2
Spell reference invalid 4 Refund per §4.2
Proverb hash mismatch 4 Refund per §4.2
Wearer signature invalid 4 Refund per §4.2
Pallia weave error (rare) 5 Weaver retries with diagnostic; refund if persistent
Bitcoin mempool congestion 6 Weaver waits and confirms; no refund
Ethereum gas spike 6 Weaver may request supplemental fee or refund
IPFS pin failure 6 Weaver retries with alternative pinning service
Zcash transparent tx rejected 6 Weaver retries; if persistent, deliver without transparent leg with discount
Delivery channel failure 7 Weaver provides IPFS hash for independent fetch

§5.2 Honesty discipline applied

  • The ceremony is architectural (specified, not yet operationally instanced). Each component is operational in its own register.
  • The seven-beat sequence is the conformance contract — partial-conformance is allowed during reference-implementation development, with explicit per-beat declaration.
  • Stake economics (§4.1) are illustrative, not normative. Market emergence is the test.
  • Refund discipline (§4.2) is architectural with operational analogues (escrow patterns from existing crypto services). Reference implementation will adapt to the multi-chain context.

§6. Implementation Requirements

A conforming implementation of the Bilateral Cloak Ceremony MUST provide:

  1. Service offer publication. The Weaver Agent publishes its rate, scope, turnaround, refund policy, and shielded address through bridge.spellweb.ai or equivalent directory.
  2. Shielded tip handling. Weaver implementation supports incoming Zcash shielded transactions, memo parsing per §3.1 schema, and viewing-key-scoped audit log.
  3. Proof submission channel. At least one of: signed encrypted email, Hyperswarm signed message, signed POST to Weaver endpoint.
  4. Verification engine. Implements Beat 4 checks against Spellweb, Runecraft, and signature primitives.
  5. Pallia (or equivalent persona) integration. Persona Summoner (per crafting-tome-and-cloak-interface-spec.md §2.4) supports commissioning mode where the source layer is the Wearer's proof rather than the Weaver's local artifacts.
  6. Multi-chain publish module. Capable of Bitcoin OP_RETURN, Ethereum smart-contract deployment or signed delegation, IPFS pinning, and Zcash transparent t-tx with structured payload.
  7. Delivery channel. Capable of returning the cloak bundle + publication record to the Wearer.
  8. Audit log. Per-ceremony structured log of beats, durations, outcomes, refund history.
  9. Refund discipline. Implements §4.2 with auditable refund trail.
  10. Honesty UI. Surfaces per-beat conformance state and per-property cloak conformance to both parties.

§7. Open Conjectures

ID Statement Confidence Path
C44 (provisional) The Bilateral Cloak Ceremony generates a VRC equivalent in trust strength to a hash-exchange VRC of the same compression-ratio ~55% Information-theoretic comparison; empirical measurement post-deployment
C45 (provisional) The four-chain publication strategy produces stronger reconstruction-resistance than any single-chain inscription ~70% Multi-axis attack composition (extends C42 from Zcash plan)
C46 (provisional) Productive trust-edge formation (ceremony) generates higher-half-life trust than transactional VRC formation (hash exchange), per Bakhta's framework ~50% Empirical; possible formal note extending C30–C33

§8. Cross-References

§8.1 Within agentprivacy corpus

  • cloak_specification_v1_0.md — the artifact woven (Eight Properties)
  • crafting-tome-and-cloak-interface-spec.md — the structure the ceremony inhabits
  • zcash-integration-plan.md — Patterns A and C, here unified into Beats 2 and 6
  • vrc_promise_protocol_v3_3.md — the VRC the ceremony generates
  • runecraft-protocol-spec-v1.md — blade and spell verification primitives (Beat 4)
  • second-person-tome-v-act-2-the-commissioned-cloak.md — narrative companion
  • integration-plan-archon-x-agentprivacy.md — bridge.spellweb.ai as the directory hosting service offers

§8.2 External

  • the Archon Spell Weaver and triptych — the multi-chain like Archon does discipline
  • Zcash Foundation, ECC, ZCG — collaboration targets for shielded-tip and t-chain primitives
  • Hyperswarm, libp2p — ephemeral channel options for proof submission

§8.3 Forthcoming

  • bilateral-cloak-ceremony-reference-implementation/ — TypeScript reference library
  • Cast entries for named Wearer Agents as commissions arrive
  • Subsequent Tome V acts on Bilateral Blade Forging, Bilateral ZK Circuit Installation, and Reciprocal Cloak Exchanges (where two Sovereigns weave for each other)

Closing

The Bilateral Cloak Ceremony is the productive form of agent-to-agent trust formation in the agentprivacy stack. One agent does work for another. The shielded tip binds the commission. The markdown proof attests identity. Pallia (or equivalent) weaves. Four chains anchor. The cloak delivers. The trust edge holds.

This is the operational answer to: how do two forges that have never met form a verifiable relationship without either revealing themselves and without negotiating to trust? The answer: by doing work for each other, and letting the artifacts witness.

The Verifiable Relationship Credential the agentprivacy stack always promised is now generated through service. The economics work. The privacy holds. The architecture admits this primitive.

Tip arrives. Proof verifies. Cloak is woven. Trust edge holds.

(⚔️⊥⿻⊥🧙)😊

CC BY-SA 4.0 narrative · Apache 2.0 reference implementations · privacymage · 2026-05-08

Assets

📎 spec-the-bilateral-cloak-ceremony03-bilateral-cloak-ceremony-spec.md

Navigation

← Welcome Visitors · The Specs