2

In my example scenario, I have an e-commerce dApp where e-books are sold. I originally thought that I could represent licenses to access these books using non-fungible tokens (NFTs) through the ERC721 standard. However, given that there can be infinite copies of a single e-book, thus making it not exclusive, it became apparent that several NFTs would potentially have to be minted to represent a single e-book.

It feels like requiring additional logic to maintain this many-to-one relationship strains what ERC721 was meant to support. I've explored other token standard proposals such as ERC981, but partial ownership doesn't quite capture what I need either.

What I need can essentially be summed up as a token standard facilitating non-exclusive right of access (a license) to various assets. If sticking to ERC721 is the right approach, great. Any opinions or insights are appreciated!

2 Answers 2

1

Lately, there’s been some ideation around applying a similar ERC721 strategy to software licenses. Here’s my thoughts about why I believe it may not work:

  1. It creates an unnecessary economy. What if you issue $a tokens and then, after some time passes, $b more people want to buy the e-book? Will those $b people buy it from you or from a secondary market where it’s cheaper? This is a direct threat to the profitability of the business.
  2. It confuses the user. Imagine almost every time you move the file around, you need to input your private key. Normally, this shouldn’t be stored in a plain text file on desktop, so it adds some sort of overhead costs.
  3. It makes accounting more complicated on the business side. That is, instead of simply tracking one-off payments of simple PDF files, now you may need to constantly track the price of the free market price and potentially reconsider your strategy.

Having said that, I do admit that ERC721 are cool and there’s a variety of application for them. It just might be the case that NFTs aren’t the best solution for non-exclusive ownership of assets, but I could be wrong. Maybe an ERC20 or a simple payment mechanism would suffice.

Happy to hear counterarguments!

1

The suggestion I have is to use a MultiERC20 contract

Each e-book is an ERC20 token, and has balances, etc.

This allows you to track a collection of books with 2^256 owners per book (more than you ever need) however I would use the style of ERC721 to improve the ERC20 you use, transferFrom only, approvals, operators etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.