# Peercoin is the Bitcoin fork that put proof-of-stake in the minting loop

> Peercoin is the reference implementation of the Peercoin protocol, a Bitcoin-derived chain that introduced proof-of-stake consensus combined with proof-of-work minting and is built in C++. It suits developers working on long-lived proof-of-stake chains, and it is a codebase where review throughput, not code output, is the stated constraint.

**peercoin/peercoin** — Reference implementation of the Peercoin protocol.

- Repository: https://github.com/peercoin/peercoin
- Website: https://peercoin.net
- Stars: 591 · Forks: 565
- Language: C++
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/peercoin-peercoin

## The protocol is defined by the minting rule, not by the fork

Peercoin, abbreviated PPC and previously known as PPCoin, is described as the first cryptocurrency design introducing proof-of-stake consensus as a security model, with a combined proof-of-stake and proof-of-work minting system. That sentence is the whole thesis. The chain is based on Bitcoin, which it says explicitly, and the difference is the minting model rather than the cryptography or the data structures. The claimed innovations are a new security model, energy efficiency, a better minting model and a more adaptive response to rapid change in network computation power. For an engineer reading the code, the interesting part is therefore the rule that decides who may create the next block and under what condition, since the rest of the codebase is recognisably Bitcoin Core lineage. The homepage is peercoin.net and the documentation sits at docs.peercoin.net, with a forum at talk.peercoin.net and a Telegram chat.

## The three branch types encode a specific trust model

The branch documentation is unusually explicit and it is the first thing a contributor has to understand. There are three kinds. The develop branch is where all pull requests should go, and it could possibly break the code, so it is unstable and not guaranteed to work on any system. The master branch only gets updates from group members, and it receives tested states from develop, so it should contain functional but experimental code. The release-* branches are the official releases, identified by major and minor version number, for example release-0.6, and official release tags are always made on a release branch. Release branches typically branch from or merge tested code from master to freeze the code for release. The rule for changes is correspondingly strict: only critical patches can be applied through pull requests directly on a release branch, and all non critical features follow the standard path through develop, then master, then release. The default branch in the repository is master, which is the experimental line, not the release line. That is a distinction worth internalising before you base any work on a specific checkout.

## Review throughput is the stated bottleneck of the project

The Testing section of the README is unusually candid about where the constraint lies. Testing and code review is the bottleneck for development, and the project says it gets more pull requests than it can review and test, asking people to be patient and to help out, with the reminder that this is a security-critical project where any mistake might cost people lots of money. The process that follows is a defined one. Developers work in their own forks and submit pull requests when they think their feature or bug fix is ready. A simple, trivial, non-controversial change is pulled by one development team member, while a more complicated or potentially controversial change is discussed in the pull request itself, or the requester is asked to start a discussion in the Peercoin Forum for broader community discussion. The patch is accepted if there is broad consensus that it is a good thing, and developers should expect to rework and resubmit patches that do not match the project's coding conventions, which live in coding.txt. There is also a stated mechanism for stale work, where a pull request that becomes outdated and is no longer automatically mergeable is closed with a warning, and the corresponding issue is labelled stagnant.

## Unit tests are expected for new code, and old gaps are openly invited

The automated testing section asks developers to write unit tests for new code, and to submit new unit tests for old code, which is a slightly unusual invitation that tells you what shape the project is in. The unit tests are compiled and run, assuming they were not disabled in configure, with:

```bash
  make check
```

The manual quality assurance section adds the other half. Large changes should have a test plan, and should be tested by somebody other than the developer who wrote the code. That is a direct statement that peer review of the code is not considered sufficient for a large change, which is a sensible convention for consensus code but does mean a contributor's change can sit idle waiting for a second person with the right context. The repository layout shows the tooling this implies. There is a test/ and a tests/ directory, a configure.ac with autogen.sh for the autotools build, a Makefile.am, a build_msvc/ directory for the Visual Studio build, a ci/ directory, build-aux/, depends/ for the dependency tree, contrib/ for contributed tools, doc/ for documentation, and share/ for the data files the client installs.

## A Bitcoin derived tree with the usual support directories

The top level of the repository is recognisably a Bitcoin Core descendant, and that is useful when you are orienting yourself. There is src/ for the node and wallet code, lib/ for the shared library code, a libbitcoinconsensus.pc.in file for the pkg-config template of the consensus library that external projects link against, db/ for the database handling, test/ and tests/ for the different test suites, scripts/ for the maintenance and utility scripts, and doc/ for the documentation. The .cirrus.yml file is the configuration for Cirrus CI, which is the continuous integration service used for the builds, and the sonar-project.properties file points at a Sonar analysis configuration. There is a .tx/ directory, which is where the Transifex configuration for translation lives, a .style.yapf file for the Python formatter used by some of the tooling, and a SECURITY.md for reporting vulnerabilities. A .tx/ directory is worth noting specifically, because it tells you translation is handled through a hosted service rather than pull requests, which is the normal arrangement for a project with a wide user base.

## Release cadence is steady and the chain has been running a long time

The version history shows a project that ships on a measured cadence rather than in bursts. The recent releases are v0.15.2ppc on 2026-10-18, v0.15.1ppc on 2025-06-11 and v0.15.0ppc on 2025-02-21, and the naming convention with the ppc suffix makes it easy to tell a Peercoin build from a Bitcoin one at a glance. The default branch is master and the last push was on 2026-10-18, the same day as the newest tag, so the code and the release are moving together. The version remains in the 0.x series, which by the project's own release branch naming means the official release branch would be something like release-0.15. The licence is MIT, held in the COPYING file at the top of the tree, and the INSTALL.md file sits alongside the autotools build files. The home page is peercoin.net and the client binaries are published on the releases page of the same repository.

## Where Peercoin is the wrong reference

Three situations argue against it. The first is a team looking for a modern layer one or smart contract platform. The repository is a node and wallet codebase with a libbitcoinconsensus shared library, which is the shape of a currency implementation rather than an application platform, and nothing in the tree suggests programmable contracts or a developer-facing execution environment. The second is a team that wants to read proof-of-stake code in isolation. Peercoin's defining feature is precisely that the proof-of-stake and proof-of-work systems are combined, and that interaction is the interesting and the subtle part of the design, so the code is not a clean reference for a pure proof-of-stake chain. The third is a team that expects a fast moving upstream. This is a security-critical project where the stated constraint is review capacity, not feature velocity, and the master branch is explicitly experimental, so building on it means accepting a different pace from what a contemporary blockchain repository offers. The realistic alternative for a team studying proof-of-stake is to read a chain with a simpler staking design for the core mechanism and use Peercoin for the hybrid case, and for a team actually shipping a product, to use an existing chain rather than a reference implementation.

## Conclusion

Adopt Peercoin as a reference when you are working on a proof-of-stake chain, particularly one that mixes staking with proof-of-work minting, and treat its branch layout and consensus code as the thing to study rather than a framework to build on. Verify first which release branch you are reading, because the official releases live on release-* branches and the master branch is described as functional but experimental, and expect to join a review queue, since the project states that testing and code review are the bottleneck.

## FAQ

### What is Peercoin?

Peercoin, abbreviated PPC and previously known as PPCoin, is the reference implementation of the Peercoin protocol. It is the first cryptocurrency design introducing proof-of-stake consensus as a security model, with a combined proof-of-stake and proof-of-work minting system, and it is based on Bitcoin.

### What are the branches in the Peercoin repository?

The develop branch takes all pull requests and is unstable and not guaranteed to work. The master branch receives tested states from develop and contains functional but experimental code, and it is only updated by group members. The release-* branches are the official releases, identified by major and minor version number, and only critical patches are applied to them directly.

### How do I run the Peercoin unit tests?

Unit tests can be compiled and run, assuming they were not disabled in configure, with make check. Developers are strongly encouraged to write unit tests for new code and to submit new unit tests for old code, and large changes are expected to have a test plan and to be tested by somebody other than the author.

### Is Peercoin still maintained?

The repository is not archived and the last push was on 2026-10-18, the same day as the v0.15.2ppc release. The recent tags are v0.15.2ppc, v0.15.1ppc from 2025-06-11 and v0.15.0ppc from 2025-02-21, the licence is MIT with the text in COPYING, and the project states that testing and code review are the bottleneck for development.

## Sources

- [License: MIT](https://github.com/peercoin/peercoin/blob/master/LICENSE)
- [peercoin/peercoin on GitHub](https://github.com/peercoin/peercoin)
- [Project website](https://peercoin.net)
- [README](https://github.com/peercoin/peercoin/blob/master/README.md)
- [Releases](https://github.com/peercoin/peercoin/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/peercoin-peercoin