From Ravencoin Wiki
Revision as of 06:16, 5 June 2020 by Jeroz (talk | contribs) (→‎Phase 6 - Voting (Aim: Q3-Q4 2020))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


This section of the wiki aims to help document the development work done related to the Ravencoin network and provide information for developers who want to build software and tools using Ravencoin.

Every two weeks developer meetings take place on the Ravencoin Community discord server #development-meetings channel ( An archive of the dev meetings is available on Reddit (in the side panel)

Several dev meeting summaries are available at

For Ravencoin network details, see:

Ravencoin platform development

Phase 1 - Ravencoin launch & mining algorithm - Jan 3rd, 2018

In addition to the X16R algorithm, most of the core code changes are in the chainparams file.

The details are broken down on the wiki page: Chainparams.

If you are looking to port existing Bitcoin applications to include Ravencoin - there are some useful parameters available from work done in the Ledger integration code on GitHub.

Summarized on the wiki page: Ledger integration

If you are looking for typical parameters needed for wallet integration - there is a summary on the Wallet integration page.

It's worth mentioning, whilst we all try to keep these pages up to date, the RavenProject code on GitHub could change and these pages could become out of sync. Please validate on

Dark Gravity Wave - Aug 20th, 2018

Ravencoin forked to include the Dark Gravity Wave difficulty adjustment to protect itself against hash rate attacks. The problem and solution to the problem was explained here.

Phase 2&4 - Assets, Subassets & Unique assets - Nov 5th, 2018

Asset FAQ written by Tron on Medium

Asset info for Main Net

Assets (cost 500 RVN):

Subassets (cost 100 RVN):

Unique Assets (cost 5 RVN) - create one-of-a-kind assets:

Reissuing an Asset (cost 100 RVN):

Global burn address

If you want to get rid of for example assets you do not want. You can send them to a global burn address:

New Mining Algorithm X16Rv2 - Oct 1st, 2019

As it became evident that X16R ASICs were developed and mining Ravenvoin in July 2019, the X16R mining algorithm was adapted with a small modification to X16Rv2. This adaptation involved adding an extra hashing algorithm to three of the 16 existing ones, which greatly reduces the times an ASIC can be used (~3.5%). X16Rv2 was implemented using an ASIC-reset-hardfork.

Development progress and code is available here:

Phase 3 - Dividends/Rewards - Feb 7th, 2020

Rewards, also sometimes called dividends, provides a way to send tokenized assets or RVN to token holders by percentage of tokens held. Dividend support can be done without modifying the protocol. Rewards do not require a consensus protocol change, and the rpc calls exist to be able do rewards already. These capabilities just make it native and easy-to-use from the client.


Use examples

  • Reward shareholders with profits (denominated in RVN)
  • Reward membership holders
  • Reward those that contributed the most to a shared project and earned special tokens

Phase 5 - Messaging, OIP, and Restricted Assets - Feb 7th, 2020

A message is "broadcast" if an owner token or channel token is sent in a transaction to the same address with the addition of an IPFS hash and an optional expiration date. The message isn't really broadcast in the sense of being transmitted to nodes, but rather each node will independently detect the special transaction type and display the message. Message display is subject to some heuristic anti-spam rules.

IPFS Integration

IPFS (Interplanetary File System) is used by Ravencoin for issuance meta-data, messaging, and transaction meta-data. Ravencoin must interact with IPFS in order to show messages because the message content is stored on IPFS. IPFS access should be on by default, but should be able to be turned off with a flag. A two phase approach will allow Ravencoin to use IPFS natively, but it will also use existing IPFS proxies.

OIP Integration

(NEW) Open Index Protocol allows for richer meta data and will get support in Ravencoin in addition to IPFS. You can find more on what you can do with OIP here. You will have to choose between adding OIP or IPFS meta data. Fortunately, OIP metadata also allows for adding IPFS.

Restricted Assets

(NEW) Restricted assets will be a new kind of assets that come with tags. The issuer can send tags to Ravencoin addresses that tell the entire chain that the asset can go there. The purpose of these restrictions is to limit the transferability of a token to known good actors, but without revealing the identity of the actors to anyone other than the original entity that verifies their identity. Only when legally required to do so, would the verifier reveal the identity.

It introduces 2 token types:

  • One starts with a $ and represents a completely new token type which is a Restricted Asset. Restricted Assets only move to Tagged addresses.
  • The other starts with a # and is a Tag. Tags tokens can only be transferred by the issuer. Tag tokens can be sent or revoked only by the Tag issuer.

Restricted assets offer a solution to SEC compliance for security tokens: Ravencoin will allow for appending externally-validated trust from interested parties such as regulators, through intermediate Qualifiers such as KYC/AML provider consortia, down to individual addresses. Issuers of assets can leverage the tags to manage how their assets can move about the chain. In this way, affirmation of an address’ status (such as KYC/AML compliant, accredited investor, or current subscriber) is possible without exposing or replicating the addressee’s Personally Identifiable Information (PII), and where the burden of establishing and maintaining trust in these qualifying tags is borne primarily by the regulated entities and regulators that require such information in the first place.


Use examples

  • Send information about your token.
  • Send alerts relevant to your project.
  • Send information about a shareholder vote.
  • Use Raven messaging for other systems.

New Mining Algorithm KAWPOW (May 6th 2020)

To battle ASICs in the long term, Ravencoin developers are developing a new hashing algorithm: KAWPOW, which is a variant of ProgPOW with parameters specifically for Ravencoin. The change will be implemented using an ASIC reset hardfork . For more info on how to mine, see

An open source kawpowminer by Ravencoin community devs is here:

More info on mining here:

BIP44 Seed Words in Raven Core Wallets (May 6th 2020)

Ravencoin core is going to default to using BIP44 starting with version 4. The iOS and Android RVN Wallet is already BIP44, and Mango Farms web wallet is also BIP44. If you’ve already created a wallet before the version 4 release, then it will continue to use just the BIP32 HD derivation and should be backwards compatible with your existing wallet.dat file. If Ravencoin core does not find a wallet.dat, it will prompt you and give you 12-words to write down as your backup. You should still encrypt your wallet and never forget your password.


Phase 6 - Voting (Aim: Q4 2020 or later)

Ravencoin will support voting. Creating a vote will create vote tokens. These vote tokens are identical to normally issued tokens, except that they are created in exact qty and units as an already issued token. Vote tokens move just like regular tokens up until the block height when the vote expires. This allows vote token holders to send their vote to a delegate that might have better information about the topic and therefore cast a more informed vote. The feature will also allow voting by percentage of ownership. Second tier web voting can be built on top of this protocol.


The Roadmap for Voting is here on Github


Issue a special vote token to every holder of your token.

  • Send to <address X> to vote for X proposal
  • Send to <address Y> to vote for Y proposal

Phase 7 - Compatible Mode (Kawwwmeleon)

04/01/2019 Dev Meeting update

The idea is to allow ravend to act as a daemon that looks like a single coin/token/asset. To realize this, the ravend daemon should be reconfigurable to listen to a transfer RPC call such as senttoaddress or sendfrom, but in this case it would be for a specific asset and not Ravencoin. This would allow easy asset integration into existing systems.


The config for the asset FREE_HUGS might look like:

{"port":2222, "asset":"FREE_HUGS", "rpcuser":"hugger", "rpcpass":"gi3afja33"}

So, sendtoaddress on the new port (non-RVN port) would send FREE_HUGS.

Using the Ravencoin platform

Dev Kit

The Ravencoin Dev Kit is available and maintained at The dev kit contains e.g.,

  • A JavaScript Ravencoin library,
  • An Extensible full node,
  • A full stack for Ravencoin blockchain-based applications,
  • A Ravencoin blockchain explorer UI,
  • A Ravencoin blockchain API for web wallets,
  • Ravencoin Message Verification and Signing for Ravencore,
  • Interface to the bitcoin P2P network for Ravencore,
  • Tools for running a local Ravencore development node,
  • Website for,
  • A client library to connect to Ravencoin RPC in JavaScript,
  • Debian packaging for Ravencore,
  • A helper to add tasks to gulp,
  • x16r library for Ravencore,
  • Treat a collection of Buffers as a single contiguous partially mutable Buffer.

Asset control

Current commands are as of v2.2.0. Be sure to check the QT wallet on github for up to date commands

issue (asset_name, qty, to_address, change_address, units, reissuable, has_ipfs, ipfs_hash)

Issue an asset with unique name. Unit as 1 for whole units, or 0.00000001 for satoshi-like units. Qty should be whole number. Reissuable is true/false for whether additional units can be issued by the original issuer.

issueunique (root_name, asset_tags, ipfs_hash, to_address, change_address)

Creates a unique asset from a pool of assets with a specific name. Example: If the asset name is SOFTLICENSE, then this could make unique assets like SOFTLICENSE:38293 and SOFTLICENSE:48382 This would be called once per unique asset needed.

reissue (reissue asset_name, qty, to_address, change_address, reissuable, new_unit, new_ipfs )

Issue more of a specific asset. This is only allowed by the original issuer of the asset and if the reissuable flag was set to true at the time of original issuance.

transfer (asset_name, qty, to_address)

This sends assets from one asset holder to another.

listassets (assets, verbose, count, start)

This lists assets that have already been created.

listmyassets ( asset, verbose, count, start ) 

Lists your assets.

listassetbalancesbyaddress (address) 

Lists asset balance by address.

listaddressesbyasset (asset_name) 

Lists addresses by asset.

getassetdata (asset_name) 

Lists asset data of an asset.

Detailed Asset Support


The Ravencoin network consists of nodes communicating on port 8767.

The asset information is available by request on the network. Specify a list of asset names to request information about each asset. Requests for information on up to 512 assets can be made per request. Return messages will be sent separately. Asset not found information may be grouped together for optimization.

Information about each asset is important for:

  • Asset creation because assets must be unique
  • Asset display because the asset information contains the number of decimal places to display.
  • Asset meta-data display - Requires the IPFS hash to show additional information about the asset.
  • Asset re-issue status to prevent reissuance attempts on a locked asset.
  • Asset qty issued to prevent reissuance attempts on a fully issued (21 billion) asset.

There are three networks:
Mainnet which uses a network identifier RAVN
Testnet which uses a network identifier RVNT
RegTest which uses a network identifier CROW

An additional command has been added to the network for asset support. This can be used by SPV nodes to get information about assets without interacting with a centralized API or a Remote Procedure Call.

Network call getassetdata()

The following is the specification for this new network call - available starting with network version 70018

Example 1: Request for asset name that doesn't exist

   Request -> getassetdata
   HEADER: 43524f5767657461737365746461746110000000571db430
   DATA: 010e4241445f41535345545f4e414d45
   Data Breakdown:
   01 - Varint size of the vector
   0e - Size of element = e.g. 14 Bytes
   4241445f41535345545f4e414d45 - Name of asset = e.g. "BAD_ASSET_NAME"
   Response -> asstnotfound
   HEADER: 43524f57617373746e6f74666f756e6410000000571db430
   DATA: 010e4241445f41535345545f4e414d45
   Data Breakdown:
   01 - Varint size of the vector
   Oe - Size of element = e.g. 14 Bytes
   4241445f41535345545f4e414d45 - Name of asset = e.g. "BAD_ASSET_NAME"

Example 2: Request for asset name that does exist, and an asset that doesn't exist

   Request -> getassetdata
   HEADER: 43524f576765746173736574646174611d0000004a54c291
   DATA: 020c41535345545f4a4552454d590e4241445f41535345545f4e414d45
   Data Breakdown:
   02 - Varint size of the vector
   0c - Size of element = e.g. 12 Bytes
   41535345545f4a4552454d59 - Name of asset = e.g. "ASSET_JEREMY"
   0e - Size of element = e.g. 14 Bytes
   4241445f41535345545f4e414d45 - Name of asset = e.g. "BAD_ASSET_NAME"
   First Response -> assetdata
   HEADER: 43524f576173736574646174610000001d000000200a58aa
   DATA: 0c41535345545f4a4552454d5900e1f50500000000 00010000f5010000
   Data Breakdown:
   0c - Size of name = e.g. 12 Bytes
   41535345545f4a4552454d59 - Name of asset = e.g. "ASSET_JEREMY"
   00e1f50500000000 - Amount = e.g. 100000000
   00 - Units = e.g. 0
   01 - Reissuable = e.g. 1
   00 - hasIPFS = e.g. 0
   00 - Size of IPFS hash 
   f5010000 - Block height
   Second Response -> asstnotfound
   HEADER: 43524f57617373746e6f74666f756e6410000000571db430
   DATA: 010e4241445f41535345545f4e414d45
   Data Breakdown:
   01 - Varint size of the vector
   Oe - Size of element = e.g. 14 Bytes
   4241445f41535345545f4e414d45 - Name of asset = e.g. "BAD_ASSET_NAME"

Examples 3: Request for asset name that contains an IPFS HASH

   Request -> getassetdata
   HEADER: 43524f5767657461737365746461746118000000e6218523
   DATA: 011641535345545f4a4552454d595f574954485f49504653
   Data Breakdown:
   01 - Varint size of the vector
   16 - Size of element = e.g. 22 Bytes
   41535345545f4a4552454d595f574954485f49504653 - Name of asset = e.g. "ASSET_JEREMY_WITH_IPFS"
   Response -> assetdata
   HEADER: 43524f5761737365746461746100000049000000cb345766
   DATA: 1641535345545f4a4552454d595f574954485f4950465300e1f50500000000000101221220da203afd5eda1f45deeafb70ae9d5c15907cd32ec2cd747c641fc1e9ab55b8e8f6010000
   Data Breakdown:
   16 - Size of name = e.g. 22 Bytes
   41535345545f4a4552454d595f574954485f49504653 - Name of asset = e.g. "ASSET_JEREMY_WITH_IPFS"
   00e1f50500000000 - Amount = e.g. 100000000
   00 - Units = e.g. 0
   01 - Reissuable = e.g. 1
   01 - hasIPFS = e.g. 0
   22 - Size of IPFS hash - 34 Bytes
   1220da203afd5eda1f45deeafb70ae9d5c15907cd32ec2cd747c641fc1e9ab55b8e8 - IPFS hash data
   f6010000 - Block height

IPFS - InterPlanetary File System

You can add a document to an asset as metadata for any purpose, such as instructions, a low-res image of a piece of art that is represented by the token, your website, etc. Messaging will also support IPFS.

Currently, there is not (yet) IPFS support directly in the Raven wallet. However, you can upload content to e.g., and add the hash of the content to the asset that you are creating.

Other documentation

Atomic swaps:

Issue assets in bulk:


This testnet network will be a completely independent secondary blockchain for testing purposes only, in which all tokens will have no intrinsic value and will not be traded on exchanges. The purpose of a testnet is to test features and functionality before introducing those features and functionality to the main blockchain. It is a playground to experiment and test different features with almost no cost to transact or mine blocks. During this testing phase, the Ravencoin blockchain itself will continue to maintain the same operation and functionality it has today.

To run your current wallet in testnet mode (Windows):

  1. First shutdown your current full client wallet.
  2. Create a shortcut to your raven-qt.exe
  3. Right click the shortcut, choose details and add '-testnet' to the target field. Example:
    "C:\Users\<username>\Path\to\executable\raven-qt.exe" –testnet
  4. Open the wallet by clicking on the shortcut you just made, and let the blockchain sync fully
Don't worry, this will not interfere with your regular Raven wallet, just make sure both wallets are not running at the same time. For those who are technically inclined, running in testnet mode does not overwrite any of the blockchain data or wallet files of Ravencoin’s main network. Instead, it will create a subfolder named testnet3 inside your data folder where all testnet related data and wallets reside.

If you would prefer to err on the side of caution, consider running your testnet wallet on a different computer.

If you have additional questions about testnet, please see this subreddit thread or the #testnet channel in Discord.

There are currently a couple of tools available to assist you with testnet testing.

Testnet Technical Information: Technical Information

Bug bounty

There is a 100k RVN bug bounty available if you can find bugs that fork the chain.

And here is an example of a bug found that got paid a bounty - happy bug hunting!

Community Projects

Brianmct RavenNodes - forked from Bitnodes - project to show all the active Ravencoin nodes

RavencoinRPC-PHP - PHP RPC API for communicating with the Ravencoin Network.

Underdarkskies - various projects including an extended RPC version of Ravencoin.