# OpenZeppelin Contracts for Cairo packages Starknet components as Scarb dependencies

> OpenZeppelin Contracts for Cairo is a library of smart contract components written in Cairo for Starknet, consumed through Scarb.toml as either the whole library or individual packages. The design leans on composable components with hooks, and the project is explicit that using the library is not a substitute for a security audit.

**OpenZeppelin/cairo-contracts** — OpenZeppelin Contracts written in Cairo for Starknet, a decentralized ZK Rollup

- Repository: https://github.com/OpenZeppelin/cairo-contracts
- Website: https://docs.openzeppelin.com/contracts-cairo
- Stars: 908 · Forks: 397
- Language: Rust
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/openzeppelin-cairo-contracts

## A library of Starknet components rather than a set of copyable contracts

OpenZeppelin Contracts for Cairo is described as a library for secure smart contract development, written in Cairo for Starknet, which the project calls a decentralized ZK Rollup. The word library is doing real work here. Instead of a folder of Solidity files you copy into your project and then forget about, the components are published as Scarb packages that your build resolves from a git repository. That changes the upgrade story. A dependency pinned to a version in Scarb.toml can be inspected, diffed and bumped deliberately, whereas a copied file quietly diverges from the version everyone else is using. The intended users are Starknet teams that need standard behaviour such as a token or a controlled upgrade path, and that do not want to re-derive the security decisions each time. The project also points newcomers to Contracts Wizard for Cairo, an interactive smart contract generator, which suggests the intended starting point is generated scaffolding that then imports these components.

## Components are embedded into a contract, with hooks left open

Looking at the ERC20 example in the usage section, the pattern is visible. A contract module declares a component with the component! macro, giving it a path, a storage variable name and an event type, and then embeds the generated implementation with an abi(embed_v0) annotation so the component's external entry points appear in the contract's ABI. Storage is declared with a substorage entry pointing at the component's own Storage type, and the contract's event enum carries the component's event as a flat variant, so component events are emitted through the contract's dispatcher rather than a separate one. The contract then calls an initializer on the component with a name and symbol, and mints to a recipient. Two things stand out. First, the behaviour is mixed in rather than inherited, which is the composable way to add something like a pause switch later without a class hierarchy. Second, the example imports ERC20Component, ERC20HooksEmptyImpl and DefaultConfig, and the empty hooks implementation makes the extension point explicit: a project that needs behaviour at token lifecycle moments supplies its own hooks implementation rather than editing the component.

## Scarb.toml takes the whole library or a single package

Getting the library into a project takes three steps. You first create the project and move into it:

```bash
scarb new my_project && cd my_project
```

The new directory holds a Scarb.toml and a src folder. You then edit Scarb.toml and add the dependency:

```toml
[dependencies]
openzeppelin = "4.0.1"
```

That single entry pulls in the entire library. The documentation also shows the alternative of taking one package, which the project recommends to improve build time by not including modules you will not use:

```toml
[dependencies]
openzeppelin_token = "4.0.1"
```

The build then fetches the sources and compiles your project:

```bash
$ scarb build
Updating git repository https://github.com/OpenZeppelin/cairo-contracts
Compiling my_project v0.1.0 (~/my_project/Scarb.toml)
Finished release target(s) in 6 seconds
```

The environment prerequisite is Cairo and Scarb, and the project links to the Scarb download instructions rather than bundling an installer. Note the version pin: 4.0.1 is the release the documentation was written against, and the two dependency forms are alternatives rather than a combined list.

## Working on the library itself means clone, build and snforge test

Contributors work from a clone rather than from the published package. The setup is short:

```bash
git clone git@github.com:OpenZeppelin/cairo-contracts.git
```

You move into the checkout and build it, and the -w flag on the build brings in the workspace packages:

```bash
cd cairo-contracts
scarb build -w
```

The test suite runs through snforge:

```bash
snforge test -w
```

The repository layout backs this up. Alongside the top level Scarb.toml and Scarb.lock there is a packages directory holding the individual published packages, a src directory, a benches directory, a scripts directory, and a sncast_scripts directory. A Makefile sits at the top for the benchmark tooling, a CHANGELOG.md tracks changes between versions, RELEASING.md and DEVELOPMENT.md document the release and development process, and AGENTS.md gives instructions for coding agents working in the tree. The workflow is conventional for Cairo: a workspace, a package manifest, a test runner, and a build that fetches dependencies over the network.

## Contract size changes are tracked as a build artifact, not a footnote

The Makefile at the repository root is small and it is about size. It defines a benchmark script path, a diff script path, a previous results file at benches/contract_sizes.json and a target directory of target/release, and it exposes two targets. The first runs the diff script over the benchmark script and the previous JSON in normal output form:

```bash
	python3 $(DIFF_SCRIPT) $(BENCHMARK_SCRIPT) $(PREVIOUS_JSON) --dir $(TARGET_DIR)
```

The second produces the same comparison as Markdown:

```bash
	python3 $(DIFF_SCRIPT) $(BENCHMARK_SCRIPT) $(PREVIOUS_JSON) --dir $(TARGET_DIR) --markdown
```

This is a reasonable answer to a problem that contract libraries have and that users of a copy and paste library never see. On a chain with contract size limits, a component library can push a project over a deployment threshold, and the failure appears at deploy time. Keeping a stored measurement of contract sizes and diffing it against a new build turns that into a visible number in continuous integration. The Makefile variables can be overridden from the command line, which suggests the benchmark is also run for release comparison rather than only for local development.

## The project states that the library is not an audit

The security section is unusually direct, and it is the part of the documentation that should decide your adoption. OpenZeppelin says the project is maintained with the goal of providing a secure and reliable library of smart contract components for the Starknet ecosystem, and it lists how it addresses security: risk management across areas such as engineering and open source best practices, scoping and API design, multi-layered review processes, and incident response preparedness. Details live in SECURITY.md, and past audits are collected in the audits directory. Then the sentence that matters for an adopter: although OpenZeppelin is well known for its security audits, using OpenZeppelin Contracts for Cairo is not a substitute for a security audit. The library reduces the amount of hand written contract code you own, and it does not transfer responsibility for your contract's own logic, its integration of components, or its upgrade policy. For teams that must show an audit trail, the audits directory is a starting point for questions, not a substitute for one.

## Where the library is the wrong choice, and what the alternatives cost

Two situations point away from this project. If you are deploying to an EVM chain, these components do not apply, because the code is written against Starknet interfaces and Cairo tooling, and no amount of configuration bridges that. If your contract needs a behaviour the library does not implement, you end up writing it yourself anyway, and the component model means your code sits beside audited code rather than inside it, so the review surface of your own logic does not shrink. The alternative shapes are worth naming. One is to write the whole contract yourself and keep full control of the code, at the cost of owning every standard behaviour and its edge cases. Another is the interactive route: Contracts Wizard for Cairo generates a project skeleton, which is faster than starting from an empty Scarb.toml and still lands you in the same component model. A third is to depend on the full openzeppelin package rather than per package packages, trading build time for the guarantee that every module is present at the same version.

## MIT licence, recent releases and a versioned upgrade path

The licence field on the repository says MIT, and the project repeats that OpenZeppelin Contracts for Cairo is released under the MIT licence, with the LICENSE file at the repository root. That is a permissive licence with no copyleft obligation, though the NOTICE-style obligations of an audit and the licence of any code you copy in still deserve a look before commercial release. On versions, the repository is not archived and the last push was on 2026-10-14. The recent release history shows v4.0.1 on 2026-08-26, v4.0.0 on the same day, and the v4.0.0-rc.1 release candidate on 2026-05-18, so the 4.x line is current and the dependency example in the documentation already points at it. A major version jump is the kind of change that deserves a diff of the CHANGELOG before you bump the pin in Scarb.toml, because component storage layouts and initializers are the kind of details that break a deployed contract silently.

## Conclusion

Adopt this library when you are shipping on Starknet and would rather not write token, access control or upgradeable account logic from scratch, because the components arrive as a versioned Scarb dependency and each package can be taken alone. Do not adopt it as a way to skip a review of your own contract, since the project states that using it is not a substitute for a security audit, and do not expect a Starknet component to run on an EVM chain. Before you commit, read the CHANGELOG.md between the version in your Scarb.toml and the current release, check the audits directory for past work on the specific component you rely on, and confirm that the package split you choose still contains every module your contract imports.

## FAQ

### How do I add OpenZeppelin Contracts for Cairo to a Scarb project?

Create the project with scarb new my_project, then add openzeppelin = "4.0.1" under [dependencies] in Scarb.toml and run scarb build. You can also depend on a single package such as openzeppelin_token to avoid pulling in modules you do not use.

### Is using OpenZeppelin Contracts for Cairo the same as getting an audit?

No. The project states explicitly that using OpenZeppelin Contracts for Cairo is not a substitute for a security audit, even though it points to SECURITY.md and a directory of past audits.

### How do I write an ERC20 contract with the Cairo components?

Declare the ERC20 component with a storage and event binding, embed its implementation so the ABI is exposed, and call the component initializer with a name and symbol before minting to a recipient. The usage example in the README shows the full contract with the ERC20Component, ERC20HooksEmptyImpl and DefaultConfig imports.

### How do I run the test suite for cairo-contracts?

Clone the repository, move into the checkout, run scarb build -w to build the workspace, and then run snforge test -w to execute the tests.

## Sources

- [License: MIT](https://github.com/OpenZeppelin/cairo-contracts/blob/main/LICENSE)
- [OpenZeppelin/cairo-contracts on GitHub](https://github.com/OpenZeppelin/cairo-contracts)
- [Project website](https://docs.openzeppelin.com/contracts-cairo)
- [README](https://github.com/OpenZeppelin/cairo-contracts/blob/main/README.md)
- [Releases](https://github.com/OpenZeppelin/cairo-contracts/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openzeppelin-cairo-contracts