Thanks for your interest. Contributions are welcome for both the smart contracts (contracts/) and the web app (web/).
Never push directly to main or dev. All changes come in through pull requests.
main ← production-ready; merged from dev after review
└── dev ← integration branch; all PRs target this
└── your-feature-branch
- Fork the repository to your own GitHub account.
- Clone your fork, then
cd web && npm install. - Create a branch off
dev— notmain, notdevitself:git checkout dev git pull upstream dev git checkout -b feat/flexible-vault-permit
- Make your changes. Keep each branch focused on one thing.
- Commit using the pattern below.
- Push to your fork and open a PR targeting
dev. - After review and CI passes, a maintainer merges to
dev. - Periodically,
devis merged intomainfor a release.
feat/<short-description> new feature
fix/<short-description> bug fix
chore/<short-description> tooling, config, deps
docs/<short-description> documentation only
test/<short-description> tests only
refactor/<short-description> no behaviour change
Examples: feat/fixed-vault-permit, fix/verify-chainid-param, docs/architecture-diagram
Use Conventional Commits:
<type>(<scope>): <short summary in present tense>
[optional body — explain the why, not the what]
[optional footer — breaking changes, closes #issue]
Types: feat · fix · chore · docs · test · refactor · style
Scopes: contracts · web · ci · scripts · deps
Examples:
feat(contracts): add depositWithPermit to FlexibleVault
fix(contracts): append ?chainid to Etherscan V2 verifier URL
docs(contracts): add ARCHITECTURE.md with deployment addresses
test(contracts): add invariant for FixedVault balance coverage
chore(web): upgrade wagmi to v2.13
ci: pin foundry-toolchain to v1
Keep the summary line under 72 characters. Use the body when the reason for the change isn't obvious from the diff.
- Target branch:
dev— PRs tomainwill be closed. - Title: follow the same
type(scope): summaryformat as commits. - Description: what changed and why; link any related issue.
- Keep PRs small — one logical change per PR is easier to review.
- Make sure CI is green before requesting review (format, build, tests).
cd contracts
forge fmt # format (CI runs forge fmt --check)
forge build # must compile cleanly
forge test -vvv # all tests must passcd web
npm run lint # eslint must pass
npm run build # production build must succeed