Two paths in: feedback inbox, or PR.
Most external contribution lands as structured friction in the docs/feedback/inbox/ directory on the SDK repo. PRs are welcome too, read this first.
docs/feedback/inbox/<date>-<slug>.md
The friction loop. Bounty-cohort developers, outside-in agents, and design partners drop entries here. The feedback-triager runs every cycle; major entries become docs / SDK PRs.
File format: frontmatter with severity (blocker / major / minor / nit), surface (e.g. @tokenops/sdk/fhe-vesting), consumer (your role: integrator, indexer, etc.). Body: one paragraph of what you tried, what failed, what you expected, where it points.
Reference shape: docs/feedback/inbox/ on the SDK repo. The triager scans the directory weekly. Reach out via feedback@tokenops.xyz for repo-access questions during the bounty cohort.
What's mergeable
Bug fixes
Reproducible test + fix. The SDK's vitest harness prefers the failing-test-first pattern. Run pnpm typecheck + pnpm test + pnpm lint before opening.
Docs
Recipes, concept pages, hook-detail polish, file PRs directly against the docs repo (tokenops-docs). Match the voice in STYLE-GUIDE.md (direct, evidence-backed, no marketing copy).
New hooks / methods
Open a feedback-inbox entry first. The SDK's API surface is narrow on purpose, additions need to fit the existing pattern (per-method = per-hook, encryptor source passed through, TSDoc with @example).
Breaking changes
Discuss in an inbox entry first; tag it severity: blocker. We'll version-bump via a major release with migration notes.
The contribution bar
Tests pass locally. The SDK ships its own FHEVM bring-up via pnpm fhevm:up; tests run against a real Anvil + forge-fhevm coprocessor, not mocks. Read CLAUDE.md in the SDK repo before writing tests for a new module.
No dead code.If a feature you added gets cut in review, delete it cleanly, don't comment it out.
Conventional commits. fix:, feat:, docs:, refactor:, chore:. PR titles inherit the shape; commit bodies explain WHY, not WHAT.