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.
The library provides the following packages under packages/:
| Component | Package | Public module |
|---|---|---|
| Scoped Authorization Grant | openzeppelin-scoped-authorization-grant-v1 |
OpenZeppelin.ScopedAuthorizationGrantV1 |
| Pausable API | openzeppelin-api-pausable-v1 |
OpenZeppelin.Api.PausableV1 |
| Pausable | openzeppelin-pausable-v1 |
OpenZeppelin.PausableV1 |
| Token CIP-0112 types | openzeppelin-token-cip112-types-v1 |
OpenZeppelin.Token.Cip112.TypesV1 |
| Token CIP-0112 utils | openzeppelin-token-cip112-utils |
OpenZeppelin.Token.Cip112.Utils |
| Token CIP-0112 | openzeppelin-token-cip112-v1 |
OpenZeppelin.Token.Cip112.V1 |
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.
- DPM
- Java 21+
The workspace declares its Daml SDK in
multi-package.yaml. Package manifests mirror that value
for standalone builds, and repository checks keep them synchronized. The SDK is
3.5.8; packages target LF 2.1.
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 --allTo build one component independently:
DAML_PACKAGE=packages/access/scoped-authorization-grant-v1 dpm buildThe resulting DAR is written to:
packages/access/scoped-authorization-grant-v1/.daml/dist/openzeppelin-scoped-authorization-grant-v1-0.1.0.dar
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/access/scoped-authorization-grant-v1/.daml/dist/openzeppelin-scoped-authorization-grant-v1-0.1.0.darimport qualified OpenZeppelin.ScopedAuthorizationGrantV1 as SAG
Each package README.md shows the consumer code for that component, and
examples/ holds runnable consumer projects.
packages/ Library components and release candidates access/ Authorization components security/ Emergency-stop and safety components token/ Category for token standard and settlement components test/ Isolated library test packages dars/ released/ Immutable OpenZeppelin release baselines vendor/ Verified third-party DAR inputs examples/ Integration examples and sibling -test packages 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.
- A component whose choice bodies consumers reuse with their own templates
ships them in an `openzeppelin-<component>-utils` package that defines no
templates, interfaces, exceptions, or serializable types, and ships the
records its templates store in an `openzeppelin-<component>-types-vN`
package. SCU ignores a utils package, so it versions by semver alone, and a
consumer can move to any later version or drop it.
- 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](ARCHITECTURE.md) for the full rationale and dependency
rules, and [RELEASING.md](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](SECURITY.md) to report a vulnerability
privately.
## Contributing
See [CONTRIBUTING.md](CONTRIBUTING.md) for development setup, package boundaries,
testing requirements, and the checklist for new components.
## Related projects
- [Canton Improvement Proposals](https://github.com/canton-foundation/cips) - canonical Canton standards
- [OpenZeppelin Canton specs](https://github.com/OpenZeppelin/canton-specs) - research, prototypes, reference architectures, and interoperability evidence
- [OpenZeppelin Canton ecosystem-stack proposal](https://github.com/canton-foundation/canton-dev-fund/blob/main/proposals/2026-04-OpenZeppelin-canton-ecosystem-stack.md) - ecosystem program context
## License
[MIT](LICENSE), except where a file states otherwise. Files in the CIP-0112
token packages that contain code derived from the Splice TestTokenV2 example
or the Splice `splice-token-standard-utils` package
(https://github.com/canton-network/splice/tree/8460154135f39019b8bb370c9c1321ff13c9bb10/token-standard/)
carry Digital Asset's copyright notice and are licensed `MIT AND Apache-2.0`.
The `README.md` of each token package lists those files and the Splice modules
they derive from. The Splice DARs under `dars/vendor/` are licensed Apache-2.0. The Apache
License 2.0 text is in [`LICENSES/Apache-2.0.txt`](LICENSES/Apache-2.0.txt).