OpenZeppelin Contracts for Canton

Reusable, security-focused Daml packages for applications on Canton. Each component is an independent Daml package so applications can build, review, upload, and vet only the DARs they need.

Warning

This is experimental software and is provided on an "as is" and "as available" basis. We do not give any warranties and will not be liable for any losses incurred through any use of this code base.

Packages

The Pausable component lives under packages/ as two packages: a frozen interface package and an upgradeable package of guard functions. Neither has a release or an audit.

Component	Package	Public module	Status
Pausable API	openzeppelin-api-pausable-v1	OpenZeppelin.Api.PausableV1	Pre-release; unaudited
Pausable	openzeppelin-pausable-v1	OpenZeppelin.PausableV1	Pre-release; unaudited

Three further components are early-stage candidates under experiments/. They will be redesigned before they move into packages/, and that redesign will change module names, template and choice signatures, and package identity. Read experiments/README.md before depending on any of them.

Component	Package	Public module	Status
Access Control	openzeppelin-access-control-v1	OpenZeppelin.AccessControlV1	Experimental; unaudited
Ownable	openzeppelin-ownable-v1	OpenZeppelin.OwnableV1	Experimental; unaudited
Token CIP-0112	openzeppelin-tokenCIP112-v1	OpenZeppelin.TokenCIP112V1	Experimental; unaudited

Each component is a separate dependency and release unit. Applications select the components they use, and participant operators review and vet the matching package IDs.

Get started

Requirements

• DPM
• Java 21+

The workspace declares its Daml SDK in multi-package.yaml. Package manifests mirror that value for Daml 3.4 compatibility, and repository checks keep them synchronized.

The Canton building and packaging guide explains DPM workspaces, DARs, and data-dependencies.

git clone https://github.com/OpenZeppelin/canton-contracts.git
cd canton-contracts
dpm install
dpm build --all

To build one component independently:

cd packages/security/api-pausable-v1
dpm build

The resulting DAR is written to:

packages/security/api-pausable-v1/.daml/dist/openzeppelin-api-pausable-v1-0.1.0.dar

Consume a local build

Build a package from a pinned source commit and reference the resulting DAR from a separate Daml project:

dependencies:
  - daml-prim
  - daml-stdlib
data-dependencies:
  - ../canton-contracts/packages/security/api-pausable-v1/.daml/dist/openzeppelin-api-pausable-v1-0.1.0.dar
  - ../canton-contracts/packages/security/pausable-v1/.daml/dist/openzeppelin-pausable-v1-0.1.0.dar

import OpenZeppelin.Api.PausableV1 (Pausable, PausableView (..))
import qualified OpenZeppelin.PausableV1 as Pausable

Each package README.md shows the consumer code for that component, and examples/ holds runnable consumer projects.

Repository layout

packages/
  security/               Category for emergency-stop and safety components
test/                     Isolated component test packages
experiments/
  access/                 Category for authorization and ownership components
  token/                  Category for token standard components
  test/                   Isolated component test packages
dars/
  released/               Immutable OpenZeppelin release baselines
  vendor/                 Verified third-party DAR inputs
examples/                 Standalone projects that consume packaged DARs
audits/                   Reports keyed to exact package releases
scripts/                  Repository validation tooling

Category directories organize related components for navigation. Package names, module names, dependency declarations, and DAR identity define each component's release lineage.

Package and compatibility model

• One independently released unit is one Daml package and one DAR.
• Components defining Daml interfaces use a frozen openzeppelin-api-<component>-vN package and a separate upgradeable package for templates or helper functions. Template-only components use one implementation package.
• Breaking changes create a sibling -v2 package and V2 module suffix; compatible SCU releases retain the existing package name.
• Composition between implementations happens through interfaces or in the consuming application.
• Documented modules form the public API; implementation details use an .Internal suffix.

See ARCHITECTURE.md for the full rationale and dependency rules, and RELEASING.md for release process guidance.

Security

These packages provide reusable building blocks. A consuming application is responsible for selecting canonical contract instances, binding authority and state to the correct resource, managing disclosure, and reviewing its complete dependency graph.

Do not use a library candidate as a substitute for an application-specific security review. See SECURITY.md to report a vulnerability privately.

Contributing

See CONTRIBUTING.md for development setup, package boundaries, testing requirements, and the checklist for new components.

Related projects

• Canton Improvement Proposals - canonical Canton standards
• OpenZeppelin Canton specs - research, prototypes, reference architectures, and interoperability evidence
• OpenZeppelin Canton ecosystem-stack proposal - ecosystem program context

License

MIT