CIP-0103: dApp API - Towards Canton Network dApp Support
- 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 see three main categories of clients that will rely on the dApp API and SDK:- 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--
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. - Dear all,
Attached you’ll find the presentation mentioned earlier.
The slides outline the key concepts behind the dApp API, our current development progress, and a preview of how the dApp SDK can be integrated into an application. They also include links to relevant resources, such as the GitHub repository containing the implementation and an example dApp.We’d greatly appreciate your feedback and any general remarks. Our goal is to align the community around this effort and evolve it further by incorporating your insights and suggestions.
Kind regards
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. - I think this is a really welcome development and will definitely accelerate speed of app development (and focus on the differentiators rather than needing to reinvent the wheel, as you say).As a broad feedback, I'd love to also see something (probably a future iteration) that files the role of viem on Canton Network too. Any EVM dApp, this (and wagmi, if in React) is always my first install.
Know that we have some of this already through type bindings, but making it easy to e.g. pull type safe events from TX receipt logs, etc, or watching live on-chain via a websockets client is a really good puzzle piece to have pre-built. (Apologies if these don't map directly to the Canton ecosystem, I'm still a rookie in DAML dApp development yet!)
I know that a lot of these are already strongly typed in Canton, but just having the "one higher level of abstraction" lib I think would be great to have on the roadmap - We at Lightshift support and welcome this change. It'll make user onboarding much more productive and bridge canton experiences across different wallet providers. Wallet integration is one of the largest barriers atm building on Canton and it's logistically challenging both for builders and wallet providers. Having a N+1 integration layer would enable both parties to offer their services much more efficiently on the network.
- Dear CIP editors and community,
Over the past weeks, we have discussed the dApp Standard proposal on this mailing list.We have incorporated feedback from wallet providers, SDK authors, and dApp developers across the Canton ecosystem.
The proposal defines a vendor-neutral, transport-agnostic dApp API that decouples decentralized applications from wallet implementations while standardizing ledger access, signing flows, and error semantics. It introduces both synchronous and asynchronous variants to support client-side and server-side wallet deployments under a single interoperable model.
We believe the proposal has now reached sufficient maturity and would like to formally request that it:
- be assigned a CIP number, and
- be moved to Review status.
The proposal includes:
- a complete specification with normative language,
- OpenRPC definitions as the ground truth,
- reference implementations and SDKs,
- and documented design rationale, including alignment with existing ecosystem standards (e.g. EIP-1193 and CAIP conventions).
In particular, confirmation or feedback from additional wallet providers and infrastructure maintainers would be highly appreciated.
Thank you for your time and for maintaining the CIP process.
Best regards,
Marc Juchli - hi everyonehave had a couple convos with builders on this topic, it seems we are ready to take this to voteDA Sponsors this CIP - any endorsers?On Thu, Oct 23, 2025 at 6:45 AM marc.juchli via lists.sync.global <marc.juchli=digitalasset.com@...> wrote:Dear all,
Attached you’ll find the presentation mentioned earlier.
The slides outline the key concepts behind the dApp API, our current development progress, and a preview of how the dApp SDK can be integrated into an application. They also include links to relevant resources, such as the GitHub repository containing the implementation and an example dApp.We’d greatly appreciate your feedback and any general remarks. Our goal is to align the community around this effort and evolve it further by incorporating your insights and suggestions.
Kind regards
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.
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. - toggle quoted message Show quoted textHappy to endorse Eric.On Wed, Jan 21, 2026 at 20:04 Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:hi everyonehave had a couple convos with builders on this topic, it seems we are ready to take this to voteDA Sponsors this CIP - any endorsers?On Thu, Oct 23, 2025 at 6:45 AM marc.juchli via lists.sync.global <marc.juchli=digitalasset.com@...> wrote:Dear all,
Attached you’ll find the presentation mentioned earlier.
The slides outline the key concepts behind the dApp API, our current development progress, and a preview of how the dApp SDK can be integrated into an application. They also include links to relevant resources, such as the GitHub repository containing the implementation and an example dApp.We’d greatly appreciate your feedback and any general remarks. Our goal is to align the community around this effort and evolve it further by incorporating your insights and suggestions.
Kind regards
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.
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. - Hi all,
We'd like to propose an amendment to the ledgerApi method of the dApp API specified in CIP-0103. This amendment standardizes some additional, optional request parameters to better represent possible HTTP requests (path, query, headers). It also drops the JSON-to-string serialization of the request and response bodies, allowing implementations to provide richer type definitions for these objects in TypeScript.Please view the amending pull-request here: https://github.com/canton-foundation/cips/pull/173
Let us know if you have any feedback or questions.
Sincerely,
Alex Matson
(Digital Asset) - Dear all,I'd be happy to see this amendment endorsed/approved.Given that this is a very small change, I expect it to be no problem for the wallet providers. However, if you have any questions, please do not hesitate to reach out to me.Kind regardsMarcOn Tue, Mar 10, 2026 at 2:35 PM alex.matson via lists.sync.global <alex.matson=digitalasset.com@...> wrote:Hi all,
We'd like to propose an amendment to the ledgerApi method of the dApp API specified in CIP-0103. This amendment standardizes some additional, optional request parameters to better represent possible HTTP requests (path, query, headers). It also drops the JSON-to-string serialization of the request and response bodies, allowing implementations to provide richer type definitions for these objects in TypeScript.Please view the amending pull-request here: https://github.com/canton-foundation/cips/pull/173
Let us know if you have any feedback or questions.
Sincerely,
Alex Matson
(Digital Asset)--
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. Send endorses the amendment in PR #173.
It materially improves the DX when integrating with the dApp API. Dropping the serialization provides for richer type information as well as the additional params present more informative interface.
Allen Eubank Send
