Share
Explore

No. Hyperstructures cannot be valuable-to-own and free

Jacob () argues in this piece that it’s possible to build protocols he calls hyperstructures.
In his telling, hyperstructures have these properties:
Unstoppable: the protocol cannot be stopped by anyone. It runs for as long as the underlying blockchain exists.
Free: there is a 0% protocol wide fee and runs exactly at gas cost.
Valuable: accrues value which is accessible and exitable by the owners.
Expansive: there are built-in incentives for participants in the protocol.
Permissionless: universally accessible and censorship resistant. Builders and users cannot be deplatformed.
Positive sum: it creates a win-win environment for participants to utilize the same infrastrastructure.
Credibly neutral: the protocol is user-agnostic.

Overall, I find the idea of a hyperstructure compelling, but I distrust that they can be valuable-to-own while still free-to-use.

Free to use is fine. Valuable to own is fine. However, it’s incomprehensible to say that hyperstructures will be simultaneously valuable-to-own and free-to-use.

Of course, the idea that hyperstructures are a new kind of thing that have this unique property of being both free-to-use and valuable-to-own is Jacob’s big claim. So let’s see if I can be wrong, because if it’s actually possible to build a free-to-use and valuable-to-own structure then it unlocks entirely new economic possibilities. But, if it’s not, then trying to build that kind of thing will only result in failure, or worse, harm.

(Note: Throughout Jacob and I both use “free” to really mean, “gas cost only” which is to say the computational costs of running the protocol. This is probably confusing, and points to an opportunity for better terminology.)

Let’s look at an example: Uniswap is a popular protocol that allows people to exchange different tokens. If I have a red token and want blue, and you have a blue one and want red, Uniswap incentivises actors to help us find one another. When we exchange our tokens that’s a transaction, and Uniswap can charge a fee to both of us in exchange for providing this service.
That fee can be distributed to two groups:
The people or platforms that helped us find one another (as their incentive)
The holders of the UNI governance token

In concrete terms, Jacob is saying that there’s a way for the Uniswap governance tokens to still be valuable even if we don’t do #2; i.e. the Uniswap protocol doesn’t charge a fee.

In the case where we don’t do #2, Jacob claims that there’s a key that will drive value to the UNI token through what he calls the “threat of the fee”. The idea is that the token holders will always be able to threaten to begin charging a fee for access to the platform, this will drive people to buy the token to protect themselves from a fee. Here he describes how a “fee switch” could be turned on by owners of the UNI token:
The presence (and control) of a fee switch that can be turned on across the protocol. This creates a dynamic called the "threat of the fee". This means that owners of the Hyperstructure have the right to turn that fee on across the protocol at the base level at any time via a vote. It’s the threat of the fee, because it’s long term value-destructive to ever turn it on.

So far I’m with him. The threat of being charged a fee for usage of the platform which will be paid to the governance token holders does give me an incentive to purchase the governance tokens. They are like shares in a very strange kind of publicly traded company where shareholders directly get to set prices of products. If I’m a rational actor — I’m not, I’ve bought a lottery ticket before I swear to you — I should purchase those tokens according to the discounted future cashflows associated with their ownership.

However, as you’ve noticed, this incentive set will definitely not result in a free protocol. Instead, the best action to take as a token holder will be to charge a fee. A big one. If you don’t charge a fee, then there’s no future cashflows to get excited about in the first place which means your tokens are valueless.

But Jacob’s not quite done. Because hyperstructures have an additional extremely important property (which is strangely omitted from their criteria): hyperstructures are forkable.

For the uninitiated, a fork is a utensil which is excellent for twirling pasta. However, in this context he’s probably not referring to the utensil but rather to the ability to copy all the code of the protocol (since it’s open source) and start up a replica of the original hyperstructure now with new owners. This is called forking the protocol. It has nothing to do with utensils and I don’t know the etymology of the term.
Famously, Ethereum had an early fork because some developers stole Eth. You can think of forking as a very last resort governance option. It’s kinda the equivalent to a populist uprising that establishes a new government, but somehow the original government can continue to exist simultaneous with the new one. (This mechanism is actually quite beautiful and has way more potential than we’re currently using.)

The consequence of this risk of a fork is that it’s easy for competitors to start up a replica of the hyperstructure if the owners start charging fees. If they charge too high of fees then someone can start a competing protocol and people will move over to it instead. Here’s how Jacob frames it:
Turning the fee on is a value destructive action because it would immediately lead to an incentivized fork, since there’s now a clear reason for new entrants to do it themselves.

With the introduction of this forking mechanism, the incentive set has almost completely flipped. When the cost of replicating the network was high, token holders could set high fees. However, now replication costs are low (it’s easy to fork) and so to remain competitive fees will have to be concomitantly low.

But Jacob seems to think that this will give rise to a natural market force to ascribe value. This is the inference I don’t follow so I’ll just give you the direct quote.
This right to destroy is an ownership right, in the same way that owners of an NFT have the right to burn. A rational actor won’t do it, but they can if they want to. In my opinion this right to destroy creates a natural market force to ascribe true value, since people will want to protect that value and utility being offered at large.

Instead of trying to make sense of this paragraph I’m going to try to steelman the argument. I can see three six! approaches to arguing that it’s possible to build protocols that are both free-to-use and valuable-to-own:
Empirically, Uniswap is valuable and free
The threat of the fee
Token holders will avoid raising fees to maximize discounted future cashflow
Network effects are non-forkable
Platform users will use collective action to minimize fees
Users will buy the tokens in order to use the protocol [WIP]
If you can think of more ways that I can be wrong, lmk . Just link the article and start with “You’re wrong :)”

Let’s start with the first one:
Uniswap
Q: Isn’t Uniswap obviously valuable, and yet it’s fees are 0?
Uniswap is obviously valuable and currently free. I just think that one day the token holders will turn on the fee switch, so it’s just free for now (in the same way Facebook didn’t have ads at the beginning, which helped drive adoption).
If you say, “Well no, they can’t turn on the fees people will just switch away if they do.” then I have two answers for you:
That’s an empirical claim about the future, which means the present free + valuableness of Uniswap is not evidence of a hyperstructure
I think that the token holders of Uniswap are actually betting that there *is* some sort of lock in. Maybe that lock in is caused by network effects or developers being willing to pay a small fee vs rewrite code. More on lock in under the “Network effects are non-forkable” section
So, in summary, no, Uniswap is not an empirical example of something being free-to-use and valuable-to-use unless early days Facebook (prior to turning on ads) was also an empirical example of a hyperstructure.
The threat of the fee
Q: Won’t the protocol users know that if they don’t spend enough money collectively on the governance tokens then someone else will buy them and turn on a fee?
Don’t the shepherds know that by overgrazing the shared pastures the grass will all die and their sheep with it?
This has the same shape as a : a group of people would benefit if they could coordinate, but all of them have an incentive to hope others will do the right thing while they pursue their own interests.
In this case, each person would like the fee to be lower, but they’d prefer not to have to tie up their capital in order to vote. So, they instead defer purchasing the governance tokens and hope someone else does it.
(NOTE: there’s a subcase here where if the demand curve is flat enough then the fee will remain especially low. But a flat demand curve is just a euphemism for, “Has other options.” which is covered by the forkability concept.)
Token holders will avoid raising fees to maximize discounted future cashflow
Q: Isn’t it likely that token holders will keep fees low because they know there’s a risk that the community will fork if they raise them?
Yes, of course. But this just means that the token will be largely non-valuable.
The primary value of the token in this framing is that you get paid in exchange for owning it as long as there’s a fee.
No fee, no value. Free means valueless.
Of course, there could be intrinsic reasons to own the token: like signalling your contribution to public goods. But that’s just donation in a different guise. It’s totally worth exploring: legible signals of contribution to public goods could be our way out of our mess of externalities. But it’s not a “natural market force.”
Network effects are non-forkable
Q: But won’t the protocol have a competitive advantage because network effects and community are non-forkable? For example, look at the value of the Facebook and Ethereum ecosystems.
Yes, but I thought forkability was a feature here. If you’re trying to retain a competitive advantage why publish the code in the first place? If your answer is, “Because open sourcing your code offers competitive advantages to development speed, code quality, and adoption.” Fine. That’s just a competitive advantage conferred by forkability, but that’s not the story of forkability that’s being told. The story is that the code is forkable so that the community can easily switch away from it, but now you’re telling me that network effects are actually enabling lock-in.

If there are competitive advantages to the network over the alternatives then that’s the source of profit. But this is nothing new, it’s what companies have always done: cultivate differential advantage in exchange for better margins.

Thinking that the code is what makes this hyperstructure have a property of forkability is like the Securities and Exchange Commission requiring public corporations to publish a business plan in order to increase competition. As if your knowledge that people buy things over the internet and want them fast is sufficient for you to build an Amazon competitor.

I’ll readily admit that forking the protocol’s code is much closer to a true forkability than a mere business plan, but we all know that the value of Ethereum does not come from the code per se but the community built on top of it. Otherwise we’d all be one click away from Vitalik levels of wealth.

To just drive the point home let’s imagine two different protocols and compare their forkability.
Protocol 1 is an open source Uniswap clone controlled by governance tokens which can set a fee.
Protocol 2 is the same, but most of the community accesses it through a meta-protocol which always picks the fork with the lowest fees.

In practice, we might imagine that this meta-protocol is an API interface which is immutable and cannot be used to charge fees. This meta-protocol selects among many competing Uniswap forks whose owners can charge fees for the usage. Anyone can spin up their own fork and offer it to the meta-protocol for use, but the meta-protocol has a built in rule which causes it to always picks the fork with the lowest fees.

Now, which of these protocols is more forkable? On the face they’re the same, both of them are open source so it’s equally easy to fork them, you just click the appropriate button.

But clearly they are fundamentally different. What our prospective protocol competitor, who we’ll call Alice, is asking herself is not, “can I get the code?” but rather, “can I get the transaction traffic?”

In the case of Protocol 1, Alice has to ask herself, “how likely is it that everyone will start using my fork instead of the original, and how much will I be able to earn from it?” Alice knows the lock-in that comes from network effects, and so rightly views it as extremely unlikely that anyone will switch. The payoff would have to be huge to be worth the work to get people to switch. Furthermore, the majority of the work to bring people onto the fork would be comprised not of engineering a better protocol, but of sowing discontent about the existing system and marketing the alternative (if this sounds like it requires Alice to become a politician that’s because Protocol 1 describes the incentive set of a political landscape: high coordination costs, low differentiability, low agent payoff).

Meanwhile, in the case of Protocol 2, Alice can easily know whether she’ll get the traffic: she just has to make a fork that has lower fees and it will be automatically selected by the meta-protocol. Then, once she publishes she’ll earn the profits from ownership of that protocol. This means her main costs are engineering costs. But wait a minute, this is beginning to sound just like regular entrepreneurship in a competitive undifferentiated landscape. And what happens to profits in a competitive undifferentiated landscape? Well, go ask a restaurant owner.

So, if we’re going to espouse the benefits of forkability, let’s be consistent and bring it to its logical conclusion: true forkability — all the way down to the community and network effects. We don’t have to define it that way, but if you don’t then I’m going to argue that that’s not really forkable, or if it is then it’s forkable in the same way that Amazon is forkable by knowing its business model; which is to say, not at all. And if we enable true forkability then the conclusion is obvious: the protocol will be optimized and the profits will be razor thin (which is to say the token value price will be low, and the value to protocol users will be high).

But maybe we’re looking at this from the wrong angle. Maybe we need to look at it from the perspective of a user in the system who buys tokens to vote for lower fees.
Platform users will use collective action to minimize fees
Q: Ok, but won’t the users of the platform all understand that if they purchase the governance tokens then they can lower the fees?
Don’t the customers of Apple understand that if they purchased enough AAPL shares they could use board pressure to lower prices?
In short, no. That’s not what happens. We can easily see why by just looking at a couple examples.
Let’s say you expect the protocol to cost you $30 to use and you’re the sole owner of the protocol. Well then of course all that money you pay is going to go right back to you, so it doesn’t matter what you charge.
If, however, there were one other owner who doesn’t use the protocol then you’d want to lower the fees, since you’d effectively be paying the other owner.
But if there were other users you’d only want to lower the fees up to the point that it doesn’t reduce your costs more than it would reduce your profits. So there’s tension. You’ll satisfice.
However, if you and all the users of the protocol were also owners proportional to your usage then raising fees would be proportionally expensive for all of you, so no one would vote for it.
Finally, if there were a handful of owners with lots of tokens that never used the protocol then they’d want to raise the fees for the ones that used it, maximizing the profit they can extract from it.

It’s all very predictable. These incentives can’t save you.

It’s worth pointing out that those profits returned to token holders are just a unique case of an externality: if there were sufficient coordination capacity then people would switch to an alternative protocol that has lower fees. However difficult it is to effect that switch will determine the fee that token holders can charge.

Users will buy the tokens in order to use the protocol
Q: But what if instead of the protocol charging fees, the protocol required ownership of the token in order to use it?
Utility tokens are isomorphic to charging a fee and returning it to governance token holders. I think.

Summary
So it seems that despite my best efforts, I haven’t found a way out of the woods. Sorry. No free lunch. For something to have ownership value it must have resale value, which means other people must either want it for its consumption value, or for its discounted future cashflow value. The “threat of fees” is not enough.

But there’s nothing to worry about. I want to argue that this is fine. In fact, this helps us describe an ethic that we want for web3. We want our protocols to behave more similarly to Protocol 2 than to Protocol 1 (see the section on Network effects are non-forkable). In other words, we want whoever builds the next Facebook to make it open source, yes, but also to make it truly forkable, so that not only can you fork the code, but also the connections. This is the major benefit of data sovereignty: network effects can be nullified. Imagine if your Facebook connections could be as easily reconstituted as your data can be moved from Excel to Google Sheets.

What’s the incentive for builders to do this? I’ll admit, not much. But we have to find ways to reward them for building hyperstructures that are truly forkable, otherwise we’ll end up with more walled gardens. The ExpectedValue(building a forkable platform) must be greater than the ExpectedValue(building a walled garden). By the way, solving this problem is equivalent to solving the problem of funding public goods.

This points the way toward an ethic and a measure of value that actually matters. There are two values to a hyperstructure: 1) the extractable value, commonly called the profit or the rent 2) the usage value, this is the value of the benefit to those that use it.

Effervescent web3 was focused on #1. But that’s fucked. Usage value, the second one, is what builders do. Everyone else is uninvited.
Random Addendum
I think our crypto world has become a bit obsessed with giving things unintuitive names because it makes our brains tickle. Despite the tickle, “unstoppability” and “permissionlessness” are really not at all good names given what we mean. (Actually, the tickle is probably caused by the fact these are bad names.)

We don’t mean protocols are “unstoppable” like a train barrelling through a school bus stuck at the crossroads. No not that. Rather we want to build protocols that are Underailable, like a passenger train which isn’t derailed by the pranksters putting pennies on the track. One obvious way that any “unstoppable” protocol can be stopped is people can quit using it, and then communities can stop maintaining it. Putting MySpace on a blockchain wouldn’t have made it unstoppable, just underailable by bad actors. As much as I may dislike the-company-formerly-known-as-Facebook, unkillable MySpace would not be better.

Aside: this whole “no censorship” maxim in the crypto space under-complicates the issue. Good governance is good. Let’s try to do more of it. Do we want porn on web3 YouTube, or graphic murder scenes on metaverse billboards? “That’s censorship!” Yes, do it anyway.

Similarly, whenever we invoke “permissionlessness” we normally mean we’re giving permission so people can access a thing. Calling that permissionlessness is like calling the principle of giving everyone equal power “powerlessness.” Bad name. We have a term for protocols that are open to anyone: open protocols. That word you’re looking for is “openness”.

no not openlessness what is wrong with you

Have I gored your sacred cow? Come join me for the barbeque.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.