One thing the SEC didn’t say anything about in its analysis of The DAO token offering last week was the place in the ecosystem for “utility tokens.”
This was bemoaned by at least one other legal commentator. As Trent Dykes’ said, it “seems unlikely that the SEC was unaware of the concept of utility tokens, yet it chose not to discuss that topic. We wished they had.”
As opposed to a currency token, which is a token intended to serve as a store of value, or an application token, which is intended to serve as a tool for the monetization of a specific service or platform (perhaps as an app-specific currency), a utility token is something different altogether.
Utility tokens are tokens intended to serve a very particular function, such as
- tracking a particular piece of information, or representing the movement of an object as it passes through a supply chain, or
- conferring a user a right or permission to perform a specific action on a platform or service.
And even a quite mundane and simple utility token can acquire a growing wealth of functionality due to being decentralized, as many different people develop on top of it.
Let us give you an example. Suppose a library wanted to use blockchain tokens to keep track of its books.
The library could create a category of token for its books. Its users would be given a “library card” which would essentially be an address, if they didn’t already have one. When a patron of the library checked out a book, the library would transfer the token to that person. And when they returned the book, they could return the token as well. Assuming everyone transfers the tokens when called upon this system would work just fine, effectively replacing the library’s private database. And, if done properly this would replace not just one library, but potentially create a single global database for any libraries which choose to participate.
But what if a user doesn’t return the token when their book is due to be returned? Or what if a user returned the token but not the book? How do would we handle this?
There are a number of different solutions.
To actually implement most blockchain applications, some degree of application-specific work is required to hammer out the practical problems for each use case. Developers have to make it work in practice using the set of tools available on the blockchain- chiefly by writing smart contracts.
A blockchain smart contract can be written to hold a token, rather than sending it to the user’s address directly where they will have exclusive control. So our scrappy developers could implement a “borrow” smart contract for holding library book tokens — when a user checks out a book, instead of going to the patron’s address, the token is temporarily held within a smart contract.
This smart contract *could* be written to automatically return the token when the book is returned. And there are many use cases that would make sense to have this sort of function, such as an access credential token that should expire after a certain period of time. But the problem with this use case is that the physical book is still out there. In this case, returning the token alone does not help.
Suppose instead the patron must supply an amount in escrow to the borrow smart contract, perhaps approximately equal to the price of one or two books, which when the user accrues late fees for failing to return the book, the smart contract will automatically draw down from. This would be synonymous with the fees many libraries currently charge to obtain a library card, and when depleted the user would be unable to borrow more books before replenishing it.
If the person returns the book on time they will be able to borrow another one for free. But if they never return the book, then eventually the user will essentially have purchased the book, and the library is effectively forced to assume there is a possibility a book will never actually be returned. And they should structure their application and smart contract accordingly.
At this early stage the library book token may not seem very useful. After all, existing library databases track who has which book all the time.
But blockchains have interesting features.
First is decentralization, which in this instance represents the collapsing of the distinction between a provider and a consumer. In other words, each user of this blockchain system for library books could be *either a patron or a library at the same time. *This could be set up to allow me as a user to transfer a book to someone else without it having to go back to the library.* *
Second, don’t forget, blockchains are public databases. This means that the information about which addresses have which tokens (books) is public information that anyone can view (the public information would just be the address; no one would know which books you had checked out unless they knew your address). In some use cases, this is a serious drawback, such as if privacy is important, but it can also be very useful. Perhaps you would like to check and see if a certain library has a copy of a certain book available before you go down and check it out. Or perhaps you would like to browse a list of all the books a library has on a website. Or maybe you’re a data aggregator interested in searching for macro trends in global book movement or reading patterns. Third parties can devise all manner of inventive applications for these systems.
Third, smart contracts can be added which expand functionality, perhaps in ways that a system’s original creators never envisioned. Perhaps book publishers will see this large database of book possession and write their own smart contracts which offer their books for sale. They don’t need anyone’s permission to do this, but would need to convince users that their code is worthwhile for them to use. But if they are useful enough to be used, then those new developments become building blocks for still further development, becoming incorporated into other, larger or more sophisticated functions.
In summary, utility tokens represent unique opportunities. Although there is clearly a need for greater supervision of investment-oriented activities regarding ICO’s, it is important not to overly generalize to all tokens, many of which may be primarily concerned with users and software in a service rather than raising money.
By Evan Jensen and Joe Wallin
If you want to read more articles like this, please visit our website, here.