Skip to main content

​
Contributing to Writz

Writz is open source. Contributions — bug reports, code improvements, documentation, and security research — are welcome. This page explains how to contribute effectively.

​
Ways to Contribute

Bug reports: If you find a bug in any of the contracts, circuits, relayer, or bitcoin-script toolkit, open a GitHub issue with a minimal reproduction. Include the test case if possible. Code contributions: See the open issues tagged good first issue or help wanted on GitHub. All contributions require tests. The CI must pass before merge. Documentation: Spotted something unclear, incorrect, or missing? Open a PR directly against the docs/ directory. Security research: See the Bug Bounty page for responsible disclosure guidelines and rewards. ZK ceremony participation: The Groth16 trusted setup ceremony requires independent participants. If you’re interested in participating, open an issue (writz.xyz has no mailbox yet). No technical background required — participants just need to run a script and discard their randomness.

​
Development Setup

All 274 tests should pass on a clean checkout.

​
Code Standards

​
Rust / Soroban Contracts

  • Run cargo fmt and cargo clippy before committing
  • Every public function must have a test
  • Use #[contractevent] for all events — no deprecated Events API
  • Per-entry persistent storage only — no growing Vec or Map in instance storage
  • Manage TTL: every write to persistent storage must set TTL thresholds
  • No unwrap() on user inputs — return errors via Result or panic with descriptive messages

​
TypeScript (Relayer + Bitcoin Script)

  • Run bun run lint before committing
  • Every function must have a test covering the happy path and at least one error case
  • No any types — explicit type annotations required
  • Use the Result<T, E> pattern for operations that can fail

​
Circom Circuits

  • Every constraint must be intentional — document why it exists
  • All public inputs must be explicitly marked <== signal (public)
  • Test proof generation AND proof verification — not just compilation
  • Test with both valid and invalid inputs — verify that invalid inputs are rejected

​
Pull Request Process

  1. Fork the repository and create a feature branch (feature/your-feature)
  2. Make your changes with tests
  3. Run cargo test (contracts), bun test (bitcoin-script), bun run test (relayer), npm test (circuits) — all must pass
  4. Open a PR with a clear description of what changed and why
  5. A maintainer will review within 5 business days

​
Open Items

The following areas are actively looking for contributors: If you want to work on any of these, open an issue first to discuss the approach before writing code.