Messaging FAQ & Guidelines

An Ownership Token grants you the ability to broadcast messages to all token holders. The protocol uses IPFS and JSON to display messaging within the wallet.

Can I send the message to new token holders even if the token holder has transferred the token multiple times?

Yes, that’s the whole point. That’s the real advantage of the system.

Can I send a message to just one of my token holders and not to the others?

No. This is a “broadcast” messaging system.

Can I encrypt the message?

Sure, but then you need a way to send the decryption key to all the token holders. If you can do that, consider sending the message using that system instead.

Won’t this be used to spam people?

We are taking some steps to prevent that in the reference clients. If token holders always add tokens to a new address when they purchase them, then the reference client can quarantine any tokens that are sent unsolicited to the same address, and also mute the channels for unsolicited tokens.

Can I turn off the messages?

Of course. The user is always in control. I’d recommend leaving messaging on for any tokens you purchase, and mute any tokens you are sent unsolicited. The reference client will try to do this for you.

What is messaging for?

We don’t tell people how to use the Ravencoin asset platform, and we expect ideas far beyond what we can possibly imagine. But one use for messaging is to let your token holders know that they’ll receive a vote token and where to send it to register their preference. Another use would be to notify token holders of a future delivered item (Kickstarter-like) that the item is ready to be shipped and to visit a site to redeem their token.

Messaging Guidelines:

  • Clients are free to show or not show poorly formed messages. Reference clients will limit message display to properly formed messages.

  • If the subject is missing, the first line of the message will be used (up to 80 chars).

  • Standard JSON encoding for newlines, tabs, etc. https://www.freeformatter.com/json-escape.html

  • Expiration is optional. Will stop showing the message after X date, where X is specified as Unix epoch. Good for invites, voting requests, and other time-sensitive messages that have no value after a specific date.

  • By default, clients will not show a message after X blocks (default 1 year)

  • Amount of subject shown will be client dependent — Reference client likely to cut off at 80 chars.

  • Messages longer than 15,000 (about 8 pages) will not be pinned to IPFS by some scanners.

  • Messages longer than 15,000 characters may be rejected altogether by the client.

  • Images will not be shown in reference clients. Other clients may show any IPFS content at their discretion.

  • IPFSHash is only a “published” message if the Admin/Owner or Channel token is sent from/to the same address. This allows for standard transfers with metadata that isn’t “published”. Remember “publishing” is just the client choosing to display the message or notify the user.


This requires only the addition of an IPFS for each transaction.

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.


Channels are special Ravencoin unique asset tokens that are created by asset owners. The channel tokens are similar to unique assets in that there is only one with a given name. They can be uniquely identified by having a ~ (tilde) in the name. They are limited to twelve characters, and can use uppercase, lowercase, and digits. Example: TRONCO~Alert

Sending these special channel tokens from one address to the same address will "broadcast" a message on the channel, which is named the same as the token.

Users can mute channels. Some channels will be automatically muted by the anti-spam system.

Client handling of messages

  • Pop-up messages or notifications when running live.

  • Show messages for any assets sent to a new address — by default

  • Mute messages for assets sent to an address that was already on-network.

  • Have a setting to not show messages older than X

  • IPFSHash (or 8 bytes of it) = <byte>

Message format

Goal: A simple message format without photos. URL links are allowed and reference clients will automatically “linkify” the message for valid URLs.

For display by reference clients, the message file must be a valid JSON file.


“subject”:”This is the optional subject”,

“message”: “This is required.”,

“expires”: 1578034800


Only message is required

{“message”:”Hello world”}

The message file goes in IPFS, and the IPFS hash is added to the transfer transaction.

Core protocol changes

Extend the OP_RVN_ASSET to include optional IPFS data for any transfer:

RVNT <standard transfer info><0xHH><0x12><0x20><32 bytes encoding 256 bit IPFS hash>

0xHH — File type 0x00 — NO data, 0x01 — IPFS hash, 0x02 through 0xFF RESERVED

0x12 — IPFS Spec — Using SHA256 hash

0x20 — IPFS Spec — 0x20 in hex specifying a 32 byte hash.

…. (32 byte hash in binary)

Note that 34 bytes are exactly a decoded IPFS hash which includes the 0x12 and 0x20 bytes, and the 32 bytes of the hash. This is useful for re-encoding. If the byte following the standard transfer is 0x01, then the next 34 bytes can be encoded to get the IPFS string starting with Qm…

GUI - Desktop

Create a broadcast message with optional expiration date.

Phase 1 - Enter IPFS hash of message

Phase 2 - Enter message, submit via POST to publish IPFS hash, submit message transaction by sending owner or channel token to same address.

GUI - Mobile

Create a broadcast message with optional expiration date.

Phase 1 - Enter IPFS hash of message

Phase 2 - Enter message, submit via POST to publish IPFS hash, submit message transaction by sending owner or channel token to same address.


These rpc calls are added in support of messaging:

issue_channel TOKEN CHANNEL_NAME

send_message TOKEN IPFS_HASH

You must hold the owner token for TOKEN.

Message Queue

The ZMQ message adds an additional queue for messaging 'pubmessage'

Only broadcast messages should be published via zmq.

Transaction messages can be obtained by watching zmq message queue 'pubrawtx' and decoding to get the ipfshash.

The ZMQ will return a json reponse.


'asset': 'TRONCO',


'txid': '8851dcf27271721f7eb5712eb49e092acfc4866e76a8e85fe6a33bb237501f9a',

'vout': 2


'expires': 1545343682



The DevKit adds messaging support by including a ipfs_hash field for every transaction that includes an IPFS hash. The ipfs_hash can be used with


Replace the hash with your hash to look up the message on cloudflare. If the IPFS daemon is installed, you can also use ipfs get [ipfs_hash]


GetRavencoin.org Contact Us

RVN Donation address: RDUE6TTEFxcbtdDxTLNC7juJKkCSstuMjT