The Bitcoin Stack
Decentralized Order Books as a Framework for Decentralizing the Internet
Dhruv Bansal,
Ryan Gentry,
& Allen Farrington
-
This document is issued by Axiom Venture Partners Limited (“Axiom”), an appointed representative of Kingsway Capital Partners Limited. Kingsway Capital Partners Limited (“Kingsway”) is authorised and regulated by the Financial Conduct Authority in the United Kingdom (the “FCA”). Axiom does not offer investment advice or make any recommendations regarding the suitability of its products. This communication does not constitute an offer to buy or sell shares or interest in any Fund. Nothing in these materials should be construed as a recommendation to invest in a Fund or as legal, regulatory, tax, accounting, investment or other advice. Potential investors in a Fund should seek their own independent financial advice.
Past performance is not necessarily a guide to future performance. Axiom has taken all reasonable care to ensure that the information contained in this document is accurate at the time of publication, however it does not make any guarantee as to the accuracy of the information provided. While many of the thoughts expressed in this document are presented in a factual manner, the discussion reflects only Axiom’s beliefs and opinions about the financial markets in which it invests portfolio assets following its investment strategies, and these beliefs and opinions are subject to change at any time.
introduction
In some respects, it seems to the authors as if Bitcoin has already won. Bitcoin is well on its way to becoming the global reserve currency of the future. The past fifteen years of laser focus in the Bitcoin developer community on censorship resistance, on protecting the twenty-one million supply cap, and on meaningful decentralization seems to have been prudent. This has led to Bitcoin becoming a staple for macro hedge funds looking for an inflation hedge, as a treasury reserve asset for some of the largest and most respected companies in the world, a respectable enough asset to merit a range of ETFs, and even, famously, as nation state legal tender.
Looked at through this lens, it seems as if the wider Crypto community knows that Bitcoin has won as well. One clue is in the distribution of ownership. There are a lot of people who only own Bitcoin. There are very few people who only own ETH or SOL and don’t own Bitcoin, or some other kind of altcoin. If even they know that Bitcoin has already won, we might provocatively ask, why do they persist? Why do they keep building new blockchains, conceiving new projects, and launching new tokens? While it is likely that some have ill intent, as in all walks of life and in all industries, we think the best answer is that they think they are building projects that cannot be built on Bitcoin and solving problems that Bitcoin can’t solve. They seem to believe Bitcoin is only capable of or interested in solving problems that are exclusively monetary. And perhaps some Bitcoiners endorse this narrative split also - Bitcoin is for money, Crypto is for everything else.
The problem with this view is that money is half of every trade and with money as revolutionary as Bitcoin, we can’t help but wonder what else will be affected by its presence and pulled into the gravitational well of its design methodology …
narrative
and reality
A subplot of the television show Silicon Valley captures this narrative split well. The viewer is not supposed to like the secondary character Guilfoyle. He’s a know-it-all, an anarchist, and all-around not a nice guy. And it turns out he is a Bitcoiner. Bitcoin exists in the universe of the show and is even characterised as serious and not likely to disappear. But it’s not what is interesting; it is not what the more likeable characters in the show focus on.
Instead, in a scene that is far more pivotal to the primary plot than the handful involving Guilfoyle and Bitcoin, an investor asks Richard, the main character, “you have unlimited time and resources, you can build anything in the world you want, anything at all, what’s it gonna be?” Richard stammers at first, but then in a rush conveying uneasy sincerity he replies, “a new Internet.” He goes on to explain, “if we could do it, we could build a completely decentralized version of our current Internet with no firewalls, no tolls, no government regulation, no spying. Information would be totally free in every sense of the word.”
As Richard embarks on this monologue, strings swell up in the background, and the viewer is supposed to appreciate that this is a profound, breakthrough moment – not just for Richard and the plot, but for the universe in which the plot is taking place. Furthermore, the viewer is supposed to understand that Richard is morally right – that this vision is not just feasible, and not just commercially viable, but is fair and just. Of course, Richard’s new Internet is built on an altcoin, which for the (presumed to be) mainstream audience’s benefit isn’t given much technical explanation. And so, the show creates this narrative contrast between Guilfoyle and Bitcoin on the one hand, and Richard and altcoins on the other.
As well as Silicon Valley, the show, this split is very much evident in the real-life Silicon Valley investment community. Those associated with Axiom, and likely readers of this piece, believe that if we fix the money, we fix the world; that central banking is upstream (at least in part) of every other problem we might wish to solve by pushing for decentralization, fairness, and openness.
The Silicon Valley view, on the other hand, is to focus on a much narrower, more tangible problem. The problem of sound money is very intangible. It’s tough for people to wrap their heads around. The Silicon Valley problem of centralized tech companies ruining the world and degrading the Internet over the past ten or fifteen years is much easier to grasp. Almost everybody has some experience of fake news, creepy surveillance, walled gardens, and so on. Everybody understands the irritation of paying $10 for 10 different streaming services for content that all used to be free. These are much more tangible problems and hence this is a much easier narrative to communicate.
However, we would argue these are the same problem. Decentralizing the money and decentralizing the Internet are both examples of a fundamental issue with centralized systems: they create misaligned incentives, they stifle innovation, they enrich those in power, and they exploit everybody else. The solution is decentralized systems. Decentralized systems are more fair, more peaceful, more aligned, and tend to create better outcomes.
Sadly, it’s not as simple as recognizing these differences and opting for decentralization. A key difference – maybe the most important difference – is a dramatic asymmetry: centralized systems are easier to build, and decentralized systems are much more difficult. While something of a simplification, consider the following heuristic: i) absent ongoing control and direction, decentralized systems have to run on the incentives of their participants; ii) for an incentive scheme to be suitably generalizable - especially in an antagonistic setting - it requires compensation for resource consumption; iii) “money” is definitionally the most scalable (and saleable!) source of compensation, therefore; iv) decentralized money is likely to be a key component to decentralizing many other systems. One element of our thesis is therefore that many proposals for decentralized systems were essentially impossible prior to the ability to incorporate Bitcoin into their designs.
Figure 1 - Design Theses of Bitcoin and Ethereum
Lest we be too hard on gigantic, centralized platforms, we must remember their existence is not the product of conspiracy but of honest attempts to direct resources to provide utility for users. One such implicit problem is the coordination and incentivization required to achieve anything like Facebook or Google without a central third party commanding immense resources.
Of course, the standard way to address this in Crypto is to launch a blockchain (or at least a token) and the standard narrative is something along the lines of: what Bitcoin did for money, we can do for the Internet … or computing, storage, bandwidth, encryption, switching, content delivery, or whatever sub-domain of “the Internet” a particular project is proposing to “decentralize,” potentially up to the level of individual applications or companies. It may be psychologically straightforward to link together the vague notions of “corporations owning your data” and “blockchains distributing data ownership” to land on the seemingly more tangible solution of introducing an altcoin to turn every company into a cooperative. But we believe it is also a profound category error.
Our view is quite different. We believe that focusing on “the blockchain” as the component of Bitcoin worth emulating and extrapolating is effectively “cargo cult innovation”: replicating the form of something that works without understanding why it works in the first place. The blockchain is not the main innovation we need to recognize in Bitcoin, but rather that decentralization is market-driven and that what we need to replicate and export from Bitcoin are its markets. The idea that we can build open, decentralized markets that anybody can join is what we need to lift.
That is to say, we should be aiming to build in layers, rather than to solve everything all at once. Separate layers can aim to solve separate problems. Furthermore, their decoupling provides robustness in both directions: the failure of a higher layer needn’t affect a lower layer, but the success of a higher layer can create demand-pull. A successful layer two makes layer one more valuable; layer three makes layer two more valuable, and so on. We also suspect a lot more people would be interested in Bitcoin if they believed that it could contribute to solving these more tangible problems and disintermediate these widely disliked centralized third parties. Hence even the prospect of a successful higher layer ought to make all layers below it more valuable also.
Bitcoin layer zero: matching orders
for work & issuance
The Bitcoin blockchain and the rules determining the validity of candidate blocks and transactions is usually collectively referred to as “layer one,” with layers such as Lightning, which we discuss below, described as “layer twos.” However, it is key to our argument, both in terms of technical accuracy and philosophical appreciation, that the Bitcoin protocol functions as two tightly coupled but distinct markets: the market between the network of nodes validating proofs of work in consensus and miners providing these proofs, and the market between users submitting valid transactions and miners including these in blocks. To avoid adopting a naming scheme that conflicts with the standard terminology (one might say, to ensure backwards compatibility) we will refer to these distinct markets as “layer zero” and “layer one,” respectively.
The service provided by “layer zero” is that of releasing Bitcoin into circulation on a predetermined schedule. The order book consists of a single ask: the price, denominated in a probabilistically determined cumulative expense of computations, for which the network will sell the next tranche of Bitcoin on a predetermined schedule. The difficulty adjustment can be thought of as a process of market making. Every two weeks (roughly) the user side of the market reacts to the changes in supply of computations and sets a new asking price.
Figure 2 - The market mechanics of Bitcoin Layer Zero
Both this price and the validity of bids are independently calculated by each node in the network from the combination of the protocol rules and the data publicly available in the blockchain. This may seem to kick the can down the road in terms of meaningfully establishing a source of consensus, but we must account for the algorithm’s “eagerness” in always accepting and propagating the first valid solution.(1)
This means that “the blockchain” is almost never in dispute; on the rare occasions it is, this is because eagerness was not enough to overcome two valid solutions found very close to one another in time. The determinism of transaction and block validity and the heaviest chain rule mean that any network participant adhering to (and in turn, enforcing) the rules of the protocol will arrive at the same conclusion as to the blockchain’s validity, both as objective history and as a continuing source of data, no matter when they join the network.
This is the essence of Nakamoto Consensus: the protocol itself and the shared belief that the units being sold are valuable are all that is required to construct a market for the units’ issuance. This market is not only decentralized in the sense of having no central coordinator, but also open in terms of the parties not even needing to be known to one another ahead of time. Anybody can join by following the rules and proving their work. The protocol determines which blocks are valid, but it does not itself submit valid blocks. Which is to say, the protocol sets the ask in the layer zero market, but external input – the link to both the physical and social worlds – submits the bids. This market is arguably best understood as being between the Bitcoin network itself and the mining industry.
The asking price set by network consensus can be thought of as denominated in bitcoins per computation and the mining algorithm provides a probabilistically stable means of gauging submitted bids denominated in computations per time. At an aggregate level, the latter fluctuates based on real-world conditions, extraneous to the protocol, impossible to target or even to predict precisely because the network is both decentralized and open. Hence, the difficulty adjustment acts as a market-making mechanism for this order book, adjusting the asking price of bitcoins per computation such that bitcoins per time can be targeted and stabilized.
Befitting the “lowest level” of a decentralized and open marketplace, this order book is trivial. The book only has one ask and orders are immediately (eagerly) matched if they meet this price. The order book of every higher “layer” increases in complexity to solve incrementally more complex problems.
Bitcoin layer one: matching orders for transactions fees and settlement
The service provided by “layer one” is the settlement of Bitcoin transactions beyond the block subsidy. The order book in this market is no longer trivial but it is still relatively small: the transactions pending in the mempool. Having established the meaningfulness of “a balance of Bitcoin,” given its issuance at layer zero, prices at layer one are denominated in Bitcoins per byte, and are set by network participants rather than by consensus as to protocol rules. Transactors are makers in terms of bidding transaction fees with each transaction they submit to the mempool, and miners are takers in terms of selecting transactions for inclusion in blocks on the basis of the highest combination of fees they can receive. While the layer zero market was made between the network and miners, layer one is made between miners and transactors.
Mirroring layer zero, at layer one, the protocol determines which transactions are valid, but it does not itself submit valid transactions. Technically, order settlement at layer one works because Nakamoto Consensus was achieved at layer zero; miners finding a block can be thought of as market making given every ten minutes (roughly) the mempool clears and the process of bids and asks resets. However, socially, layer zero needs layer one given Bitcoin issued to miners that can never be transacted won’t be deemed valuable, which would otherwise break the incentives for the layer zero marketplace. Hence, we see that “the Bitcoin protocol” is two tightly coupled but distinct marketplaces, each with its own order book and its own makers and takers.
Figure 3 - The market mechanics of Bitcoin Layer One
Core to our thesis as to what from Bitcoin to replicate, how to replicate it, or whether or not to replicate it at all, is the realization that one cannot wish into existence a single allegedly “decentralized” market to solve arbitrarily complex problems. If one does so, it is overwhelmingly likely that the incentives required to endogenously sustain the system will eventually (or immediately) break. The genius of Satoshi’s methodology was to break the problem into parts that are so small they can be solved by markets in the first place.(2) There is no single market that will both release the supply of digital currency for circulation on a predetermined schedule and settle its transactions in a censorship-resistant manner.
The important thing to realize is that it’s not “the blockchain” that’s making all of this work. It’s the idea that every aspect of this market is both simple and decentralized. The problems tackled are made as simple as possible such that two markets are required rather than one. And the order books in these markets are decentralized, order matching is decentralized, market making is decentralized, and even the rules are decentralized. This is incredibly powerful, and Bitcoin is the first system in history to work this way. This is the part of Bitcoin we ought to attempt to export to other applications, and hence, in our understanding, to other layers.
The fact these base layers of open, decentralized marketplaces serve to create a sound digital money is key to how to build out marketplaces at higher layers.(3) This money (Bitcoin) is half of every trade in every other marketplace, and hence provides a means by which markets can be made in the first place by providing a consistent and context-independent gauge for intersubjective value. This is a fancy way of saying that you need money to make markets, and you need decentralized, open, digital money to make decentralized, open, digital markets. Furthermore, higher layers require lower layers to exist, but lower layers benefit from the value created at higher layers. However valuable layer one Bitcoin can be as a new global money, it can become significantly more valuable if we recognize it as a crucial technical building block to building markets with the potential to disrupt many other human networks.
We argue this is a vastly superior approach to minting a new context-dependent money for each incremental application and trying to bootstrap a market around matching this money to its intended application. The latter is the unfortunately necessary implication of lifting the blockchain to new contexts rather than decentralized marketplaces that utilize Bitcoin’s already working blockchain and its product: Bitcoin, the monetary asset that is both issued and settled in a verifiably decentralized manner.
lightning:
matching orders
for routing and payments
Another layer up brings us another market: the Lightning Network. Keep in mind that it has taken us fifteen years to come close to understanding how the market at layers zero and one work. We are only six years into today's mainnet Lightning Network so our understanding of how this market works is a little bit fuzzier.(4) But we believe we can apply all the same principles to ensure that Lightning is a truly decentralized marketplace for Bitcoin transactions.
The core primitive of the Lightning Network is the payment channel, and the “network” part of “the Lightning Network” is the chaining together of channels. This lends itself to the concept of a “route.” Figure 3 below (pg. 6] illustrates that via C is a possible path for A to send to B, whereas via D may be the actual, cheapest, best route from A to B. We are in the early days of this marketplace for routing.
Figure 4 - The market mechanics of Bitcoin Layer Two
In the early days of the Internet, there were no DNS lookups and there was no such thing as a distributed routing table. Everybody just had the same config file of all the nodes on the network. We are still more or less at that stage with the Lightning Network. This is interestingly evidenced, for example, by LN+ being by far the most widely used service for coordinating channel openings and working on essentially social rather than commercial incentives.
However, in the future one can easily imagine using all the same principles we’ve learned from layers zero and one on Bitcoin: a marketplace for routing emerging where you can make offers for your liquidity to be a part of routes and somebody on the other side will happily take your offer to make a payment. We are already starting to see this layer two market for routes develop, with routing nodes broadcasting the price of their last-hop inbound liquidity to some other destination in the network, adding an order to the liquidity order book, and users taking this order off the order book by consuming the advertised inbound liquidity in choosing to pay through this route.
The liquidity market around Lightning Labs’ Loop service is one concrete area of the Lightning Network where these market mechanics have already become fairly advanced. Loop is a submarine swap service, which means customers use it to swap funds they have received over Lightning for new funds on-chain, simultaneously sweeping hot funds to cold storage and purchasing inbound liquidity such that they can continue to receive payments over Lightning.(5) In order to facilitate this market activity, the Loop node needs inbound liquidity (or the ability to receive payments) of its own.
Today, this inbound liquidity is provided by a robust, decentralized, permissionless set of peers who broadcast a minimum price across the network for how much they will charge to forward payments to Loop. This price can be thought of as an ask. Importantly, this minimum price is purely market-driven, as there is no barrier to entry for the free market of node operators to open up new channels at lower fee rates, undercutting their competition. The taker side of the market then is the swappers themselves. When they initiate a Loop Out, the swappers are presented with an “order book” of potential routes hundreds of permutations deep to get their payment from their node to the Loop node. When they find a route that matches their market-driven willingness to pay, the market clears, the swap occurs, and each individual in the route gets paid for playing their part in facilitating market activity.
Another such marketplace is Magma, orchestrated by data analytics company Amboss Technologies. Entrants to the marketplace can purchase a new channel connection from specific nodes on the network to create more efficient routes from payment origins to destinations. This enables the Lightning Network's structure to change directly in response to market demands. Amboss also publishes the aggregate pricing for new channels as a benchmark rate, called LINER, providing a direct comparison to traditional, credit-based payment methods as the market for Lightning Network liquidity grows and matures.
Perhaps the truest manifestation of a decentralized order book would be Liquidity Ads. While Loop and Magma are both admirably non-custodial services, they nonetheless rely on a central coordinator to construct their order books from decentralized makers and takers.(6) With a Liquidity Ad, rather than buyers and sellers congregating in a centrally provided marketplace, they instead attempt to utilize the Lightning Network’s gossip protocol to advertise public channels for routing. This is an interesting approach to pushing for decentralization in that some thought around design and engineering trade-offs has to be given to embedding the necessary communication tools for certain usages of the protocol inside the protocol. It is unclear at this stage if this approach can either bootstrap to a meaningful scale given the (definitional) lack of a coordinator to catalyze usage or if the UX can ever truly match centralized provision. But it is nonetheless an intriguing development, potentially contributing to a spectrum of viable decentralization in the construction of decentralized order books on layer two and opening the door to market-making the routing of ancillary nonpayment data over the same infrastructure.
We look forward to similar principles being applied to more Lightning-native concepts such as Async Payments and Blinded Paths as the network continues to grow and mature. We are hesitant to celebrate too definitive a “success” however, given the relative novelty of the protocol and its emergent use cases do not seem (to us) to provide clear answers as to whether or not the problems intended to be solved have truly been broken down into small enough pieces to be solved by a single market.
Nostr:
matching orders
for notes
and other stuff
Within the past year or so, we have seen a rapid rise in the use of the NOSTR protocol, or, Notes and Other Stuff Transmitted by Relays – usually stylized as “Nostr”. The first use case for Nostr appears to be an effort to rebuild social media, and Twitter in particular, around a decentralized protocol rather than a centralized platform, but the inherent flexibility and openness of the protocol leads us to believe that it is overwhelmingly likely that more use cases will be discovered and built out in due course. On the social media side of Nostr itself, there are already deeply involved discussions around how to extend to capture the use cases of, and hence to rebuild, the likes of Medium, Substack, GitHub, Telegram, and more - although we caution this is all mostly speculative at this stage.(7)
This presents two interesting developmental quirks that are highly relevant to our analysis. First, there is a distinction between “the protocol” and “the client used to access the protocol” that may be confusing to newcomers used to the likes of Twitter and Facebook but is entirely straightforward – arguably even more natural – to those more steeped in open-source development in general, and Bitcoin in particular.
For example, different email clients can all communicate with one another by utilizing the same underlying standard.(8) Likewise, so can different Bitcoin or Lightning wallets, whereas, to invoke what has surely become a cliché, a Cash App user cannot pay a Venmo user. Likewise, a user of the Nostr iOS client Damus can broadcast “notes” (and other stuff!) that will be received by users of web client Astral, Android client Amethyst, or Primal, which has implementations in all three domains. In fact, the very same user could well be signed into these different clients simultaneously with the same private key.
The second developmental quirk evidently ties into our overall thesis: Lightning is a crucial component of the protocol because in order to decentralize the “assets” of something like Twitter, we also have to figure out how to decentralize the funding (i.e. the “liabilities”). In the age of, “if it’s free, you’re the product,” we are prone to forget that there is an enormous cost that goes into running such a centralized platform, as we briefly covered several sections above. The traditional yet unsavory method of platform monetization is a trade-off in the provision of a valued service and is not exploitative solely for the sake of opportunistic exploitation. However, in Nostr, the costs of bandwidth, storage, and other computational resources (“transmitted by relays”) which are necessary to distribute the assets can be funded by Lightning, given Lightning is as decentralized, open, and digital as we desire Nostr to be.(9)
Developer William Casarin has repeatedly publicly stated not only that “Bitcoin is the native token” of Nostr and Nostr iOS client Damus alike (but also that Nostr itself would not be possible without assuming from initiation that it is an overlay on the decentralized payments functionality provided by Lightning).(10) Although it is very early days with Nostr and a great deal of activity and nascent infrastructure has been self-funded and self-hosted by enthusiasts (much like Lightning was in its early days as well, and Bitcoin before them both), it is not difficult to begin to imagine how the frameworks of decentralized order books could once again become crucial to its functioning and its scaling.
It is fascinating to note at this stage that, so far, Nostr has no in-protocol market mechanisms, especially as compared to Lightning having some market mechanisms but not all. To a large extent, Nostr is able to decouple the “money” side of trades from the protocol by relying on Bitcoin, via Lightning, and can focus on the protocol catalyzing Bitcoin-denominated decentralized markets for the resources it allows its users to access, as organized for them by clients.
One major problem that users of the protocol arguably need solved for them by clients is essentially that “relays” can be thought of as dumb servers, by design. They rebroadcast any “note” from a valid signer to anybody else who asks for it. In order to recreate the typical experience of social it is important for the user experience for clients to be able to access past such (re)broadcasts that occurred while the user was offline. Naturally, the computational resources required to facilitate all of this have real-world costs.
And so, when clients want to publish events to relays, we can imagine that they are “taking” offers for the finite storage and bandwidth a given relay is able to “make.” This is determined not so much by “block space” as at layer one, or “liquidity” at layer two, but in this case more like “physical reality.” It is not a consensus parameter nor a market design within the protocol but has at this point reached all the way to opportunity costs in the real world. There is more flexibility at this higher layer as the payment could well be arrived at by the size of the data (like layer one), the frequency and value of broadcast (like layer two), or in yet more complex methods that the flexibility of layer two enables. The first iteration that has already come to market is a simple upfront fee, but we would expect as much experimentation here as is possible to discover the optimal design in general, or optimal designs specific to different use cases. That Nostr is a free and open-source protocol and not a centralized platform means these experiments can happen to exactly the extent people are willing to run them.
Similarly, when relays forward notes (and other stuff!), the process of relaying could be thought of as making offers to win the right to include an event in the feed of a client, which will take the best offer(s) it can find. The economic relevance of this point can be grasped immediately by imagining that the initial problem of relay selection when a user sets up a new client can potentially be solved by the client auctioning off the “right” to be one of their relays. Given users want to find other users, and all relays do in this ecosystem is compete to provide this utility as cheaply and usefully as they can, it is easy to understand why conceiving of this process literally as “order matching” is incredibly powerful.
Given the overlap in developers and general enthusiasm between Nostr and Lightning, this is an unsurprising starting point for this kind of service. But there are already signs of far more generalized decentralized order books being built on Nostr and utilizing Lightning for payment rather than as the good being exchanged.
A case study of using Nostr for decentralized order books has already emerged from anonymous developer Super Testnet. He has created a submarine swap service(11) akin to Loop, mentioned above. What is fascinating about this project is that rather than a central coordinator, Nostr is used as the (itself decentralized) communication layer to match makers and takers.
CivKit is another such early proposal, recently put forward by Nicholas Gregory, Ray Youssef, and Antoine Riard. The proposal is rather complex under the hood and interested readers are encouraged to read the white paper (link here) and additional resources as we will not be able to do its mechanics justice. In short, the idea is to tap into the features of all of Bitcoin, Lightning, and Nostr to create a protocol for public market boards and order books for any real-world asset. Nostr as an underlying communication protocol offers two benefits: it has a multicast broadcast feature that allows trade events to be announced to a group of interested clients with “best-efforts” reliability, and clients can manage their own credentials, making it easy and cost-effective to switch between different market boards.
Nostr’s reputation-based public keys are leveraged as well. With Nostr, content creators have a persistent public key that enables followers to be permissionlessly ported across any linked application. In CivKit-enabled marketplaces, participants are incentivized to maintain a positive reputation. The process is similar to sellers on eBay, with the key difference that the mechanism is decentralized, rather than orchestrated by a monolithic centralized third party.
Enthusiasm around Nostr is such that at the time of writing there are new proposals emerging faster than can be kept up with. But what all have in common is a potential for creating increasingly decentralized order books, and natural integration with Bitcoin and Lightning – a characteristic and a trend we strongly predict will continue as use cases are discovered, design spaces mapped, and applications proliferate.
And while we are optimistic on and supportive of Nostr’s growth, we caution the reader firstly that it is still extremely early days for the protocol, and that we believe our broader analysis may be applicable to its potential to fail. That is to say, we can’t help but wonder if “social media” may prove to be too complex a problem to try to solve with a single decentralized market. It may well turn out that any or all of: identities, networking, messaging, feeds, and search represent their own discrete problems. Nostr may end up solving none, one, some, or all of these.(12)
The submarkets that power decentralized global computing need to exist before we can have truly decentralized, web-scale applications.(13) Nostr creates demand pull but we should be mindful of expecting too much, too soon. Relays, aggregators, trackers, and so on, are all compromises that reintroduce centralization because the proper submarkets do not yet exist. Applying The Bitcoin Methodology would guide towards solving as simple problems as possible with as many markets as are needed, inheriting as many properties of lower layers as are available, and sequencing application dependencies roughly in order of complexity.
hard problems &
bad solutions
Order books are the hard problem of distributed systems. Bitcoin – layers zero and one – can handle this without too much difficulty because the layer zero difficulty is a single parameter and the layer one mempool is tiny, transactions rarely change before confirmation, and there is a block subsidy to incentivize miners to participate without forcing the entirety of the bootstrapping burden on the network from day one. That is comparable to the scale required for the clearing of central bank reserves. The next level up is Visa scale. That’s a much bigger order book that the Lightning Network has to deal with, and which is inherently much more challenging. It’s fair to say that the Lightning Network is more complex than the Bitcoin blockchain, without needing to be too specific about how to gauge this. The next layers up are going to be Web scale; it’s every network request and every computation that is occurring on the web.
Figure 5 - The evolving narrative of Ethereum's purpose and design
That’s a huge order book. How do we manage that? There is one paradigmatic approach that we always take which is that you start by assuming every participant has their own copy of the order book. That’s what Bitcoin’s mempool is when you run your own node. The Lightning Network has the same thing when you run your own Lightning node. The second step is to incentivize greater consensus between different copies of order books by pooling. That’s what a mining pool is and it’s what a liquidity marketplace is. When you join a mining pool you are giving up your mempool and using the mempool of the mining pool orchestrator. When you utilize a liquidity marketplace you are outsourcing order book construction to the marketplace operator. And then, of course, the third step is to distribute the orchestration itself. We see things like Stratum V2 emerge as examples of this in layers zero and one. Liquidity Ads are a much less mature example in layer two, and there is not yet any equivalent in Nostr, to our knowledge, but this is the progression we expect to see for order books at arbitrary scales.
We’ve tried to walk through the reasoning here from the bottom up, but it’s also interesting to note that ex-Bitcoin Crypto, and Ethereum in particular, has done this backwards. They started off with the “world computer,” then they realised they needed infrastructure, which is where the “web3” meme came from. Then they realised they needed payments to incentivize the decentralized management of this infrastructure, and that’s “DeFi.” But then it turns out people only want to be paid in real money, not costlessly and centrally issued, questionably legal securities, so now Ether has to be money – ultrasound money, no less. Finally, they realized both that Ether is poor money and Ethereum layer one doesn’t scale, so most worthwhile commercial and development efforts have gone into plugging different flavors of stablecoin into the monetary role and different flavors of ZK-rollups into the scaling role. It is noteworthy that, while many such projects are technically impressive, they virtually all require some kind of central coordinator in order to function rather than endogenous incentives and market mechanisms.
The Bitcoin ecosystem is going through this same progression but is doing so in a more sensible order. Having built exceptionally robust foundations for money, and now trying to do so for payments, we are only now on the cusp of the “web3” equivalent.
The motivating factor here – the call to action – is that by building in this layered approach and buying into the narrative we have outlined in this piece rather than those promoted by the wider Crypto ecosystem, we really can disrupt many of these centralized intermediaries. We really can fix the Internet. And furthermore, we can provide defence in depth for the first ever and only credible sound, digital, programmable, free and open, decentralized money.
Perhaps both too abstract and too dystopian to be more commonly discussed, but today’s centralized Internet is surely a risk to Bitcoin and its users. If we could gradually replace the networking infrastructure of today with layers of markets, then surveillance and filtering of Bitcoin protocol data would become much harder, making Bitcoin safer and more robust. In other words, a healthy layer two improves layer one, and a better, fairer Internet protects Bitcoin. A proliferation of actually useful applications – as opposed to VC-driven securities fraud – makes the idea of banning Bitcoin increasingly absurd. And as the subsidy gradually decreases, miners have to increasingly depend on layer one instead of layer zero. This means blockspace has to become increasingly valuable. Direct, bank-like monetary usage of Bitcoin provides a floor for blockspace demand but higher layers that settle through Bitcoin will scale this up.
conclusion
If the reader is a Bitcoiner and wants to get rid of Ethereum; for the token to go to zero; for altcoins to go away; don’t make fun of them, educate them! Teach them that we can do whatever it is they want to do in a better, more scalable, more robust fashion. We don’t want to lose a generation of talented developers to schemes that go nowhere, which leave them disillusioned with the very idea of decentralized applications, and which teaches the general public to wrongfully equate these goals with financial scams.
And if the reader is on the Crypto side of this debate, if you are considering moving your project to Solana or Tron or whatever else, maybe consider moving it to Bitcoin instead. It will be harder at first, as building in layers always is, rather than going straight for the end goal. It will be more difficult to monetize, and, frankly, more difficult to attract talent, in the short-term … But, if engineered according to the design methodology presented in this paper, will probably be more robust, more sustainable, and make more economic sense.
Besides, if you don’t do it, someone else will.
end notes
(1) Note this eagerness was not possible in prior “digital money” projects precisely because the networks did not offer a single asking price. In b-money, for example, there were multiple bids for money creation provided by multiple users and so the full set of “completed bids” had to be evaluated to determine the “highest bids” for inclusion.
(2) This idea – “The Bitcoin methodology” – is explored in much more depth in present co-author Dhruv Bansal’s series, What Hath Satoshi Wrought?, part one of which, How Did Satoshi Think of Bitcoin? is available here: https://unchained.com/go/how-did-satoshi-think-of-bitcoin
(3) See Section 1: The Innovation from First Principles in Only The Strong Survive by present co-author Allen Farrington and fellow General Partner at Axiom, Anders Larson, for a more involved argument that, “Bitcoin’s distributed security is endogenous and depends on its value as money; and its value as money is endogenous and depends on its distributed security.” Available: https://www.axiombtc.capital/only
(4) It is also frankly unclear, and a source of increasingly fractious debate, how extensible or complete Lightning’s utility will be at maturity or if other payment protocols might emerge to either complement or supersede its various shortcomings. This is worthy of a separate discussion in its own right and we do not mean to pass judgment here, but we think it is worth i) acknowledging the contemporaneous debate which has arguably emerged precisely because of the discovery of the market’s true properties over years of its operation in the wild, and ii) encouraging utilization of the methodology of distributed order books we present in weighing up the pros and cons of any layer built on top of Bitcoin, whether competitive, complementary, or entirely orthogonal to Lightning.
(5) More thorough explanation available: https://thebitcoinmanual.com/articles/btc-submarine-swaps/
(6) This is a nontrivial problem and in many ways a fair recognition of its difficulty is the core of our argument. Bitcoin’s layer zero solved this problem by having a trivial order book and layer one solved it because both blocks and mempools are small, limiting the data required for independent nodes to synchronize. The datasets required to construct order books at higher layers (very much including the order books for lightning channels, liquidity, and routing) will naturally be much larger. The core problem worth tackling is creating market incentives for the decentralized and open aggregation of bids and asks without simply recreating centralized points of failure.
(7) Although long-form blogging is arguably de-risked and proven out already, with services such as https://yakihonne.com/ , https://highlighter.com/ , and https://habla.news all thriving.
(8) The curious reader is nonetheless strongly encouraged to read Jameson Lopp’s post, The Death of Decentralized Email, reflecting on his time as an SMTP engineer to recount how the protocol has been effectively captured by corporations such that regular users have little choice but to go through gatekeepers, making it de jure open but de facto closed. Lopp’s message is that this was a result of short-termist protocol design decisions initially conceived as fostering adoption but which placed too great a burden on those hoping to keep the service decentralized, and that this should serve as a cautionary tale for development of Bitcoin and its higher layers. Available: https://blog.lopp.net/death-of-decentralized-email/
(9) For our purposes, we assume about the above level of basic familiarity in addition to what we have just described and will not get into too much of a granular technical discussion of Nostr in this piece. For the interested reader, Shinobi has an excellent overview at Bitcoin Magazine, available: https://bitcoinmagazine.com/technical/what-makes-nostr-a-different-social-platform
We should add that Nostr development has not been entirely without controversy. The above commentary is intended as enthusiastic analysis in light of our broader thesis, but not as unequivocal endorsement. The interested reader is likewise pointed to an additionally excellent article by Shinobi in Bitcoin Magazine outlining the contemporary problems with key management in Nostr (available: https://bitcoinmagazine.com/technical/solving-nostr-key-management-issues) and a Medium post by Liran Cohen (available: https://medium.com/@itsliran/working-towards-interoperability-decentralized-identifiers-decentralized-web-nodes-verifiable-91839cb98f16) outlining a potential path for Nostr development to solve some of these issues by bringing the protocol more in line with the decentralization standards currently in development by W3C and DIF.
(10) And that it is not at all a coincidence that nearly identical comments were made six or more years ago by early Lightning developers and entrepreneurs trying to clarify the point of what they were doing amidst a backdrop of unrelenting hype around “initial coin offerings.”
(11) YouTube walkthrough available: https://www.youtube.com/watch?v=mVWufwzQ_RI and GitHub available: https://github.com/supertestnet/swap-service
(12) Nostr developer Pablo Fernandez described the ecosystem as follows: “Nostr is NIP-01, most other NIPs are protocols on top of Nostr. This is a powerful framework because it helps realize that, within the Nostr system, we can have multiple experiments of the same use-case and market dynamics dictate which protocols proliferate and which die. We have competing protocols for DMs, for Music, for computing markets, etc. This might seem chaotic (it is) but that it implies that we are able to experiment each use case as its own market instead of having Nostr's e.g. music experimentation to work or fail under a single proposal.”
(13) See https://vendata.io/dvms and https://noogle.lol/nip89 for examples of data vending machines emerging as Nostr-native markets for compute