Release Manifest
Each candidate is paired with a manifest so downloaded binaries can be compared against a single known checksum set.
Verify Releases
Check manifests, signatures, and signer metadata before you trust a build.
CPH Core is building a Bitcoin-like trust lane: detached signatures, signer packets, and release authenticity checks tied to the current staged candidate.
Authenticity
Signer Lane Active
- Manifest
- SHA256SUMS
- Signers
- Target 3, minimum 2
- Verification
- Detached signatures
Verification Steps
How the current release lane is intended to be checked
The same structure is used by the candidate, signing packet, and trust-lane tooling.
- Download the current candidate and its `SHA256SUMS` manifest.
- Verify detached signatures and the signer metadata packet.
- Compare the signer set against the current trusted roster before running the candidate.
- Use the public explorer and health APIs to confirm you are landing on the expected network state.
Trust Lane
The pieces that turn a file download into something operators can verify.
This is the part of CPH that aims to feel closer to a serious public release process.
Detached Signatures
Trusted signers return detached signatures and metadata so operators do not have to trust a single maintainer path.
Live Cluster Agreement
The trust lane is strongest when the staged candidate, the public seeds, and the explorer surface all agree on the same active network topology.
What To Check
- The manifest hash matches the downloaded files.
- At least two trusted signer returns are present for the authenticity lane.
- The live candidate and public cluster still agree on seeds, nodes, and explorer reachability.
Why It Matters
- Release verification protects operators from running the wrong build.
- Signer diversity improves trust beyond a single maintainer path.
- Authenticity checks are one of the remaining steps on the path from bootstrap-ready to bitcoin-grade maturity.