Ravencoin Core: a Bitcoin fork built for asset transfer

A fork of Bitcoin with one change of emphasis

Ravencoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world, and the platform also lets anyone create assets, or tokens, on the Ravencoin network. The README is explicit about the intent. Ravencoin aims to implement a blockchain optimised specifically for the use case of transferring assets such as securities from one holder to another, and it is built on a fork of the Bitcoin code.

The key changes from Bitcoin are two. There is a faster block reward time, and there is a change in the number, but not the weighed distribution schedule, of coins. Everything else is inherited, and the inheritance is acknowledged in detail. The project is launched based on the hard work of over 400 Bitcoin developers who made over 14,000 commits, and the README thanks them by name.

The argument for a separate chain is laid out in the Abstract. The success of the Ethereum ERC 20 token shows demand for tokenised assets on another blockchain. Bitcoin also has the capability of serving as the rails for tokens through projects such as Omnilayer, RSK, or Counterparty, but neither Bitcoin nor Ethereum was specifically designed for facilitating ownership of other assets. Bitcoin is and always should be focused on its goals of being a better form of money, and its developers are unlikely to prioritise improvements specifically beneficial to token transfers.

So the design question the project asks is whether a use case specific blockchain and a specific development effort can create code which either improves existing structures like Bitcoin or provides advantages for specific use cases.

The tokenisation use cases the README names are NFTs, STOs, gift cards, and fractional ownership of anything of value. The project describes itself as a digital peer to peer network for the facilitation of asset transfer, and it explains the name through the story of ravens as messengers carrying statements of truth in the fictional world of Westeros, with Ravencoin designed to carry statements of truth about who owns what assets.

The repository is the Bitcoin tree, plus an assets layer

The repository is described as the Raven Core integration/staging tree, and the top level entries show exactly how much of it is Bitcoin.

There is src/ for the C++ source, which is where the node, the wallet, the consensus code, and the unit test harness live, along with the test/README.md that the documentation points to for how to write unit tests. There is configure.ac and autogen.sh, which is the autotools build, plus Makefile.am and build-aux/. There is depends/, which is the vendored dependency system Bitcoin uses to pin library versions, and contrib/ for the community scripts. There is a .tx/ directory, which is the Transifex configuration for translations, and a share/ directory, a binaries/ directory, and an about/ directory.

Then there are the directories that are specifically Ravencoin. The assets/ directory is the asset layer, the part that does not exist in Bitcoin. The doc/ folder holds the documentation the README tells you to read for how to run Ravencoin, and there is a whitepaper/ directory, a roadmap/ directory, and a community/ directory.

There is also a libravenconsensus.pc.in file at the root, which is a pkg-config template for the consensus library, meaning the consensus code is packaged as a separate library that other software can link against. The test/ directory at the top level is the Python regression and integration suite, distinct from the C++ unit tests inside src/test.

The primary language is C, with the Python test suite as the second language, and the MIT licence applies with the COPYING file and the MIT licence URL referenced. The last push to the repository was on 2026-08-18, and the home page is ravencoin.org.

Three test layers, and a project that admits its bottleneck

The Testing section is the most honest part of the README, and it starts by naming the constraint.

Testing and code review is the bottleneck for development. The project says it gets more pull requests than it can review and test on short notice, and asks people to be patient and to help out by testing other people's pull requests. It also says to remember this is a security-critical project where any mistake might cost people lots of money.

The automated testing has three layers. Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Those unit tests are compiled and run, assuming they were not disabled in configure, with make check, and the details are in src/test/README.md. There are also regression and integration tests in the test/ directory, written in Python, that are run automatically on the build server, and those can be run locally if the test dependencies are installed with test/functional/test_runner.py.

On top of that is the manual part, and it carries a rule that most projects state more softly. Changes should be tested by somebody other than the developer who wrote the code, and this is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

That is the practice of a codebase where a merge can move real value, and it is why the two-layer test structure matters: the Python suite catches the kind of regression that a unit test cannot see, because it exercises the node end to end.

A testnet is up and running and available to use during development, which is the third layer, and the one where the actual chain behaviour is verified before a release.

Master, develop, and the tags you should actually use

The Development Process section is short and the branch meanings are worth being precise about.

The master branch is regularly built and tested, but is not guaranteed to be completely stable. Tags are created regularly to indicate new official, stable release versions of Raven Core. And active development is done in the develop branch.

So master is the integration and staging tree, which is what the repository description says, develop is where work happens, and the tags are the releases. The recent releases confirm the tag convention, with V4.8.0 described as a core release that patches two major bugs and published on 2026-08-19, v4.7.0 patching the asset transfer quantity overflow bug in June 2026, and v4.6.1 with an improved GUI, bug fixes, and minor new features in August 2022.

The four year gap between v4.6.1 and v4.7.0 is worth noting. The intervening releases were bug fixes for a running chain, and the descriptions are specific about what they fixed. A quantity overflow in asset transfers is exactly the class of bug that matters in a chain whose purpose is transferring assets, and the fact that the project describes its releases in those terms rather than in feature terms is a fair signal of what the project prioritises.

The contributing workflow is described in CONTRIBUTING.md, and there is a note that developer IRC is inactive and to join the Discord in the development channel instead.

Editorial conclusion

Adopt Ravencoin Core if you are running a node on the Ravencoin network or building on its asset layer, and you want the upstream code rather than a wrapper. Do not adopt it as a general purpose blockchain, because the project is explicit that it is a use case specific chain optimised for one function. Verify first which release branch you need, since master is the integration tree and the tagged versions are the stable ones.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. RavenProject/Ravencoin on GitHub
4. README
5. Releases