Back in May, I had what ended up being a major hand surgery — repairing a torn tendon and in the process reconstructing the end of my pinkie by grafting tendons borrowed from my ring finger. As a result, I am now recovering from two injuries — the pinkie itself and the ring finger that was the donor.

What I have learned is that most surgeons under-sell the recovery process. Surgery is invasive and often causes as many problems than it solves. In my case, the scar tissue from the surgery is a huge barrier to recovery — it is currently stopping my tendons from “gliding” correctly, which is what lets you actuate your fingers in both directions.

So I have been going to occupational therapy for the last few weeks to work towards regaining motion in my hand. It’s really 8 distinct projects to regain fluidity on both tendons on each of 4 knuckles (3 in my pinkie and one in the ring finger).

The progress has been slow – each session I find out how many degrees of motion I have gained (or lost) in each knuckle, in each direction. It is frustrating, because especially in the area of the major reconstruction, it is hard to feel any motion or progress.

But I realized today that even in the worst spot there is at least a wiggle. And working that wiggle — even a tiny bit — gets you a little farther along, and enables a little more. So I have to believe that progress is possible and work the wiggle so that tomorrow I can work it a little more.

Like with a lot of things, it is hard to accept that progress happens slowly and incrementally, rather than quickly and fully. But I am trying to remind myself, that like with everything, we are working with compound interest and that the goal is to get a little better every day, and then build on that. Easier said than done, of course, but important to remember that that’s how things usually work.

A central concept on the internet is Layering. Each of the protocols in the internet stack talks to the layer directly above and below it — new protocols can be added as long as they speak the language of their layer. Protocols at one layer can be upgraded so long as they don’t break compatibility with the layer above or below it. This architecture maximizes interoperability and allows for a great deal of flexibility. The shape of the layers has been described as an hourglass, like this:

(credit: University of Calgary)

Beyond layering at the protocol level, we have gone on to build layers at the infrastructure and application levels. Infrastructure like AWS and Cloudflare, software libraries like Node, Rails, and jQuery, services like Twilio and Stripe. To build an application today, you do not need to go build a data center (or many of them), think about how to manually process HTTP requests, or write bare-metal adapters to the payments or telecom systems.

In the crypto/blockchain space, we are just at the very beginning of establishing layers. I think it’s safe to say that today’s blockchain landscape looks more like the early days of AOL, Prodigy and Compuserve (standalone, disconnected networks) than like the open, interconnected internet. A major reason for this is the introduction of cryptocurrencies and tokens, which provide a strong incentive — for now at least — for starting new networks and maximizing value of existing networks. But, as teams continue to build, and continue to build the same things over and over again, layering seems both inevitable and needed.

Within blockchains, layers delineate networking (libp2p as a leading tool), consensus (tendermint, hashcash and others), applications/smart contracts, and perhaps indexing/search (something everyone is doing on their own right now, but that thegraph is looking to solve as a layer).

Perhaps the most interesting question is how different blockchain systems may layer together. Cosmos and Polkadot are building systems for interoperable blockchains via a hub-and-spoke model, with shadow assets pegged to outside chains for interoperability. Interledger is attempting to be a more universal cross-ledger (ledger, meaning blockchains and otherwise) protocol, akin to TCP/IP in the core internet stack.

How these systems interconnect, and layer atop one another, seems like a fundamental question as we move from the speculative phase to the functional phase. We are just now beginning to get glimpses of it.

One of my favorite things about the cryptocurrency / blockchain space is that our conception of “what it all means” is still very much in flux. Nic Carter just published a nice analysis of how the functional narrative around bitcoin has changed over time – (roughly) from e-cash, to e-gold, to private currency, to a reserve cryptocurrency, to a programmable shared database, and on. (FWIW, at USV, our “aha” moment was in 2013 when we started thinking of bitcoin as a protocol, rather than just a payments system). Point is, we are still figuring this stuff out as we go.

It is a particularly interesting time right now because many of the projects that were born in the ICO boom of 2017 are starting to launch — each with its own token. For example, EOS last month and Augur this month. So that means we will finally get to see some natural experiments in real-world token economics and what it takes to make a token economy work from scratch.

The launch of Ethereum showed us that cryptonetworks can be used to create smart contracts and new kinds of assets, and that an economy could develop around the creation of these assets and the execution of the contracts. Relative to the original e-cash vision for Bitcoin, the economy inside of Ethereum is narrow (not buying potato chips with Ethereum), but it is actually still rather quite broad — you can use ETH to purchase broadly useful services on the network.

The other day, someone asked me: why wouldn’t every new project create their own token, rather than using a larger existing token (like BTC, ETH, Steem, etc)? My answer was: for the same reason that some countries use their own currency: because they can. In other words, the economy is strong enough to support its own currency. Whereas other, weaker nations just adopt USD/Euro etc – they don’t have the critical mass to support their own currency. I think of this as Minimum Viable Economy. (I am sure there is a technical economics term for this)

Looking at cryptonetworks, the question, then, is: what is Minimum Viable Economy? I think the answer depends a lot on the shape of the network / economy; for example (from harder to easier):

1. currency/medium of exchange use case: minimum viable economy is actually quite large, because a currency is only useful to the extent that merchants and other parties adopt it. So, for cryptonetworks aiming for a real currency use case (buying potato chips), the bar is super high.
2. “narrow network” payments use case: think of a p2p payments use case like Venmo. In order for venmo to work, I don’t need every deli and online store to accept it, I just need my friends to be on it. Still a high bar, but considerably lower than “full economy”
3. single-purpose network use case: many of the cryptonetworks that are launching now are what I think of as single-purpose networks, or single-purpose economies. Functional networks like Filecoin, Livepeer or 0x. In these networks/economies, there is a single market — for storage, compute, trading, etc. These networks/economies are the most unusual and new — meaning, historically, it would never have made sense to have a separate currency for buying electricity, and a separate one for buying gas, and for buying orange juice, etc. But for global computer networks operating on global universal standards, it may be that a single currency with a single market of buyers and sellers, may, in fact, work. In the single-purpose network, the Minimum Viable Economy is the smallest — just sufficient density on the supply and demand sides of the market — similar to what it takes to launch a traditional marketplace platform like Lyft of Airbnb. Still very hard to accomplish, but more akin to launching an app than starting a country.

As Dani was looking at UBI on the blockchain, we discussed this concept a bunch – at least some aspects of blockchain-based UBI resemble the currency use case – a basic income currency is only actually useful as long as it is accepted by merchants (similar to EBT/food stamps).

I am probably most interested in the third category, because whether/how it works will have the most bearing on the future of computing, web infrastructure, and application development. In practice, a lot will depend on the friction involved in transacting in many currencies (easier for computers than for humans), and on the still unknown impacts of programmable token exchange and cross-network interoperability on liquidity and token value.

Across each of these three categories (and surely more), we will no doubt be getting some lessons in Minimum Viable Economy over the coming year.

In June, the SEC gave some of its most concrete guidance to date that cryptoassets can start out as centralized projects, possibly initially sold under securities laws, and eventually become “decentralized” and thus no longer sponsor-controlled, and no longer sold or transferred under securities laws.

It makes sense that a decentralized protocol does not fit the definition of a security. There’s not a clear single issue or promoter (for purposes of reporting, etc); tokens are often generated on an ongoing basis (which would constitute a “continuous offering” and related registration requirements); tokens are generated on a fully peer-to-peer basis in the protocol (potentially implicating independent nodes as transfer agents or broker dealers, or requiring those as middlemen); not to mention how all of the above are complicated by new issues like forking.

Of course, all of this leaves some open questions on what exactly constitutes decentralization, but I am confident we will work through those to come to a usable definition. For example, “is the network forkable” is one simple (but incomplete) heuristic. Another is: “would the network continue operating if the initial sponsor went out of business”.

This second one is perhaps the most concrete, and I believe the the net effect of the SEC guidance is that we will begin to see protocol development companies (the initial “sponsors” of cryptonetworks) set a course to intentionally self-destruct.

How this is done, exactly, will remain to be seen. Already we have seen a company / foundation split as one way of setting the protocol in the hands of a long-term custodian that is not the initial sponsor. Some projects may bake self-destruction into their initial charter (and any associated coin offerings or distributions); others may make self-destruction part of the protocol software development roadmap.

But regardless of mechanism, I believe many projects will begin to contemplate their “path to decentralization” — that is the takeaway from the SEC guidance, and a self-destructing company (leaving behind only an autonomous, decentralized protocol) is the logical result.

This is going to be a messy process. For example, the recent launch of the EOS network demonstrated some of the challenges of handing off a protocol and network to the community. But luckily we will get to see many more real-world experiments as projects move out of the fundraising phase and into the build->ship->decentralize phase.

I was at an event last night, where the moderator, Preeti Varathan from QZ observed that there seemed to be a lot of cynicism in the blockchain / crypto space — in other words, that the whole thing was essentially premised on a distrust of existing systems (fiat currencies, large internet companies, etc).

It’s an interesting and I would say correct observation, but it’s also not the whole story. In addition to the distrust angle, there is also an innovation angle (though it is related to the distrust angle), which I’ll get to at the end.

But to focus on this question of distrust: a few weeks ago, I was in Amsterdam for the TNW conference, doing a number of things on their “hard fork” track for crypto/blockchain projects. Two conversations stood out:

First was David Schwartz from Ripple, who gave what I thought was a fantastic and clear introduction to cryptosystems — David’s main point was that cryptonetworks are about fairness. You set the rules (in code) and once they are set, everyone plays by them on even footing. No one has the ability to rig the system once it is up and running.

If this sounds a lot like a description of democracy and the rule of law, I think that’s intentional. The framers of the United States had very similar goals — escaping a system that felt “rigged” and set up a rules-based system that had decentralization (3 branches of government, federal vs states, house vs senate, etc) and checks and balances built in.

So why is there a pressing need for fairness (in money, in tech platforms) today? The original bitcoiners were escaping what they saw as unfair depreciation of fiat currency due to inflation — they were digital gold bugs who wanted a real store of value. Beyond that, there is a generation of application developers who don’t trust the platforms they are building on — developers have a keen appreciation of power dynamics and know when they are getting screwed. And beyond that, there is an even larger macro distrust and erosion of institutions brewing — for example I hope that the US can hold on to its own (relatively) fair, rules-based system of governance, but that seems as threatened as ever. So there are plenty of reasons to be cynical and distrusting, both of traditional finance, technology and government.

On to the second conversation was that same day, at dinner with a number of Dutch citizens. One gentleman made the point that “life is pretty good here, and we like our centralized institutions”. Anyone who’s been to Amsterdam can probably relate. Here is a picture from near where we were staying:

It’s ridiculously beautiful and every time I’m there I am struck by how happy the Dutch seem to be — cruising canals by boat, riding bikes everywhere, healthy chubby babies in tow. Even their teenagers are happy. I am obviously being flip here, but the point is — when things are good, or seem to be good, there’s little perceived need to change the system.

To the last point about innovation: the thing that I am most excited about here (and I think I speak for most of us at USV) is what a decentralized asset/contract/data layer means for innovation. Because cryptosystems are open source, extensible and forkable by default, and because they operate on rules-based systems without arbitrary centralized control, we now have a wide open environment for innovation, both at the infrastructure and the application layers. We are still so early in seeing what that will actually mean in terms of services that business and consumers can actually use, but we are building a very exciting foundation.