Blockchain Application Tokens and Software Nano Services

Back in 2016, I started dissecting the implications of blockchain tokens, software products, and the emerging “cryptoeconomics” brought about by the evolution of decentralized application networks. It’s a complicated body of different taxonomies, and hard for many to fully understand. This has been evidenced by regulators, who have taken up the concerns and engaged in heavy enforcement of the blockchain industry as of late.

Maybe about a year ago, I penned a blog post called “Software Economics and the Advent of Tokenized Utility Application Network Solutions”, which wasn’t one of my more popular publications (go figure, it’s pretty thick).

The article was sort of a streaming “mind riff” on the evolution of how software gets funded. In it, I started scratching the surface of the evolution of the economics of software development as a whole.

I really didn’t understand the implications of the fully-developed hypothesis back then. I was just connecting some mental dots between things I knew about capital, software, data, launching software products, and ultimately — licensing.

The Evolution of Software Licensing from Mainframes to Cloud

Coming up through the early era of computing, software licenses were these giant documents, which spelled out in great detail the intellectual property rights, conveyances, permissible usages, term of the agreement, who is subject to, etc… When software ran on a single computer, it was much easier to spell out the intricate details of what a licensee received in exchange for payment.

Then, cloud computing came along, which greatly simplified licensing down to a fundamental concept — you either pay us or we shut it off. This was a radical departure from giving a user a runtime execution license that continued to operate (albeit, sometimes with a little “modification”) past the license term.

Back in those days, the industry needed a collection agent called the Business Software Alliance (BSA), who ran around shaking down IT departments, forcing them to produce an audit of software license assets to ensure compliance. Huge, draconian fines were assessed when a company was discovered to be afoul of their vendor agreements.

Cloud subscription models changed all of that, because usage could be metered down to the packet level. If you stop paying your subscription to Adobe Creative Cloud, they kill your access to the software.


Now let’s skip tracks here for a moment to also consider the concept of “micropayments”.

Wikipedia says,

“A micropayment is a financial transaction involving a very small sum of money and usually one that occurs online. A number of micropayment systems were proposed and developed in the mid-to-late 1990s, all of which were ultimately unsuccessful. A second generation of micropayment systems emerged in the 2010s.

While micropayments were originally envisioned to involve very small sums of money, practical systems to allow transactions of less than 1 USD have seen little success. One problem that has prevented the emergence of micropayment systems is a need to keep costs for individual transactions low, which is impractical when transacting such small sums — even if the transaction fee is just a few cents.”

Ted Nelson, the guy who coined the term “hypertext” and “hypermedia” way back in 1965, initially came up with the idea of micropayments as a way to pay licensing fees to copyright holders for usage of various works.

Early in the internet era, there was a flurry of interest in the concept of “micropayments”. In fact, the W3C even had a micropayments working group dedicated to establishing and incorporating standards into browsers and HTML itself.

Early in the web era, IBM and other companies danced around with the idea of micropayments. At that time, the concept of micropayments at the consumer level was a really good one, but very premature in terms of consumer readiness.

But over the years, formalized applications of the concepts behind micropayments have indeed emerged into various applications — even at the consumer level. For example, in-app purchases for mobile, video gaming, and even API level access metering for SaaS, IaaS, and PaaS providers like Microsoft and Amazon.

Paypal and other payment processors support micropayments, and as of late VISA has even moved towards token-based micropayments architectures for consumer purchasing. The vision is finally being realized.

Token-based & Floating Licenses

Token software license models have been experimented with for many years. IBM & BMC have both worked on creating various token-based license schemes for product lines.

For example, IBM created a floating license pool for their Rational product line, which essentially level sets a pool of tokens for use by an entity across users. When someone uses Rational products, the tokens are pulled from the license pool to activate the software.

So it’s pretty clear there’s a precedent with token licensing and even floating pools of licensing.

However, with all licensing, this requires the hard contractual documentation to go along with the tokens, as evidenced by IBM and other software companies detailing at great length the terms of the license.

Secondary Market License Sales

The traditional approach to software licensing has been that of publishing, which seeks to license each and every use of the intellectual property. As such, software companies are resistant to the notion of secondary market license sales, instead arguing that each person must have a new license to use the product under the original license agreement.

This debate has found its way into court rooms, in particular around the rights of a person to sell and trade video games in secondhand stores like GameStop.

In Europe, a landmark case paved the way for active secondary software license trading at the corporate level. Microsoft sought to stop companies from selling their unused product licenses on the aftermarket, but a judge ruled the companies had the rights to the property, and could subsequently re-sell them.

If a software company wishes to allow secondary market resale of licenses, it might be counter-intuitive when compared to traditional models. But so long as the company agrees and incorporates that language into the requisite contractual documentation, there’s nothing stopping any software company from doing so.

Blockchain Application Utility Tokens as Nano Services

It is really difficult to leverage the concept of a license as part of a blockchain tokens construct, because a license conveys rights to use software. Most blockchain software is a derivative of open source, so unless you wrote the original platform from scratch, you cannot convey the right to the software itself.

This is distinct from the right to access and use computing resources. This falls under a services agreement.

Of course, the debate over the contextual use of a blockchain token rages on between private industry and regulators, especially in jurisdictions where there’s no taxonomy to define the applied use of a token in terms of currency vs. application utility vs. security vs. commodity.

Apparently it’s pretty hard for people to get their heads around the idea of an abstracted data element that represents something else in the real world — and while the underlying construct of the data element is the same in technology terms, the data element should be treated differently depending on how that data element is being utilized.

If a blockchain token represents a security, then that blockchain token absolutely should be treated like the security it represents. Too bad for unregistered security token sellers. They violated the law.

It comes down to deep examination of what the token does within context.

If the token activates features within a functional software application, then it takes on the form of a nano services contract.

Some say it’s a membership, which could be the case when simply accessing the broad features of a system. But once the membership has been fulfilled by getting someone through the front door, individual computing services provided by the blockchain protocol are ultimately activated across a distributed computing network through the incremental use of the core token.

Ethereum uses the concept of gas to pay for any transaction, which is ultimately how miners supporting the blockchain are compensated for their hashing power to maintain the chain.

Extend this into a higher application layer, and you now have connected the dots between just actions on the blockchain, and API microservices within an application itself. Amazon AWS has a management component called Lambda that does pretty much the same at the cloud level. Extending it to blockchain transactions isn’t that far of a reach.

Again, so long as there’s contract language to specify in detail the usage of the service, it’s to the discretion of the provider to define how this works for the end user, who agrees when using the service.

Floating Nano Services Tokens

The difference between a license and a services agreement is pretty clear. On one hand, one can argue that a utility token represents a license — however, since most blockchain applications are based on open source, the rights to the software application itself is pretty distinct from the rights to use computing resources that power the application.

When those Nano Services Tokens are floating and can be acquired to use within the application network, holders of those tokens have the ability to pay for incremental usage of whatever features the blockchain foundational layer, as well as higher order application layers offer.

Software companies who agree to allow the secondary market acquisition of those Nano Services Tokens have created a floating model, wherein all the utility tokens that power a blockchain framework can be used regardless of point of acquisition — whether directly from the company, or from another 3rd party in an aftermarket transaction.

With a fixed number of tokens, the potential supply and demand impact on the cost/value of a token may fluctuate up or down based on the market. But this goes back to my article a year ago with regard to market-based pricing of software platforms instead of company-based pricing.

If a platform enables users to pay for exactly what they use instead of forcing them to pay for the account just sitting there without use, users will opt for a consumption model over subscription. As transaction volume demand increases, so does the cost of the core tokens.

But that doesn’t make the token a security. That makes the token a market-priced, scarce commodity.

Once again, it comes down to the specificity of the legal language in the agreement, which defines how the service and token model works.


The blockchain and cryptocurrency media has poisoned the discussion, since most of the focus has been on currency, commodity, and security — complete with the legal taxonomy associated with each. Regulators are examining the usage of tokens and how tokens are sold, and rightfully so.

But stepping back and actually examining the contextual use case of a token is clarity. What is the token doing within a software framework? If it activates features in a microservices cloud stack, then it is a permissioning mechanism attached to a cloud services agreement. End of discussion.

A software startup can create their blockchain and application stack, and go sell tokens to the open market on that basis. I say this without being an attorney, so check with your counsel. But I am pretty confident that if the token is attached to the requisite services agreement language, it’s solid.

Make no mistake, this requires hard documentation about the token in the form of a services agreement, which must spell out the usage of the token within the application, the rights, conveyances, and terms between the company and the end user. Without that documentation, the mere assumption of the token status leaves the company open to legal and regulatory challenges.

There are still legal discussions around how these Floating Nano Services Tokens get sold — but it is a compelling argument that even pre-selling a services contract for a software application that hasn’t been built yet doesn’t necessarily constitute a “security”.

Of course, that also comes down to how the token is marketed and sold, particularly with regard to expectation of profits and whether the token is being purchased by a buyer for usage on the platform vs. speculation. In these instances, the utility token absolutely constitutes a security — as the Munchee case established.

But for software companies who are careful to not promise value growth of their application token, and can document the token with the requisite services language, the path appears to be clear with historical precedent rooted in software licensing and services agreement language tested by courts around the world.

We’re working to advance blockchain technology, and also pave the way for regulatory clarity in the U.S. around these distinctions. We can no longer delay our innovation, as our status as a competitive nation in technology is diminishing. These are the distinctions and clarity necessary to remove the chilling effect from blockchain innovation and startup development.

Send this to friend