Contributing

This page summarizes how to work on the open-source Keythings Wallet monorepo. For full details, readCONTRIBUTING.md and CODE_OF_CONDUCT.md in the repository.

Scope

The monorepo contains:

  • The Keythings Wallet browser extension under src/.
  • The @keetanetwork/wallet-core library under packages/wallet-core/.

Getting started

  1. Fork the repository and clone your fork locally.
  2. Install dependencies with bun install at the repo root.
  3. Run the baseline checks to verify your environment:
    • bun run lint
    • bun run build (run once to confirm a clean build)
    • bun audit

Role-based quick starts

Contributors

For a more detailed walkthrough, see the Contributor Quickstart.

  • Read README.md, CONTRIBUTING.md, and SECURITY.md in the monorepo.
  • Set up the dev environment with bun install and bun run dev.
  • For each change set, run:
    • bun run lint
    • bun run build (once; re-run only if you fix build errors)
    • bun run test:unit and bun run test:integration when touching core logic
    • bun audit
  • When changing wallet architecture or security‑sensitive flows, consider adding or updating an ADR underdocs/adr/ in the monorepo.

Reviewers

For a focused review checklist, see the Reviewer Quickstart.

  • Skim the relevant ADRs in docs/adr/ (for example, storage, network mapping, permission model).
  • Confirm the author has run bun run lint, bun run build (once), and bun audit.
  • For risky changes (key handling, RPC surfaces, capability tokens), ask for targeted tests and, where applicable, a short note in the PR description explaining threat model impact.
  • Use the docs in /docs/security and /docs/testing as checklists when reviewing security or testing changes.

Release managers

For end-to-end release guidance, see the Release Manager Quickstart.

  • Before a release, run the full pipeline defined in the monorepo README (lint, build, manifest validation, unit/integration/e2e tests, and bun run security or bun run security:all).
  • Verify that SECURITY.md and the docs site security pages reflect any recent changes.
  • Review recent ADRs to ensure architectural and security decisions are documented.
  • Follow the incident response and disclosure guidance in SECURITY.md when a release contains security‑relevant fixes.

Development workflow

  • Create a feature branch from main for each change.
  • Keep pull requests focused and well scoped.
  • Prefer Zod for input, API, and configuration validation.
  • Avoid logging secrets such as mnemonics and private keys.

Before opening a pull request

At minimum, run:

  • bun run lint
  • bun run build (once, unless you are fixing build issues)
  • bun audit

For deeper verification, follow the guidance in the root README to run unit, integration, e2e, and security suites.

Guidelines for changes

  • Keep TypeScript types strict; avoid any unless strictly necessary.
  • Use Zod schemas for validating external data and configuration.
  • Add or update tests alongside code changes whenever practical.

Updating @keetanetwork/wallet-core

  • Keep the public API surface small and composable.
  • Document new APIs with clear names and usage notes.
  • Ensure packages/wallet-core builds successfully, for example by runningbun run build from the packages/wallet-core directory.

Reporting security issues

Do not report security vulnerabilities via public GitHub issues. Instead, follow the process described inSECURITY.md (for example, by emailing the security contact listed there).

30 of 33