your two addresses — did:plc + npub from one bzDiD root

① the bsky address — did:plc

did methoddid:plc (portable, PDS-hosted, ATProto)

derivation rolebzDiD root ATTESTS the plc signing key (never is it)

plc documentdid:plc:<rotation-0-hash-of-root>

also_known_asat://handle.beehive

escrow event fieldbuyer_did / seller_did: did:plc:…

law: the plc did is a HANDLE, not the root — lose it and the root re-attests a new one. rotation keys held by the bzDiD ceremony; the escrow fixtures already speak this field.

② the nostr address — npub

key schemesecp256k1 pair, bech32 (npub/nsec)

derivation rolebzDiD root derives the pair via registered context

npub (public)npub1<bech32-of-derived-pub>

nsec (secret)never rendered, never on-chain, client-held only

NIP-05name@beehive.nature

DM payloadpointers only (?room ?order ?piece) — never content

law: the npub is an ADDRESS of the root, not the root itself; relays carry ciphertext (NIP-44 class), and the derivation context is registered so any client can re-derive from the ceremony. secp256k1 vendoring docks with the engine (bzdid-key carries ed25519 today).

③ the binding attestation (on-chain row)

attestation eventdid-bind: {root_fp, plc, npub, ts, sig}

whereVaulta custom_json lane (the event layer already chosen)

costHP-only, free forever at stake (measured 17/20 ops are custom_json)

the interweave: one soul, two mailing addresses, both revocable, both re-derivable. bAccords (TASK 4) stamp both fields on every card and event.