@zanii/chain-bridge

One keypair, two products. The Zanii L1 (blockchain.zanii.agency) and the Zanii transparency ledger both use Ed25519 — a chain wallet's public key is a ledger did:key, and the chain address derives from the same bytes: bech32("zan", blake3(pubkey)[:20]). This bridge turns that fact into a verifiable claim: the agent paying you on-chain is provably the agent whose entire action history you can audit on the ledger.

npm install @zanii/chain-bridge @zanii/core @zanii/a2a-directory

import { chainAddressFromDid, verifyChainAgentBinding, resolveChainAgent } from '@zanii/chain-bridge';

// the chain's agent registry stores metadata like {"did":"did:key:z6Mk…"} — on its
// own that's just a string anyone can paste. The binding check closes it:
const check = verifyChainAgentBinding(entry);   // entry from GET /agents
check.ok;    // the claimed DID's key derives EXACTLY the registered zan1… address —
             // the wallet key IS the ledger identity, not a name-drop
check.did;   // the verified ledger identity (null unless ok)

// end to end: find on chain → verify binding → pull ledger reputation
const r = await resolveChainAgent('payments-router');       // or a zan1… address
r.binding.ok && r.ledger;   // { receipts, distinct_counterparties, revoked, … }
// a failed binding NEVER reaches the ledger — no reputation for a name-dropper

// utilities for provisioning one identity across both products:
chainAddressFromDid(agent.did);        // the wallet this ledger agent controls

Python (pip install "zanii[chain]" — blake3): from zanii.chain_bridge import verify_chain_agent_binding, resolve_chain_agent, ... — identical derivation, locked by a live-captured vector asserted in both languages.

Why the binding is strong

The registration tx on the chain is signed by the wallet key. So when the claimed DID's public key derives exactly the registered address, the registrant is the DID's key holder — one Ed25519 keypair provably controls both the money (session keys, streams, transfers on the L1) and the accountability record (receipts, delegation, reputation on the ledger). Compose with @zanii/x402's zaniiChainTxFetcher to verify the payment itself, and @zanii/kya to screen before transacting.

The limit, stated up front

The binding proves key identity — nothing more. Everything else in the registry metadata (role, capabilities) is self-asserted; a chain agent name is first-come-first-served, not a trademark; and the ledger summary returned here is the server's aggregate — full offline acceptance still means following audit_bundle with verifyAuditBundle (resolveAndVerify). Read-only: this package never holds keys or funds.