Middlewhere?
pronounced: middleware (originally published on Medium Dec 1st 2021)
To some, this may sound like a statement of the obvious. However, I see it worthwhile for all of us to have a common language, a consensus view of reality. Therefore, I still thought about writing out a piece on how investment opportunities actually form a spectrum ranging from companies on one side, and DApps on the other. This can be seen as a reference for investors as we evaluate opportunities with different valuations, upsides, differences in survivability, and their performance in different market cycles. This can also be a reference for entrepreneurs to have a better sense of where their project stands in a larger ecosystem, — and tips on how to relocate on the spectrum.
Valuation: Given the nature of the beast, DAOs tend to be appraised at higher valuations. The open participation allows hundreds to easily become users, or service providers. Tens of people serving tens of people, in the confines of companies, create only so many transactions and so much value. Comparing that to the potential of an application with hundreds serving hundreds, the value of companies can be dwarfed by the value of DApps.
Growth: In a market where value is influenced by future value, it is clear that growth is not linearly independent of the valuation itself. Being roughly a measure of how fast we get to a meaningful size and increased defensibility, growth is another facet in which DApps can outperform companies. The important part here is not really the ultimate, or say, an end-state valuation similar to an eventual carrying capacity valuation, but also how fast we really get there -the speed with which we achieve the eventual (hopefully higher) valuations.
Successful DApps have a higher chance of achieving great multipliers faster than their counterparts organized as companies even if they are executing on the same value propositions. The steady-state size of a DApp, in which hundreds or thousands are serving hundreds or thousands is extremely arduous in the context of companies that have frictions all around, and I mean all around, with everything that matters — adding data, talent, products, and customers. In addition to the greater upside of eventual value created, DApps also have a rate advantage because whatever the eventual hypothetical size a given app may have as a function of the market size of the services, a given DApp also re-iterates faster and onboards what counts (data, talent, services, and users) faster.
Survivability: Survivability is a measure of how likely an initiative is to last for another X years. When we speak of survivability we should be referring to a 3-year survivability or 5-year survivability. When we refer to a particular horizon of survivability, then within that, we should also remember that the likelihood for a project to last for another 3-years is not the same over the course of its life, so a 3-year or 5-year survivability will not be intrinsic to a company, but it will also change over time. A 3-year survivability of a given company or DApp will therefore be different 7 months into its existence or 3 months after going live, etc. In general, we may see survivability go down from inception until it stands the test of time* while its peers drop dead or are abandoned, and then it begins to rise again.
(* Time here is a proxy variable that we refer to because we can more easily measure uniformly across different applications, and also because we already have, as humans/society, decided on a way to measure it, refer to it, or experience it. Instead of survivability for a period of X time, at time point T we could speak of surviving for another TVL of V at value locked at value ‘u’, or other metrics such as surviving for another T transaction at a point of having had committed transactions of ‘c,’ etc. Whether we refer to ‘X’ more time of survival at time T, another ‘V more value for current value of u’, we can always think of actions like commits (?), redemptions, etc., you name it in the form or survivability where what we care to have be it time, value locked or transaction can be measured that will first decrease as a function of its junior variable and then increase).
Cyclicality: In up markets or down, the value appraised in all companies and projects will be subject to change. So ok, duh. The further to the right an opportunity is on the Comp-DApp spectrum, the more likely it will severely move with the market cycles. Ok that’s not a groundbreaking statement either, right? The more like a DApp an initiative is, and less like a company, the more volatile its value/token will be changing with the market sentiment. The more interesting teaching of the illustration above is on how each investment type will perform — as a function of their location — in different phases of the market cycle.
When ‘crypto markets’ have exuberance, DApps and their tokens have seasons of positive market sentiment. In times of crypto fear, uncertainty, and doubt, every DApp independent of the soundness of the code, talent, vision, and market size is seen as a sh#tcoin. Until the timewe can see a decoupling of crypto winds from the value in DApps, and the market matures away from the continued correlation between DApp tokens and crypto markets, we can expect investor and talent interest to be a lagging variable of prices. As the price goes up, developers and investors will want tokens. As prices flank, and as the social organisms we are, we will see it as less worthwhile to build a DApp as other members of our species — in the form of market participants — signals to us, our work and capital is not demanded there yet, or anymore.
So what happens in the left hand-side of the spectrum? What if you are looking at a DApp fetching real world data or assets for other DApps to work with, on-chain. Or further to the left, what if you are a company issuing old world assets on-chain or even more to the left, if you are a company that does not even try to touch public chains and integrate to other DApps? The further left we go the less upside, less risk, and less volatility we are looking at. Why? The stakeholders, users, and developers were not part of the solution or the ecosystem because of the value in tokens. If the driver was not the token valuation, then the incentive is not immediately reduced in a bear market.
Reflection for investors:
An investor who is looking to model and expect value, could higher E(v) on tokens of DApps especially when the pace of adding new developers, features, or money — in bull markets — is high. Investors investing here should also be prepared to plan for exits as we approach the bear markets which can be best indexed with slowdown in the rate of growth with on-chain transactions. While E(v) of a DApps portfolio is theoretically higher, timing becomes more important both for exits and entries to actually capture that higher E(V). There will be investments in the left and the right hand side of the spectrum worth making independent of the cycle stage, however the 3- or 5- year survivability of DApp opportunities may be reduced if the E(V) optimizing investors are late to the party. On the left, however, one can expect to have less new value created but also less of it will be wiped, with less upside and volatility. In cold markets investing in more DApps with a clear market and in hot markets where the potential of loss has grown, investing in more companies offers greater protection and still an opportunity to capture upsides in DApps. As investors, I think we owe ourselves and our investments that we support infrastructure and ensure the future of innovation that depends on our survival. Don’t be the hedge fund that goes out of business when tokens get a bad rep, the next iteration of DApps will still need you.
Reflection for entrepreneurs:
Logistically, going from the far left to going to the far right is a treacherous path and like most things with physical limits, starting conditions implicate some barriers to downstream differentiation. Here are some initial thoughts on moving into and out of the ‘middlewhere’, the transitional zone between the old and the new…
If you have raised money with equity, you have bureaucracy around money you can raise, decisions you can take, obligations to talent, and obligations to renew filings. If your contracts with your named customers are pdfs, you are selling software as a service. In short, you are far left, and you can begin by —
a) Decentralizing the infrastructure that houses the data and runs the computation, and let each client of yours set up a node. Instead of data you and your servers provide, they can then rely on the servers they pay for on their own. The servers will be running the service of your app and they will have an immediate look at the node that has the same information as every other node. You can charge the users per node they host + transactions they run, and collect the payments via smart contracts using stable coins. You would also pay them a portion of the transaction fees that other users pay, block-by-block. This will ensure incentives to run the nodes even when they are not trying to propagate a transaction. If this proves to be a hard sell you may encourage your clients to leverage a node-as-a-service company (i.e. BlockDaemon, or BisonTrails) so that the clients don’t have to rely on the servers your company hosts for them.
b) Making it easy for new users to come online in your network. Instead of having to meet your company’s sales and onboarding team, open-source the onboarding materials, and make it easy to run your applications code on their node. If this proves to be a hard sell for you out of concerns for using the code, you may ask them to pledge collateral for the duration they are given access to run the code.
c) Making it easy for the data or results of your computation to be read by other Decentralized applications. If you are tracking assets, liabilities, or data on some private or permissioned chain out of concerns for privacy, for example, enable querying of the data by approved parties in the form of multi-party computation or ZK proofs so that at least the ‘conclusions’ of the data can be used by public chain activities. You can also streamline how an address will be added to or removed from the list addresses that can run limited queries on otherwise private data.
d) Turning the logic of what you do to smart contracts. This effort will be similar to digitization that companies had to go through. Similar to how companies updated the signing process to Docusign to enhance the deal execution process, or artifact data to ERP-compatible information, whatever your digitized service is already doing can now be done on smart contract. If you are re-coding the sale of an asset from one party to the next you can make the contract of purchase on chain, if you are tracking a certain action like quality control etc., or recording the payment for it, all of that can be done on chain, with the data about the assets accessible with links to off-chain data. If you are recording who can sign for what, or what investor communications were sent, all of this can be blockchainified/on-chained.
What if you are, yes a company, still, have named clients, but you are already working primarily with public chains, assets therein, and data about said assets? Even though you may be a private company, how can you further move to the right, in this ‘middlewhere’ space?What could you do then to further decentralize — if it is right for you?
a) If your users are not averse to dealing with tokens, begin accepting payments in tokens native to your application or stable coins that will immediately be turned into the tokens of your application. This can be further strengthened by initiating a burn mechanism of the token, and reducing fee structures for token holders. It could also be disempowered if you receive part stable-coin part tokens native to the application or introduce an emission of the tokens made available to spend for your company. As loosely or closely, tie the payments your clients make to the value of the token. Observe nuances to be a utility token and not a security if possible. I don’t encourage doing this in the US where no matter what you call your token, an existence of a tie between the value of the token to the value created by a select group of individuals working in a company will likely be called a security. If we evolve to a future in the US where the SEC is not a merit regulator but a disclosure regulator, then with specific questionnaires and records of informed purchases you may be safe even in the US. SEC time is about 10x slower than crypto-time.
b) If you don’t have a streamlined and digitized service, you should first standardize the service so that it is digitized. Secondly, blockchainifying/onchaining the digital service will also be crucial by putting the activity on-chain and wielded by smart contacts. If you are a high touch, white glove service for custody, audit, or portfolio tracking, think how you can track the downstream value a client secures, generates, or commands using your application and be consistently paid for that in tokens native to your application?
c) Pay the team in tokens native to the application or future revenues of the company placed on a smart contract. This could help you find those who invest in the vision, talent that is more missionary than mercenary, and foster an employee owned company culture where chiefdoms and territories can be dissolved in favor of ‘it may not be my job but it’s my responsibility’.
d) Integrate with more DApps, be an interface to access, manage, track or otherwise engage more applications for your customers. Decentralized applications are hungry beasts looking for venues of growth. They are positioned to reward those who contribute value. Find ways to make these integrations profitable, be that bounty programs, air-drops, or token swaps.
If your project is in the second category of this middlewhere — in the translational area still- further to the right of the spectrum, what is the recipe for success? You got the right idea, most of our future will be on-chain from finding mates, to getting jobs, receiving income, etc., and there is a big wide world out there that is not reflected on, commanded by smart contracts. You are well placed in your project’s organization to scale leveraging the dynamics of DApps, but what are points to continue to get right?
a) Don’t lose your token, don’t lose its ability to trace the value your project delivers.
b) Further develop your governance of prioritizing what old-world assets, data, talent and integration you can bring into your system.
c) Integrate the best elements of the code-base that the competing DApps have, smaller than the other DApps, the more ambitious they will be. Love them, support them, and learn from them. Like cultivating your rival for the discipline it can offer you. When in doubt, think ‘what would Vitalik do?’ remembering his response to ETC.
d) Bridge more DApps to off-chain activities of today, and bring more off-chain activities on chain, and be there for everyone on your left to enable them to talk the language of more DApps.
If your project is a DApp working with assets, data, and computation completely on chain, well you are already worth your code in gold. I would say keep doing what you are doing but have seen far too many DApps fail to say that. Here is a short-list:
a) Maintain stellar tokenomics, intelligently reward talent, other DApps, and users that offer value.
b) Maintain stellar governance, enable low-code or no code improvement proposals, budget suggestions, product and feature requests, and investments from the treasury.
c) Maintain stellar security, protect your users by enabling and rewarding best cyber security practices, safe participation to the extent that can be measured with on-chain activity.
d) Maintain stellar usability, continue to allow individual, SME, enterprise and DApps to integrate easily.