Skip to Content
⚠️ Alert: Sylan is under active development—only trust contract/wallet addresses announced on our official channels; we will never DM you, ask for funds, or run surprise airdrops/presales.
CommunityContributing

Contributing

We ❤️ contributors! This page explains how to propose changes, run the stack locally, write good issues/PRs, and follow our coding/commit standards.


Code of Conduct

We follow a standard Contributor Covenant. Be respectful, constructive, and kind. Report unacceptable behavior to the maintainers via the contact listed in the repo.


Where to start

  • Good first issues: look for the good first issue label.
  • Help wanted: labeled for items suitable for external contributors.
  • Docs: typos, clarifications, or additional examples are always welcome.

Project layout

  • /sylan-contracts — Solidity (UUPS, OZ/Solady mix); tests in Foundry/Hardhat
  • /sylan-dashboard — Next.js 15 + Tailwind 4 + shadcn/ui (repo will be available to public soon)
  • /sylan-provider — Sylan provider repo
  • /sylan-docs — Sylan docs - This site (Nextra)
  • /sylan-node — Sylan node repo

Branching & commits

  • Branch: feat/<scope>-<short-desc> or fix/<scope>-<issue#>
  • Conventional Commits: feat:, fix:, docs:, refactor:, chore:, test:
  • Lint: pnpm lint before pushing; CI will enforce lint/type checks.

Pull Requests

  • Keep PRs small and scoped; link to an issue.
  • Include: motivation, screenshots (UI), gas diffs (contracts), and tests.
  • Mark as draft if still exploring; convert to ready once stable.
  • Check CI green; fix lint and type errors.

PR checklist

  • Linked issue
  • Added/updated tests
  • Updated docs (if user‑facing change)
  • Ran pnpm -r build locally

Testing standards

  • Contracts: unit tests for happy/failure paths, storage layout checks for upgrades, fuzz on time windows.
  • SDK: test vectors for request hashing and EIP‑712 verification.
  • Dashboard: mock events and wallet flows; ensure event‑driven state updates.

Security & disclosures

  • Do not open public issues for sensitive findings. Email the main developers.
  • We run pre‑release audits; report potential vuln responsibly for recognition.

Style & docs

  • Prefer TypeScript; enable strict in tsconfig.
  • Keep comments succinct; write README updates alongside code.
  • Diagrams: use mermaid in MDX; keep under 50 lines per diagram.

Release process

  • Use semantic versioning across packages.
  • Tag releases; publish changelogs summarizing contract addresses, ABIs, and breaking changes.

Getting help

Ask in GitHub Discussions or the community channels linked on the homepage. Maintainers are happy to mentor first‑time contributors.

Last updated on