Five Ravencoin Asset Patterns

Five Ravencoin Asset Patterns

Ravencoin ($RVN) is the coin for a POW blockchain.  From the website, "Ravencoin aims to implement a blockchain which is optimized specifically for the use case of transferring assets such as tokens from one holder from another."  On November 5, 2018, asset creation went live on the block chain.   Users can create assets, represented by tokens on the block chain. Sub-assets can also be created.  Assets can be sent from one address to another address. Each asset has a special 'owner token.'  The possessor of the owner token has special rights on the creation of assets and sub-assets.  Each asset type has a unique name and can be made in quantities from 1 to 21 billion, with up to 8 digits of divisibility.  In the first 3 weeks since November 5, over 13,000 unique assets have been created.

One example of asset use is a token that represents a share of some real-world asset, such as a property.  One can take a house or piece of land, put some legal documents online in IPFS, link a Ravencoin aasset representing that house to the legal documents, and distribute portions of that asset to represent partial ownership in the house.  If someone wants to transfer ownership of their portion, they can represent that by transferring the asset.

The above example represents a methodology of linking asset transfer to a real-world goal.  Let's call such methodologies 'usage patterns.'  

I present six more usage patterns that may be useful when considering using the Ravencoin blockchain to achieve real-world goals. In each case, use of a database outside the blockchain is minimized - this permits a separation between a grantor of a token and an observer making a decision based on the presence of a token.

Permission Groups

Consider a resort which want to permit someone entrance to their private villa for a period of time, and also to certain locations that the tourist has paid for, but not others. The tourist tells the resort his or her public Ravencoin address.  The resort can send a permission token to the tourist and *without use of an external database* grant or remove permissions as needed for the tourist.  This is important because one can then have a third party actually grant the permissions separately from the verifier, e.g., the exclusive club in the resort.

More formally, let us consider a Grantor of permissions, a User of permissions, and any number of Verifiers of permissions.  The verifiers simply have to examine the blockchain and do not process any assets or tokens.  The Grantor has access to address G, while the User has access to address U. This wallet G has permission tokens P1…PN in it.  Grantor creates a sub-asset S with two instances.  The grantor sends one instance of S to G and the other to U.

The user can now prove that he has permissions P1…PN by simply showing his copy of S in his wallet to a Verifier.  The Verifier looks at G and sees that S is in G and thus knows that the User has permissions P1 through PN.  When the Grantor wants to revoke the user’s permissions, the Grantor can simply remove his copy of S from G. No access to U is required.

One could expand on this to create multiple permission groups represented by multiple addresses owned by the Grantor.  The Grantor can move the copy of S to different permission groups as needed.  Thus, the resort can have a 'basic' permission set, a 'luxury' permission set, and an 'VIP' permission set.  

Votes and Surveys

The Ravencoin product plan includes special voting tokens, where an asset-manager can send 'vote' tokens to every owner of the asset-tokens. By sending these vote-tokens to a special address, votes can be taken.  But even before voting tokens are created, we can use regular sub-assets to vote- just create a vote-token with N copies, send those copies to addresses and designate special addresses as voting results. One can of course expand to multiple addresses to take surveys rather than yes/no votes.

Expiring Assets

One can create a sub-asset with a timestamp at the end. Noting that asset names must follow a certain pattern, unix time is representable by assets of 6 characters until 8/20/2055 and by 7 characters for thousands of years. 

Non-Transferable Permissions

One might want to transfer an asset yet forbid that asset from being used by any other address.  There is no way to forbid address owners from transferring tokens, but one can place a target address in the IPFS hash. The verifier can check to see if the associated file's json matches the address.  Alternatively, one can compute the base-36 version of the target address and take the last N digits. Append these digits to the token as part of its creation.  With probability 36^N, a random address will not have the same signature, thus making the token practically impossible to transfer.
The question arises - what's the point?  Why not just check the blockchain to see if a token was transferred more than once?  The interesting thing about this pattern is that it enables a form of escrow.  One can have a token that only is useful for a particular address and send it to a different address.  The token's utility only takes effect if it ever gets to the target address.

Management Hierarchy

The sub-assets can represent a management hierarchy. Duplicate tokens can be kept by the Grantor in a ‘CURRENT’ address to represent operationally valid tokens, much like the pattern described in the Permission Groups section.

I'm sure that many more patterns will be discovered as Ravencoin asset usage grows.