Contributing
post-quantum-packages provides post-quantum cryptography building blocks used in production blockchain systems. Correctness, consistency, and minimal dependencies are the top priorities.
Prerequisites
| Language | Runtime | Minimum version | Tools |
|---|---|---|---|
| TypeScript | Bun | 1.0+ | — |
| Rust | rustup | 1.78+ | rustfmt, clippy |
You only need the toolchain for the language you're contributing to.
Setup
git clone https://github.com/multivmlabs/post-quantum-packages.git
cd post-quantum-packages
# TypeScript
bun install
# Rust
cargo build
Before you start
- Non-trivial changes (new features, API changes, new packages) — open an issue or discussion first to align on the approach before writing code.
- Bug fixes and small improvements — open a PR directly.
Running tests
# All TypeScript packages
npm test
# All Rust packages
cargo test
# Single package
cd packages/<package>/ts && bun test
cd packages/<package>/rust && cargo test
Package structure
Every package follows the same tri-language layout:
packages/<package>/
├── ts/ # TypeScript implementation
│ ├── package.json
│ ├── tsconfig.json
│ ├── src/
│ ├── tests/
│ └── README.md
├── rust/ # Rust implementation
│ ├── Cargo.toml
│ ├── src/
│ └── README.md
└── python/ # Python implementation (planned)
├── pyproject.toml
├── src/
└── tests/
All implementations of a package must expose the same public API and produce identical outputs for the same inputs. Current priority is TypeScript and Rust.
Coding standards
TypeScript
- Formatter and linter: Biome (configured in the root
biome.json). - Target: ES2022, ESNext modules, strict mode.
- Style: no
any, explicit return types preferred, single quotes, semicolons, trailing commas.
cd packages/<package>/ts
bunx biome check --write .
bun run build
bun test
Rust
- Edition: 2021.
- MSRV: 1.78.
clippywith warnings treated as errors.rustfmtformatting.no_stdcapable where applicable.
cd packages/<package>/rust
cargo fmt -- --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-features
cargo build --no-default-features
Implementation guidelines
- Minimize allocations on hot paths (encoding / decoding).
- Prefer two-pass encode: compute total size first, then write directly to the output buffer.
- Use zero-copy (
&[u8]borrowing,Uint8Arrayviews) on decode paths where possible. - Match raw bytes over string intermediates (e.g., OID lookup by DER bytes, not dotted-decimal strings).
- Keep packages lean — every dependency is attack surface.
Making changes
1. Branch
git checkout -b feat/pq-oid-add-new-algorithm
Naming: feat/<package>-<description>, fix/<package>-<description>, or docs/<description>.
2. Implement
- If you change behavior, update both language implementations to keep them in sync.
- If you add a feature to only one language, note in the PR that the other language needs corresponding changes.
- Add or update tests for any behavior changes.
- Update the package README if the public API changes.
3. Verify locally
Run the checks listed in the Coding standards section above.
4. Commit
Use Conventional Commits. The scope is the package name:
feat(pq-oid): add SLH-DSA-SHA2-128s algorithm support
fix(pq-key-encoder): correct PKCS#8 version field encoding
docs(pq-jws): update usage examples for v2 API
test(pq-cert-verify): add chain validation edge cases
refactor(pq-spki): reduce allocations in encode path
5. Open a PR
- One logical change per PR.
- Fill out the PR template and link any related issues.
- CI must pass before review.
- PRs are squash-merged into
main.
Review criteria
- Correctness — does it produce the right output? Are edge cases handled?
- Consistency — do both language implementations agree?
- Performance — no unnecessary allocations or copies on hot paths?
- Standards compliance — does it follow the relevant RFCs and NIST specifications?
- Test coverage — are there tests for new behavior and edge cases?
- Minimal dependencies — does it introduce new external dependencies? If so, why?
Reporting issues
- Bugs: open a GitHub issue with reproduction steps.
- Security vulnerabilities: see the Security policy — do not open public issues.
- Feature requests: open a GitHub issue describing the use case.
License
By contributing, you agree your contributions will be licensed under the MIT License.