First off — thank you for taking the time to contribute! Vortex is an open-source protocol, and we welcome issues, pull requests, and discussion from anyone.
This project participates in the Drips ecosystem for sustainable open-source funding. Merged contributions to this repository may be recognized as part of our dependency/contributor funding splits, so contributing here is meaningful beyond the code itself.
This project and everyone participating in it is governed by our Code of Conduct. By participating, you are expected to uphold it. Please report unacceptable behavior to the maintainers.
Vortex is split across independent repositories under the
vortex-protocol organization:
| Repo | Stack | Description |
|---|---|---|
vortex-contract |
Rust / Soroban | On-chain intent settlement contracts |
vortex-backend |
TypeScript / Express | Intent relay API + WebSocket feed |
vortex-frontend |
TypeScript / Next.js 14 | Swap UI + solver portal |
Each repository is independently buildable. See each repo's README.md for setup.
This file lives in the org-wide
.github repository and applies to
all of them.
- Fork the repository and clone your fork.
- Create a branch from
main:git checkout -b feat/short-description
- Make your changes (see Development below).
- Ensure lint, type-check, and the contract build pass locally.
- Commit using Conventional Commits.
- Push and open a pull request against
main.
Contract (vortex-contract)
cd vortex-contract/intent_settlement # within a clone of the vortex-contract repo
cargo fmt --all
cargo clippy --all-targets -- -D warnings
cargo test
stellar contract buildBackend (vortex-backend)
npm install
npm run lint
npm run build # tsc type-check + emit
npm run devFrontend (vortex-frontend)
npm install
npm run lint
npm run build
npm run devWe follow Conventional Commits:
feat(backend): add /api/v1/tokens registry endpoint
fix(contract): reject fill after deadline
docs: clarify solver bond slashing
chore(frontend): bump next to 14.2.3
Common types: feat, fix, docs, refactor, test, chore, ci.
- Keep PRs focused — one logical change per PR.
- Reference the issue it closes (e.g.
Closes #12). - Include a clear description of what changed and why.
- Add or update tests where it makes sense.
- Make sure CI is green before requesting review.
- For UI changes, include a screenshot or short clip.
- Issues labeled
good first issueare scoped for newcomers. - Issues labeled
help wantedare ready for community pickup. - Each repo's
README.mdlists larger initiatives on its roadmap.
If you want to work on something not yet tracked, open an issue first so we can align on the approach before you invest time.
- For regular bugs, open a bug report on the relevant repo (the shared template applies org-wide).
- For security vulnerabilities, do not open a public issue — follow SECURITY.md instead.
By contributing, you agree that your contributions will be licensed under the MIT License that covers this project.