Architecture

Sigilry implements CIP-103 — Canton Network’s dApp API standard — as a thin, typed layer between dApps and wallet extensions. The primary contract is JSON-RPC over a transport such as postMessage, with method names, params, results, and event semantics fixed by the CIP-103 OpenRPC schema. See CIP-103 Conformance for the per-method conformance status.

System diagram

dApp UI
  -> @sigilry/react (hooks) or @sigilry/dapp (provider)
  -> WindowTransport (postMessage)
  -> Wallet extension (RPC server)
  -> Canton Ledger API / DAML

Developer tooling
  -> @sigilry/cli (DAML DAR to TypeScript types)

Responsibilities

• dApp: Calls window.canton.request({ method, params }) and reacts to CIP-103 events.
• Provider: Implements the CIP-103 dApp API. Object shape (request, on, removeListener) follows the EIP-1193 pattern that CIP-103 adopts.
• RPC server: Validates params with Zod schemas generated from the CIP-103 OpenRPC spec and routes to handlers.
• Transport: Moves requests and responses between contexts.
• Schemas: Generated from the CIP-103 OpenRPC spec and used for runtime validation.

Data flow

1. dApp sends JSON-RPC request to the provider.
2. Transport serializes the message (for example, postMessage).
3. Extension receives the request and routes it through createCantonServer.
4. The server validates params and calls the handler.
5. Response is returned to the dApp and validated by the client.

Versioning and specs

• CANTON_DAPP_API_VERSION exposes the CIP-103 dApp API revision implemented by @sigilry/dapp.
• The canonical CIP-103 OpenRPC schema lives at packages/dapp/api-specs/openrpc-dapp-api.json.
• Zod schemas are generated into packages/dapp/src/generated from that OpenRPC source.
• For per-method conformance status see CIP-103 Conformance.