Contributing
Tidecoin follows an open contributor workflow: propose patches through pull requests, keep changes focused, add tests with behavior changes, and expect review before merge.
This page summarizes contributor practice. The repository source of truth is
../tidecoin/CONTRIBUTING.md.
Before Opening a PR
- Build Tidecoin Core locally.
- Run the relevant unit and functional tests.
- Keep commits atomic and reviewable.
- Avoid mixing formatting, refactors, and behavior changes.
- Explain why the change is needed, not only what it changes.
PR Area Prefixes
Use a component prefix in the PR title:
| Prefix | Use for |
|---|---|
consensus | Consensus-critical rules |
wallet | Wallet behavior and wallet RPC |
net or p2p | Peer-to-peer networking |
rpc, rest, zmq | Control and integration interfaces |
mining | Mining and block-template behavior |
qt or gui | GUI changes |
test, qa, ci | Unit tests, functional tests, CI |
build | CMake and build system |
doc | Documentation |
refactor | Structural changes without behavior changes |
Commit Messages
Use a short subject line and a body when the reasoning is not obvious. Keep each
commit buildable on its own where practical. If a commit fixes or references an
issue, use fixes #123 or refs #123.
Do not include username mentions in commit messages or PR descriptions.
PQ-Specific Constraints
- Do not introduce ECDSA/secp256k1 assumptions into Tidecoin PQ paths.
- Do not add floating-point arithmetic to cryptographic signing code.
- Keep scheme activation checks separate from wallet preference.
- Add tests for PQHD, scheme registry, script flags, and AuxPoW behavior when touching those surfaces.
- Treat consensus serialization changes as high-risk.
Review Expectations
Review is part of contribution. A good PR includes:
- a narrow scope;
- clear motivation;
- tests or a clear reason tests are not needed;
- before/after behavior notes;
- links to protocol docs when touching consensus or cryptography.
If reviewers request changes, either update the patch or explain why you disagree. Unanswered review feedback blocks merge.
See also: Build from Source, Testing, Security Reporting, Release Process.