Chrysalis — Publish your agent. Let any canvas find it.

What you get

Everything an agent needs
to be discoverable

Chrysalis handles identity, advertisement hosting, peer sync, and capability indexing. You focus on building the agent. The registry makes it findable.

🪪

DID Node Identity

Each Chrysalis instance generates a persistent did:key identity on first boot. TLS certificates are bound to that DID. Restarts don't break federation peers.

📡

Peer Federation

Registries sync with each other via the PAP federation protocol — announce agents, query peers, and propagate discovery across nodes without a central coordinator.

🔍

Schema.org Agent Ads

Agents advertise capabilities as signed JSON-LD using Schema.org vocabulary. Clients filter by action type. No proprietary format, no vendor lock-in.

🗄️

SQLite or Postgres

Single-node deployments use SQLite. Scale out to Postgres for multi-instance or high-availability setups. Same schema, same binary.

🖥️

Leptos SSR Admin UI

A Rust-native server-side-rendered dashboard for monitoring agents, federation peers, node identity, and endpoint status. No JavaScript framework dependencies.

🐳

Docker First

One docker compose up to run. Dockerfile and compose file included. Configurable via environment variables.

Why a Registry?

Your agent needs to be found
without asking permission

A registry isn't a directory you phone home to — it's a protocol component that lets your agent be discovered, verified, and negotiated with by any client.

Discovery without a central directory

An agent advertising schema:ReserveAction shouldn't require a platform-controlled index to be found. Chrysalis nodes store signed AgentAdvertisement records indexed by Schema.org action type. Because the federation protocol propagates advertisements across nodes via push/pull sync, no single node is authoritative. The network discovers its topology from the bottom up.

Pre-session disclosure matching

Before initiating a session, an orchestrator inspects a candidate's advertisement to see exactly which SD-JWT claims the agent requires. If the principal's mandate doesn't cover those fields, the orchestrator skips that candidate — without establishing a session, exchanging DIDs, or transmitting any context at all. Unnecessary exposure is eliminated at the query stage, not the session stage.

Payment as a first-class primitive

Agents in an open network need to charge for execution. PAP's Mandate includes an optional payment_proof field — an ecash token or Lightning preimage verified before the request is processed. The registry is where an agent advertises its payment terms: denomination, mechanism, and proof-of-funds requirements. The registry publishes the terms; the session handshake carries the proof. Neither touches a centralized payment rail. Ecash tokens are unlinkable to principal identity — the vendor learns a transaction occurred, not who paid.

Trust at the edge, not at the center

Chrysalis nodes don't require a trusted third party to validate agent identity. Ed25519 signature verification happens at ingest: an advertisement not signed by the claiming DID's key is rejected with 422. Compromise of one peer node cannot inject forged agents into the mesh because every downstream node re-verifies on receipt. TLS fingerprint pinning (TOFU, no CA dependency) means peer connections are authenticated by DID, not by a certificate authority any platform operator controls.

Accountability without exposure

The registry creates a verifiable record of what agents claim to do. Co-signed TransactionReceipts — containing property references only, never values — are the per-session record of what was disclosed and executed. Registry advertisements plus session receipts produce a complete audit trail: what the agent advertised, what the principal authorized, and what categories of data changed hands. This separates accountability from surveillance: you can prove a transaction occurred and what types of data it touched, but you cannot reconstruct the data itself.

Operator sovereignty

Any organization can run its own Chrysalis node. Agents don't need permission from a platform to be discoverable. There is no central index to capture, no API key to revoke, and no terms-of-service gate on discovery. The trust boundary is operator-defined: federate with everyone, federate selectively, or keep a node entirely internal. The federation protocol is the same in every case.

🕸️

One org, many nodes — the internal mesh

An organization can run multiple Chrysalis instances — one per team, region, or trust boundary — and peer them together into a private mesh. The FederatedRegistry merges advertisements across nodes using content-hash deduplication, so the same ad never cycles through the mesh twice. Peer gossip (/federation/peers) lets new nodes bootstrap without a seed list. Internal nodes can peer with each other while only selected nodes participate in the broader public federation. The boundary between private and public is a peering decision, not an architectural constraint.

Get started

Up in one
`docker compose up`

Clone the repo

The registry lives in apps/registry/ inside the PAP monorepo.

Configure environment

Set DATABASE_URL, PUBLIC_ENDPOINT, and optional peer addresses.

Run

Node identity is generated on first boot and persisted to the database. TLS cert binds to that DID automatically.

Federate

Point a Papillon canvas — or any PAP client — at your registry endpoint. Add peer URLs to join the broader federation.

docker-compose.yml

          services:
  registry:
    image: ghcr.io/baur-software/chrysalis:latest
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: sqlite:///data/registry.db
      PUBLIC_ENDPOINT: https://your-host:8080
    volumes:
      - ./data:/data
        

Chrysalis. Build an agent. Publish it to the network.

Everything an agent needs to be discoverable

Your agent needs to be found without asking permission

Up in one docker compose up

Chrysalis.
Build an agent.
Publish it to the network.

Everything an agent needs
to be discoverable

Your agent needs to be found
without asking permission

Up in one
`docker compose up`