[Feedback welcome] OpenZeppelin’s Daml development stack is public and open for review

App Development
,
1

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-112 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-112 settlement primitive.

  • CIP-112 (Token Standard V2) is backward compatible with CIP-56 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-86, CIP-103, and CIP-104 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:

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

2

The privacy-preserving DEX and cross-chain stablecoin payment designs immediately caught my attention. It’s great to see reusable building blocks becoming available for the ecosystem. Thanks for sharing these resources with the community.

3

Our implementation of the new stack for our yielding and on-yielding stablecoins and agentic registry on Canton using this standard

4

Awesome stuff! I noticed that all the DAML code are using AGPL license. Is that intentional?

5

Thanks for putting these out for review. We spent most of our time in lending.md, and section 7 (Open Design Questions) is the part closest to our own work. On Compound we implemented the CAPO oracle for the correlated-collateral case, built the reserve-growth tracking, and we operate Compound Labs’ Configurator pattern on the markets we deploy. Several of the section 7 questions are things we handle in production.

One observation from that side: oracle-induced risk and market risk fail differently and want separate controls. Your maxStaleness field already points that way. We wrote up the correlated-collateral case here: Correlated collateral and the parameter layer: notes for Canton vault builders

The question we’d like your read on is scope. Buffer sizing, debt ceilings, the change path for VaultParams, stress evidence for the insurance fund: is any of that planned for the reference implementations in M2 or M3, or does it stay a layer that implementers bring? We ask because that layer, parameter governance and calibration on Zenith, is what our open Dev Fund proposal covers (Proposal: Canton Risk Engine by Noosphere-314 · Pull Request #665 · canton-foundation/canton-dev-fund · GitHub). If you’re already building it we’d rather know now. If you aren’t, we’d rather compose with your stack than build something that sits awkwardly next to it.

Glad to go further on any of this, in whatever format is useful to you.

6

  1. Thanks @woof-software, this is useful feedback.

    For context, the reference implementations are not products we will deploy. They are complete, audited starting points that teams fork and operate. That draws the line like this:
    We will be implementing the baseline parameter surface and its change path. VaultParams, maxStaleness, maxDeviation, the oracle interface requirements, role transfer through access control and ownable, and the SCU rules for adding fields such as a debt ceiling.

    We do not own calibration. Buffer and grace-window sizing, ceiling values, insurance-fund stress evidence, and shock testing depend on the collateral, the market, and the operator. We document the questions in section 7 so that a fork knows what it must answer, but we do not plan to ship a risk engine or a simulator.

    So your proposal does not overlap with ours. It fills the layer we leave to operators. What matters is that the two compose cleanly, and I see two seams:

    1. Parameter governance. Your registry with propose-execute windows and execution-time validation is a natural author for VaultParams updates.
    2. Oracle implementation. The RI specifies the PriceOracle interface and the requirements on the update mechanism, not the mechanism.

    The current design is an initial architecture document. It will evolve as we get start the implementation, and that is the right point to align on the two seams above.

    Thanks again for the interest!

7

Hey @zhe_bd, thanks for your interest!

The libraries (daml code) that we will be developing going forward are MIT license: GitHub - OpenZeppelin/canton-contracts: OpenZeppelin library for secure smart contract development on Canton · GitHub

The tooling systems will be AGPL license.

If you are interested in using the tools are have any conflict with the licensing, feel free to reach out and we can look at your usecase directly.

8

I took up the invitation to test these. I made each assertMsg/ensure condition vacuous one at a time, rebuilt the DAR, and re-ran the suites: 52 of 69 fences can be removed with every test still passing — 3/7 in access-control-v1, 24/32 in simple-token, 25/30 in stablecoin.

Not vulnerabilities: every fence is present and correct. But you described these as audited starting points that teams fork and operate, and a fork inherits the suite — so this is what it will and won’t catch when someone changes the code later.

Method, the controls, and the three defects in my own harness that produced false findings first: cantor8_kya_rails/docs/findings-openzeppelin.md at 2c4948ff3b25d2e24fda2f2ca7e8537d8ea57164 · dominicrume/cantor8_kya_rails · GitHub

Filed per repo: canton-contracts#43, canton-token-template#9, canton-stablecoin#9.

Happy to be told any of these are deliberately redundant or covered by a test my harness can’t attribute.

9

You mentioned an agentic registry alongside the stablecoins.

Does anyone ever ask you to prove your agent didn’t do something?

10

Yes, we support deterministic settlement by agents.

what do you have in mind?

11

I built a way to keep a record of what an agent tried to do, including the
attempts that get blocked. Anyone can check it without trusting whoever
wrote it.

What does deterministic settlement give you when an agent gets blocked?