In this article, we are going to discuss the standard of how can we develop the smart contract in EOS that can have partial ownerships for various unique assets with hierarchical approach. We already know the handling of the virtual representation of items, it may be fungible tokens ( FTs ), semi-fungible tokens ( SFTs ) or non fungible tokens (NFTs). But what if we want to have distributed ownership of some NFTs like videos, music, e-books, games, photography etc.? We will discuss about the approach we should follow.

Before reading this, we would recommend you to read the previous articles to have an in depth understanding of writing basic EOS smart contracts. The whole series about the EOS and writing their basic smart contracts can be found at http://localhost/niyama/tag/eos/. So let’s get started!

First of all we will discuss, what is ownership, digital assets and how it works in blockchain?

Ownership and Assets

Digital assets have a direct monetary value. Although, maintaining its integrity and ownership is a huge challenge. It includes fraudery, tampering, duplication and more. So, blockchain provides integrity, make trustless transactions without any central authority. 
Cryptographic digital assets, just like physical assets, have many properties, one of which is fungibility, semi fungibility or non-fungibility. In Economics, fungibility refers to the interchangeability or equivalence of each unit of a commodity with other units of the same commodity.
Hence, Fungible tokens work fine for tokens that want to have currency-like properties rather than being something unique and valuable itself. Fungibility is the essential feature of any currency — for the means of exchange, a unit of account, and store of value — Fungibility exists for Bitcoin, Ether, EOS etc.. On the other hand, the Non-fungible tokens are a special type of token that represents a unique asset. They represent scarce physical property, like cryptokitties, artwork, crafts, virtual house,s etc. Hence, they are non-interchangeable, unique, and non-divisible tokens. The other type of tokens are semi-fungible tokens (SFTs). These tokens are 1 of n with a serial number or slightly different metadata. dgoods and simple assets focus on making a marketplace for such digital assets as tickets, luxury goods, games, etc.

So, blockchain’s power can help in prospering other industries as well like videos, movies, music, e-books etc. where piracy and illegal use of content is damaging the industry, especially to creators of the content. Digital information is therefore invaluable. Hence, support in its creation, storage and distribution should reflect that value and safeguard the rights and interests of its true owners. Providing the true ownership on blockchain to such digital assets along with creating a marketplace hence can be a great value. But, NFTs in itself is indivisible in nature, hence you either own the NFT token or you don’t. So, what approach can we follow in order to have partial ownership on such digital assets?

dNFTs Architecture

We will now discuss the architecture required for this model. We require a hierarchical approach for the category, token name and their percentage holdings. category is at the topmost hierarchy which tells us about what marketplace it is holding. It can be used to group various tokens of similar class. Token name is unique, non fungible and as such is not an asset (eosio::asset). Both category and token name are of type eosio::name. Hence, instead of an asset we can realise it as something which cannot be distributed or divided. Now, to have some percentage ownership on them, we can define a constant asset:

const asset per = asset ( 1000000, symbol (“PER”, 4 ));

This defines the 100% total current supply of any unique token. Though we can burn them but cannot mint them. These are initialised as 100 PER as the current supply whenever new token is created by anyone under some category. 10 PER of token VT-A means 10% ownership of VT-A. Hence, multiple accounts can have the ownership on same token without the token itself being fungible. Also, note it is not a compulsion that 100 PER needs to be issued at once. One can issue any x PER to accounts where x<=100. The reward or the royalty can be distributed by the issuer or creator to their share-holders. Note, PER here acts as a stable token for that NFT token asset.

This basic architecture can be realised by following flowchart :

Now, to uniquely identify each token in it, we use the dnft_id which gets auto incremented every new token is created. The dnft_id state in singleton table is initialised to 0 while we call the config action in the smart contract. This is also done to ensure that we don’t always need to add the category & token name in all the tables. We can point to them by just their unique category ids hence saving the RAM at large.

In this example, Alice has 100 PERs at VT-A, 70 PERs at VT-B while Bob has 30 PERs at VT-B and 40 PERs at VT-C. Note, the total issued supply of VT-C is only 40% so it may be that the issuer has got only 40% rights so he cannot distribute more than that.

Similarly, this leads to not only an easy to use global market space for such scenarios. Like for any video, VT can be the category where one can create their unique token.

To ensure that these holdings can be tradable, anyone having PER at any token can list them for sale at the contract by paying for the ram. The lists table is updated by token’s dnft_id, seller, holdings and price_per_percent. Their PERs are transferred to the contract’s account to ensure safety. The sale listing can be cancelled anytime before it being sold and ram allocation can be freed up. The ram payer in this case was kept seller himself to limit the fake multiple small sellings i.e for 10x of PER at the same token, one does not make 10 sale listings of x PER each as that would it the ram.

So, let’s quickly check the actions present in the smart contract:

• ACTION setconfig(string version)

To maintain the version of the contract.

• ACTION create(name issuer, name category, name token_name, bool burnable, string base_uri, uint8_t span, string hash)

To create a new token under some category like HarryPotter token for ebooks category. The span for its validity is mentioned. The hash that needs to specifed is sha256 file checksum. The filled template for its creation is mailed to validators who verifies the creation and its checksum from the blockchain. Hence acts as legal binding of its authenticity.

• ACTION issue(name to, name category, name token_name, asset quantity, string memo)

It is callable by issuer; to issue to their true ownership holders as per their percentage. Quantity needs to be in PER only (representing %).

• ACTION burn(name owner, name category, name token_name, asset quantity)

It is callable only by token owner; to burn quantity PERs of their ownership on particular token.

• ACTION buyshare(name from, name to, asset quantity, string memo)

It is called when a user sends relevant EOS from eosio.token to this smart contract account with a memo of “sale_id,to_account”. The effective tokens are issued back to the buyer who initiated this action.

• ACTION listsale(name seller, uint64_t dnft_id, asset percent_share, asset per_percent_amt)

It is callable only by owner; creates a sale listing in the token contract valid
 for 1 week, transfers ownership to token contract. The RAM for each listing is paid by owner itself, hence demotivates for DoS attack on RAM. The listing of the sale is kept alive for 1 week only. Once, the sale is listed the owner of that percent token (percent_share) becomes the contract account only (without the permission to spend them). Though, seller may close the sale anytime, to free the RAM and get back their ownership share.

This is a difference between ethereum and EOS. We don’t require to care about the transaction fees but need to care about the RAM.

• ACTION closesale(name seller, uint64_t sale_id)

It is callable by seller if listing hasn’t expired, or anyone if the listing is expired.

To buy the ownership, one has to transfer the EOS from the eosio.token transfer action with the memo as:
<sale_id,to>

Please note, instead of only listing the sale of his/her ownership shares, the limited time bidding mechanism can also be made whereby people may bid for it. It would be best suited if the no. of people using the platform are more. Even, the ram requirement would be lesser in such scenarios. There is no need of pausing any sale listing or bidding as there are no transaction fees as such in EOS so one may close and recreate the sale if required.

• ACTION startbid(name seller, name category, name token_name, asset percent_share, asset base_price )

To have bidding mechanism for any percentage shares. The time duration kept for it is also 1 week. Bidding becomes successful after a week and the highest bidder receives the shares.

• ACTION closebid(name seller, uint64_t sale_id)

Seller can close the bid anytime before 1 week but the bidding would be declared unsuccessful in this case and no bidder would receive the shares. This is kept to ensure transparency that only highest bidder receives shares irrespective of his identity.

Now, the main question arises that what about the case if some EOS account makes fake NFTs and can become untraceable later after selling them. So, to avoid such scenarios, we are focused to add trusted entities that act as validators to any NFT. Hence, providing authenticity to any investor.

• ACTION addvalidator(name owner, string email, string pub_key_hash)

Contract account can add trusted validator EOS account, their unique email ids used for PGP encryption and the hash of their PGP public key.

• ACTION delvalidator(name owner)

Contract account can delete validator EOS account anytime.

• ACTION validate(name validator, name category, name token_name, string certificate_hash)

A validator can validate the NFT creation to which he is assigned to. One validator is chosen by the seller based on their trust level. Another validator is chosen by contract at random. Both validators issue certificate IPFS hash after verification and fee taking in the real world. If any validator doesn’t verify without specifying a reason within a week, their trust score is affected.

Note, before verification by validators, the NFT can not be issued to anyone.

The full smart contract implementation of this architecture may be found at :
https://github.com/Quillhash/dNFTs

Conclusion

The new marketplace can be established for the scenarios like music, videos, e-books, games, photography etc. where partial ownership of NFTs is the requirement. But in EOS, it needs to be done with proper care that it does not waste precious resources like a ram. Also, it would motivate public participation in such valuable assets too.

EOS in itself can be a huge plus to creating such a marketplace where we require faster transaction speeds. The emergence of this trend is not without its hurdles, however. But the future seems to be promising with the EOS coming up and creating a better marketplace for all. Zeptagram is the one doing great job using this standard and are first to implement it. They have created a marketplace for music rights via their platform. It shall be an awesome opportunity for anyone to list and earn from their music.

Thanks for reading. If you are interested in contributing to the dNFTs open source standard, we welcome you to reach out via our website, or via telegram channel. We would love to hear your opinion.

To be up to date with our work, Join the Quillhash Community :-

Telegram | Twitter | Facebook | LinkedIn