OpenZeppelin Contracts for Cairo packages Starknet components as Scarb dependencies

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:

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:

[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:

[dependencies]
openzeppelin_token = "4.0.1"

The build then fetches the sources and compiles your project:

$ 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:

git clone [email protected]:OpenZeppelin/cairo-contracts.git

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

cd cairo-contracts
scarb build -w

The test suite runs through snforge:

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:

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

The second produces the same comparison as Markdown:

	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.

Editorial 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.

Frequently asked questions

Official sources

1. License: MIT
2. OpenZeppelin/cairo-contracts on GitHub
3. Project website
4. README
5. Releases