Building Company Playbook #6: Using token design for financial and product success
Building Company Playbook #6: Using token design for financial and product success
This entry will focus on cryptoeconomics and token engineering, and the key considerations when designing token-based projects and systems.
Gm Fintech Architects —
Today we are continuing our Building Company Playbook series, targeted at addressing the key questions in getting Fintech and DeFi projects off the ground. This entry will focus on cryptoeconomics and token engineering, and the key considerations when designing token-based projects and systems.
For prior series, here are the guides so far:
If you got value from this article, let us know your thoughts! And to recommend new topics and companies for coverage, leave a note below.
Long Take
Expanding the Scope
The business of entrepreneurship can feel like the creative act of a single person. The image of the tortured artist, or the embattled tech genius, comes to mind. Can Elon take on the world? Can Picasso tell us the truth?
Fintech companies, in particular, appear to be individual participants in the economy trying to take value and share for themselves. Build positive unit economics, grow the client base, defend your network effects, and IPO into a stream of cash from happy investors. This is the single player game in modern economics. It coincides with the theory of the firm, and the maximization of various microeconomic levers.
But not all problems are like this. Some are above the paygrade of a single company, and are at the level of systems and macroeconomics. Instead of thinking about the particular unit economics of your thing, you are put into a place where you have to think about the entire value chain and *all* of the different actors that are touching a particular good or service. Questions about public goods and the tragedy of the commons become the core consideration, and the incentives of everyone involved in the sector are as important as those of your role in itself.
This is a blessing. In the past, macroeconomics had been relegated to a theoretical pseudo-science. While economists could analyze the past, they could hardly engineer experiments. Data could be scraped from historical accidents — one developing country against another for a decade after the collapse of the USSR, for example — but not intentionally engineered.
Live economies impact the lives of billions, and only a select few people running government can play with the variables of money supply, fiscal policy, or tax rates. Mistakes are dangerous, and can damage livelihoods at scale.
Cryptoeconomics, and token engineering within this discipline, are a way to bring experimentation into the economic skillset. Using protocols and tokens, we can design value generation loops and financial mechanisms that function like economies in themselves. Such experiment can succeed beyond all expectation — see Bitcoin. Or they can fail profoundly — see Terra/Luna. The more important thing is the ability to experiment in itself, and to design system-level protocols that consider all participants and all markets that interact with them, and then to improve those protocols in real time.
Necessary Disambiguation
Before diving deeper into our view of token engineering and design, let’s start with some things that people can get wrong.
The word “token” means a lot of things to a lot of people. Like a “hyperlink” in the media Internet, it can encompass many different things. Is this hyperlink a book, or a song, or a text, or a sign-up screen, or a phishing scam? You can see how it is incorrect to think about the hyperlink as the substance of the hyperlink.
Similarly, tokens are the economic abstraction on blockchains. They stand in for whatever the thing is that they represent. That thing may be a digital asset, whether a security, commodity, money, or a nothing. That thing may be a digital object, often called a non-fungible token (NFT), and refer to an image, a plot of land, an interactive game, or a link to some cloud storage. The thing in common is that tokens are digitally scarce and can be owned, with the economic architecture of blockchains enforcing that condition. Further, they can function across multiple markets and financial primitives — payments, trading, savings, lending — just by taking on the particular standard in which they are embodied.
When we talk about token engineering and cryptoeconomics, we are not talking about “tokenization”. Taking a particular real world asset, like a bond, and transforming it into a digitally native version, like a wrapped bond, or a bond token, or a deposit token for bank cash, is not the magic thing. It is interesting to the extent this bond is now subject to the financial markets of Web3, but it is not interesting to the extent it does not invoke the entire value chain and ecosystem needed to produce it.
Further, we are not thinking of tokens as shadow equity. Imagine you have some particular digital brokerage platform or a centralized exchange. Adding a new meme representation of value for this exchange — looking at you Binance, Huobi, FTX and every other CEX that launched a lazy exchange token — is not real cryptoeconomics at work. It is attention and capital markets arbitrage, which will fail to hold value unless you engineer the tokens to become valuable flows between the various utilities of your products.
Additionally, we want to note the distinction between (1) hard mechanistic token designs, and (2) softer qualitative versions thereof. In the first case, there are protocols that require highly specific and technical specifications. The generation and function of tokens is completely mathematical. For Ethereum to function, quite literally, everything about the token supply and usage is coded into the blockchain. Yes, new functionalities emerge with smart contract applications, but the core value proposition is written in code and is immutable.
Alternately, for higher level and applications, even those that offer deterministic token functionality — see MakerDAO or Curve.fi, among many other “projects” and “platforms” — token design and usage is much more flexible and ambiguous. When you introduce the complex behavior of people and tribes in the usage and management of your token, the resulting capabilities and intended use will be far more flexible, and often less stable.
Last, we side-step the questions of token classification (e.g., money, utility, security, commodity) and particular DeFi implementations (e.g., AMM, lending, wrappers, staking). The former is a question we had answered in 2018.
For the latter, this 2021 paper on DeFi from Wharton to which we contributed could be a helpful addendum. Neither of those labeling diversions are helpful for a first principles design of your project’s token functionalities. They are needed as comparable designs and mechanisms so you can reason by analogy, but are not the right starting point. Our goal here is to get you on the path, rather than obsess with higher level detail.
Building around Endogenous Factors
In a fintech company, you are spending a lot of time understanding your customers and suppliers. In a Web3 project, you are going to need to understand every single type of person that can interact with your code and application.
Start by asking yourself what exactly your product and service wants to do? What is its purpose, and how does it fulfill its purpose? Perhaps your project wants to create a new money, and in doing so maximize the adoption of that money. Or perhaps it wants to maximize the number of data providers integrating into some oracle system. Or perhaps it wants to attract and transform capital from one form to another. Or perhaps it wants to shift risk form factors around. Or maybe it wants to bring in lots of new developers into an app store. Or maybe it just wants art, lots of digital art in a vault somewhere. Don’t be vague, pick a thing.