Contribution Guidelines
How to propose changes, report bugs, and join the community.
We welcome contributions from the community! Whether you're fixing a typo, adding a new opcode, or writing a tutorial, your help makes Matador better for everyone.
Getting Started
Find an Issue
Browse our GitHub Issues to find something to work on. Look for the good first issue label if you're new.
Fork & Branch
Fork the repository and create a new branch for your work.
git checkout -b feat/my-new-featureImplement & Test
Make your changes. Ensure you add tests for any new logic!
- Contracts: Add tests in
contracts/tests/ - Compiler: Add tests in
dsl/packages/*/test/
Submit PR
Push your branch and open a Pull Request. Please follow the PR template and link to the issue you are solving.
Coding Standards
We enforce strict coding standards to keep the codebase clean and secure.
Solidity
- Style: Follow the Solidity Style Guide.
- Naming:
PascalCasefor contracts,camelCasefor functions/vars,UPPER_CASEfor constants. - NatSpec: All public interfaces must have NatSpec documentation.
TypeScript
- Style: We use
eslintandprettier. Runnpm run lintto check your code. - Types: Avoid
any. Define interfaces for all data structures.
Commit Messages
We follow the Conventional Commits specification. This allows us to automatically generate changelogs.
<type>(<scope>): <description>| Type | Description | Example |
|---|---|---|
feat | A new feature | feat(interpreter): Add BLOBBASEFEE opcode |
fix | A bug fix | fix(cli): Resolve path issue on Windows |
docs | Documentation only | docs: Update API reference for v1.2 |
test | Adding missing tests | test(core): Add fuzzing for stack overflow |
chore | Build/Tooling changes | chore: Upgrade Foundry dependencies |
Documentation
Documentation contributions are highly encouraged!
- Typos: Feel free to fix typos directly via a PR.
- New Guides: If you want to write a new guide, please open an issue first to discuss the topic.
- Templates: Use our standard MDX components (
Steps,Callout,Cards) to maintain visual consistency.
Review Process
We aim to review all PRs within 48 hours. Please be responsive to feedback. Once approved, a maintainer will merge your changes.