We really appreciate and value contributions to OpenZeppelin Contracts for Cairo. Please take 5' to review the items listed below to make sure that your contributions are merged as soon as possible.
Before starting development, please create an issue to open the discussion, validate that the PR is wanted, and coordinate overall implementation details.
Also, consider that snake case is used for Cairo development in general due to its strong Python bias, but in order to be compliant with the standards, EIP implementations must use camelCase. Therefore, EIP-based contracts will have their external functions written in camelCase while the rest of the codebase will be in snake_case.
And make sure to always include tests and documentation for the new developments. Please consider the following conventions:
-
Naming
- libraries should be named
library.cairo
, e.g.erc20/library.cairo
- contracts should be PascalCased i.e.
MyContract.cairo
- interfaces should be prefixed with an
I
, as inIAccount.cairo
- test modules should begin with
test_
followed by the contract name i.e.test_MyContract.py
- libraries should be named
-
Structure
- libraries should cede their names to their parent directory and are named
library.cairo
instead - interfaces should be alongside the library that the interface defines
- preset contracts should be within a
presets
directory of the library to which they are a preset - Here are example paths:
openzeppelin.token.erc20.library
openzeppelin.token.erc20.IERC20
openzeppelin.token.erc20.presets.ERC20Mintable
- And a visual guide:
- libraries should cede their names to their parent directory and are named
openzeppelin
└──token
└── erc20
├── library.cairo
├── IERC20.cairo
└── presets
└── ERC20Mintable.cairo
As a contributor, you are expected to fork this repository, work on your own fork and then submit pull requests. The pull requests will be reviewed and eventually merged into the main repo. See "Fork-a-Repo" for how this works.
-
Make sure your fork is up to date with the main repository:
cd cairo-contracts git remote add upstream https://github.com/OpenZeppelin/cairo-contracts.git git fetch upstream git pull --rebase upstream main
NOTE: The directory
cairo-contracts
represents your fork's local copy. -
Branch out from
main
intofix/some-bug-#123
:(Postfixing #123 will associate your PR with the issue #123 and make everyone's life easier =D)
git checkout -b fix/some-bug-#123
-
Make your changes, add your files, commit, and push to your fork.
git add SomeFile.js git commit "Fix some bug #123" git push origin fix/some-bug-#123
-
Run tests, linter, etc. This can be done by running local continuous integration and make sure it passes.
tox # stop the build if there are Markdown documentation errors tox -e lint
-
Go to github.com/OpenZeppelin/cairo-contracts in your web browser and issue a new pull request. Begin the body of the PR with "Fixes #123" or "Resolves #123" to link the PR to the issue that it is resolving. IMPORTANT Read the PR template very carefully and make sure to follow all the instructions. These instructions refer to some very important conditions that your PR must meet in order to be accepted, such as making sure that all PR checks pass.
-
Maintainers will review your code and possibly ask for changes before your code is pulled in to the main repository. We'll check that all tests pass, review the coding style, and check for general code correctness. If everything is OK, we'll merge your pull request and your code will be part of OpenZeppelin Contracts for Cairo.
IMPORTANT Please pay attention to the maintainer's feedback, since its a necessary step to keep up with the standards OpenZeppelin Contracts attains to.
If you have any questions, feel free to post them to github.com/OpenZeppelin/cairo-contracts/issues.
Finally, if you're looking to collaborate and want to find easy tasks to start, look at the issues we marked as "Good first issue".
Thanks for your time and code!