[Feedback welcome] OpenZeppelin’s Daml development stack is public and open for review
Hi Canton community,
The first repos of OpenZeppelin's open-source Daml development stack for Canton are now public, and we're looking for your feedback. Test it, read the designs, and let us know how it works for what you're building, or where you would like to see improvements.
This release includes a Daml contracts library with an implementation of the CIP-0112 token and settlement standard, and reference-implementation designs for the ecosystem's common financial use cases. It's built to the same standard as OpenZeppelin's libraries across Ethereum and other leading ecosystems, which have underpinned over $35 trillion in onchain transfers.
Full details:
Token standard and settlement foundation
The specs repo consolidates a token template, a stablecoin reference, and the CIP-0112 settlement primitive.
- CIP-0112 (Token Standard V2) is backward compatible with CIP-0056 and adds settlement and further features.
- The settlement primitive includes the atomic settlement logic the reference implementations build on, rather than each application reimplementing it.
- The interop exemplars for CIP-0086, CIP-0103, and CIP-0104 can be validated against a LocalNet ledger over gRPC with ./scripts/localnet-cip-interop-validation.sh, which demonstrates the implementations working together rather than in isolation.
Repos:
Reference-implementation designs
Architecture and design documents for the first four reference implementations, each a documented architecture for a specific financial application. These are design documents only; implementation code begins in the next milestone and is not present in these repos.
- Privacy-preserving DEX: exchange design using atomic settlement as the core primitive, with a modular structure extending to AMM and other venue types.
- Lending protocol: lending-market design built on the same settlement core.
- Cross-chain stablecoin payments: stablecoin payment flow spanning Canton and external chains, with reserve and attestation controls.
- Confidential auction launchpad: sealed-bid auction design using Canton's privacy model.
Repos:
- OpenZeppelin Canton Privacy-preserving DEX
- OpenZeppelin Canton Institutional Lending protocol
- OpenZeppelin Canton Crosschain stablecoin payments
- OpenZeppelin Canton Confidential auction launchpad
Review and feedback are welcome
Clone the repos, read the design reports, and open an issue with how it works for what you're building, or where it should change.
Note that development is still in progress, and these components haven’t been audited yet. All releases will undergo full security audit after collecting community feedback.
Pepe Blasco
Engineering Manager, OpenZeppelin- Congrats on shipping this in the open. We reviewed the stack at ZeroVaultID, with a focus on the CIP-0112 compliance attestation path, since it's close to our own work on Canton.
Strong points worth calling out: the threat model is unusually candid about what an attestation does and does not represent, and canton-contracts documents its D1 binding rationale clearly.
One piece of feedback: the D1 code snippets in the reference architecture documents do not match either CIP-0112 implementation (fetchByKey registry resolution and attestationCid as a direct choice field). Details and suggested resolutions in canton-specs issue #82: https://github.com/OpenZeppelin/canton-specs/issues/82
Happy to be told any of it is deliberate simplification. Looking forward to where the CIP-0112 work goes. - Hi OpenZeppelin team,
Thank you for sharing the settlement experiment — this is a genuinely valuable contribution to the Canton ecosystem. The two-phase AllocationInstruction/Allocation flow, the Optional Lock on holdings, the D1/D2 compliance hooks, and the SettlementReceipt/EventLog pattern are exactly the kind of reference material the community needs.
We have been building a similar settlement framework on Canton for the otcDigital marketplace and have been studying your contracts closely. We posted separately on a related topic — the absence of a first-class on-ledger Account concept in both CIP-0112 and your settlement experiment — and made some specific observations about how Account appears in your model. You may find that thread relevant.
One assumption we made in that post: we noted that your fixture types carry different Daml package IDs from the Splice interfaces, and assumed this was because including Splice DAR binaries in an open-source repository is not possible due to licensing. If that assumption is wrong, or if there is a path you are aware of for open-source Canton implementations to interoperate with Splice-based production networks, we would be very interested to hear it — it is directly relevant to how broadly the account standard could apply.
Thanks again for the work.
Mani Pillai, mani@...