Marc JuchliOriginal post
Oct 22, 2025
Hi all,
I’ve been working on the Canton Network application layer for the better part of this year, focusing on simplifying how developers can build dApps and how users can interact with data and assets residing on the validator of their choice.
As more institutions launch wallets, custody services, and marketplaces on Canton — and as the number of ledger-integrated apps continues to grow — we’ve reached a point where developers need a simpler and more consistent way to enable user interaction with the network and the deployed apps. Connecting UIs and backends directly via gRPC or the JSON-Ledger API has proven too fragmented for scalable app development.
To address this, we’re introducing the dApp API and dApp SDK — a unified framework for building Canton-native dApps that let users connect through any validator and sign using the method of their choice.
Before sharing the detailed API specification, I’d like to outline the underlying philosophy and get your feedback.
We believe that standardizing this interaction model will unlock a new wave of Canton-based applications — from DeFi-style utilities to institutional settlement services — without forcing each to reimplement fundamental primitives like signing, session management, or contract query logic.
In a follow-up message, I’ll share a presentation summarizing our development progress so far, and we’d greatly appreciate your feedback.
Does this direction align with what you’d expect from a Canton dApp development standard?
I’ve been working on the Canton Network application layer for the better part of this year, focusing on simplifying how developers can build dApps and how users can interact with data and assets residing on the validator of their choice.
As more institutions launch wallets, custody services, and marketplaces on Canton — and as the number of ledger-integrated apps continues to grow — we’ve reached a point where developers need a simpler and more consistent way to enable user interaction with the network and the deployed apps. Connecting UIs and backends directly via gRPC or the JSON-Ledger API has proven too fragmented for scalable app development.
To address this, we’re introducing the dApp API and dApp SDK — a unified framework for building Canton-native dApps that let users connect through any validator and sign using the method of their choice.
Before sharing the detailed API specification, I’d like to outline the underlying philosophy and get your feedback.
We see three main categories of clients that will rely on the dApp API and SDK:
At the UX level, the standard aims to enable:
- Wallet and custody solution providers: responsible for identity, authorization, and signing. These would implement the dApp API to allow their users to interact with dApps while signing transactions through their service.
- User-facing dApps: which bring on-ledger actions (such as transfers, settlements, or governance) to web or mobile interfaces.
- Application backends: which issue, query, and manage contracts on the Canton ledger.
At the UX level, the standard aims to enable:
- A consistent flow for connecting wallets to dApps (similar to EIP-1193, with potential for a WalletConnect-style extension).
- Declarative methods for signing and submitting ledger actions using a signing provider of choice.
- A uniform event model that allows dApps to react to ledger updates (such as contract creation or settlement completion) in real time.
- A simplified developer SDK that abstracts away ledger APIs, authentication, and transport details — allowing developers to focus on business logic rather than infrastructure.
We believe that standardizing this interaction model will unlock a new wave of Canton-based applications — from DeFi-style utilities to institutional settlement services — without forcing each to reimplement fundamental primitives like signing, session management, or contract query logic.
In a follow-up message, I’ll share a presentation summarizing our development progress so far, and we’d greatly appreciate your feedback.
Does this direction align with what you’d expect from a Canton dApp development standard?
Are there specific integration patterns or developer workflows you think we should prioritize in the SDK?
Looking forward to your thoughts,
Marc
--
Looking forward to your thoughts,
Marc
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.