tl;dr: Underappreciated and misunderstood, the token engineers of today merge best practices with the unique elements of crypto-economic systems. They will be the heroes of tomorrow.
Amidst all of the excitement around crypto-economic systems, decentralized markets, and the crypto assets that power them is a critical, but often overlooked discipline.
That discipline is known as Token Engineering.
Eventually, like other forms of engineering, we’ll see Ph.Ds awarded in the field (or given through a distributed consensus mechanism of peer-recognized excellence).
Token engineering will take its place alongside mechanical, electrical, and all of the other forms as a key driver of value in digital-native economies.
Why does Token Engineering Matter?
Even asking that question is a bit ridiculous, since it’s like asking “why do civil engineers matter for bridges?”
Hyperbole aside, they matter a lot, because at the heart of crypto-economic systems lies a design theory for incentives and punishments that is supposed to ensure a “wealth of the commons.”
If those economic incentives are not conceptualized, simulated, and then built according to specifications, all of the value in a network becomes vulnerable. (Hint: that’s why I love Nexus Mutual so much. Disclosure: I am long NXM)
Like any bridge, building, or device in your home, the same is true for engineering across the board.
I’m not an engineer by training. I’m a bit of a techno-hacker, but without engineers, and in particular, Token Engineers, the millions of crypto-economic experiments we are going to see emerge in the next few decades will have problems.
Actually, they will have problems no matter what, but absent a token engineering discipline, the problems will manifest at even larger rates.
If there’s a growth industry and a job with high future earning potential, it’s Token Engineering.
The Syllabus for Token Engineers
At some future institution, let’s call it crypto-MIT, there will be an introductory course for eager, young, future Token Engineers called “The Degree of Token Usage in a Product.”
It’s going to be based on Trent McConaghy’s latest blog post, “Should Product-Market Fit Come Before Tokens.”
We touched on Trent’s previous blog post last week in Why Crypto-Economic Systems will be more secure, where he talked about how to verify token-based systems.
Now, he takes a step back from the verification to ask: “do you even need a token and, if so, when?”
First, like the engineer that he is, a framework for token types is offered.
- “Product doesn’t use tokens.
This is the simplest. Indexing protocol TheGraph is a good example. Even without tokens, the product could nonetheless be compelling, by using another blockchain benefit like decentralized control, immutability / provenance, high availability, or censorship-resistance. Or, it could help other blockchain products, like TheGraph. (If your product doesn’t use a token and fit any of these, then use a database.)
- Product uses tokens but doesn’t have its own token.
The decentralized exchange Uniswap is a good example. It has token dynamics and therefore needed design and verification around those token dynamics. But it hasn’t introduced a new token (yet).
- Product uses tokens and has its own token, but it does not rely on it.
Lending protocol Compound is a good example here. It has tokens (COMP for governance), but they’re not critical to the core product offering (loans). Synthetix uses tokens closer to the core of its product (stake SNX to mint) but gives alternatives so you don’t need its token (stake ETH to mint).
- Product does rely on its own token.
Without the new token, the protocol would not work. Bitcoin, Ethereum, arweave, and MakerDAO are good examples. These are typically the hardest to design, but they’re also the most “crypto native” as they leverage blockchain technology the most, for example as incentive machines.
Understanding tokens as crypto-assets is challenging enough. Getting your head around all the various permutations and capabilities of tokens can be mind-boggling, but this framework really helped simplify things for me.
What I really loved about this list though is that, for each type of token example, he highlighted existing crypto-economic systems which deploy that model. I also loved the fact that Arweave made a list with BTC, ETH, and MakerDAO, since I’m an advisor to the project and a marketer who loves branding by association. :)
Except for the first one, I’ve used them all so it helped things click a bit more.
The Zen masters might call it “a moment of enlightenment.”
Engineering Best Practices
The moment of enlightenment was prolonged (I really do enjoy reading Trent’s stuff) when he followed the tried and true “same, but different” methodology that I favor in marketing.
Token engineering may be different because it involves the use of economics and incentives to make the system work instead of water, electricity, or nuclear power (though all of those, I would guess will touch these network in some way).
However, it is the same because the principles that have served engineers well for centuries apply here as well.
These strategies include:
- minimize dependency on tokens
- start simple
- re-use token design
It seems like this is good advice, no matter what kind of engineer you are. What’s more, following this advice makes you an even better engineer.
Now that I think I about it, engineering is like marketing. “We’re all in marketing, it’s just that some of us know it.”
Engineering is the same way and here’s the key piece of advice that served as the coup de grace:
10x software engineers think more quickly; 100xers import (and focus on where they add value).https://blog.oceanprotocol.com/should-product-market-fit-come-before-tokens-6c542a75c8dc
The framework for thinking about different types of tokens within different types of crypto-economic systems was extremely helpful.
The similarities with existing engineering best practices gives me confidence that token design will only get better and better as the field of token engineering matures.
But the reminder that 100xers import and focus on value is the ultimate doctrine for me: Before you invent, see if you can adopt. Then, only invent on top of that.
It seems obvious, but it’s a great reminder because it allows you to build, create, deploy, and test faster.
The beauty of token engineering in crypto is that the designs and software are open-source, which means re-usability is a given and innovation is poised to go exponential.
We may not think about the engineers who made our lives better in the physical world, but without them, we don’t have much.
We may not think about token engineers as we see crypto assets “moon” and “lambo,” but they will be the silent heroes of this revolution.
It reminds me of the BASF commercial from when I was a kid…