PREVIOUSLY ON TOKENOMICS…
In our first post, we explained what Tokenomics is, explored some common misconceptions around Tokenomics (and Tokenmetrics), and discussed why it's such an important concept to master.
If you haven't yet read it, it’s a good place to start.
In this blog, we’ll present our practical, 5-step process for designing and building Tokenomics.
Step 1: Identify your Users
Step 2: Identify Their Needs
Step 3: Define Actions & Goals
Step 4: Build an Incentive mechanism
Step 5: Test and Simulate KPIs
Previously, we defined Tokenomics as the economic mechanism for motivating and aligning multi-sided platform participants to achieve an optimal outcome for all parties involved. The engine, the fuel, and the generator. Today, we’ll show how to start the engines (and keep them running), how to add the proper fuel (at the right time), and how to use this "stored energy" to generate more energy.
Mechanism Design (i.e. Tokenomics) and product design are deeply entwined, and follow similar steps – but what makes one product superior to another?
We all own products that we “can’t do without”. Some are obvious like your smartphone or TV, and some you take for granted and notice only after they’ve malfunctioned or gone (e.g. car, fridge, an ex).
The dry definition of product value is, “The benefit that a customer gets by using a product to satisfy their needs, minus costs.” We value these products because they make our lives "better". We like the products we like because they "fulfill our needs". They keep us satisfied. On rare occasions, they exceed our expectations - these are the products we love.
Everything we do, whether we’re conscious of it or not, is based on perceived value. Is it worth my time, money, or effort? We calculate every decision’s value for money or ROI, according to our intrinsic “incentives function”. This is why adding incentives methodically can make all the difference.
One of the greatest benefits of well-thought and executed Tokenomics is the ability to adjust and time incentives. Done right it can drive a mighty, self-perpetuating, network effect and viral community growth. Way back in 2012, when we built Colored Coins, there was another protocol called Counterparty. We (#objectively) provided a better technical value, but they grew 4X faster than us since they had an incentive mechanism and community built around their protocol while we didn't see (back then) the value of adding Tokenomics to our open-source code.
Step 0: Do You Want to Build (on/) a Blockchain?
Like most novel technologies, using a blockchain as a tool has its tradeoffs and its merits, depending on what you plan to build. Choosing the wrong tool may not only be suboptimal but may hinder your work and make the end product unfeasible.Before embarking on this journey, you should determine whether this is the right tool for the job and ask yourself some questions.
Do you really need a blockchain? Do Immutability and Transparency benefit or hurt the product? Can a smart contract (which is basically a self-executing lawyer and judge written into code) be written to replace a "human trust-entity"? Does removing middlemen and Central Authorities create a never-before profitable service? What is the added value of having a token for your product?
In short, is using a blockchain the right strategy for you or just a shiny new hammer looking for an old, rusty nail?
A blockchain can be an immensely powerful tool but as you know with great power…
Most of the list items below are features, not bugs, but as with all double-edged swords - you should handle them with care and make sure you don’t lose your sheath.
The decentralized nature of DLTs entails redundancies as all nodes in the network "hold" the same copy of the transaction history, which prioritizes security over inefficiency (SPoF). Scalability is at odds with decentralization or computing power (ETH vs. SOL). Immutability prioritizes data integrity and trust over development speed and flexibility (no undo button). Self-management of private keys (#NYKNYC) trades off autonomy with responsibility. Public, on-chain data favors transparency over privacy, and interoperability favors a wider reach over bridges' risk and complexity. Finally, creating a legal structure for a crypto entity and the vagueness around regulations mean few know how to navigate this maze.
That said, "one man's trash is another man's treasure" and if you're a glass-half-full kind of person (as all entrepreneurs should be), most of the above can be a tremendous opportunity for your project.
The preceding tradeoffs result in a relatively homogenous user profile or persona, which can help you better refine your target audience before interacting with them and thus better match your product design.
If the answer to step 0 is "yes", the next step is…
Step 1: Identify your Users
A long, long time ago, during my days at uni, there was a 7-Eleven-like store less than a minute’s walk from where I lived. During the day, a young guy oversaw the place, and at nightfall, an older gentleman was in charge.
To say there was a night and day difference between them would be an understatement. Whenever I needed help finding a product during the day, the young guy would mumble/grunt and point to its location. If I asked the same question during the night shift, the older gentleman (whom I later realized was the store owner) would do a double-somersault just to physically show me where it was.
The attitude disparity stuck with me. It’s the difference between an employee/service provider doing the bare minimum for the agreed-upon "incentive", and an owner with skin in the game.
Mapping the Key Users
When trying to identify your project's key users, you should ask yourself the following questions:
Who is creating value?
Who is providing a service?
Who is providing resources?
Who is exerting meaningful effort?
Who is taking the risks?
Every protocol has its leading actors, who provide the product or service, and the supporting actors who enhance and add additional value to the service. Let's walk through some examples.
The main actors and "literally" the value creators who do the work for the OG – Bitcoin – are the miners who compete to produce the next block, hoping to win the block reward while keeping the blockchain safe and consistent.
The main actors in Ethereum are currently its miners, who basically provide the same service. When ETH 2.0 is released and moves from PoW to PoS, it will be the validators. In exchange for potential rewards, the validators provide resources to the network by running nodes and creating blocks. They also provide better security, since the network gets better at thwarting attacks as more ETH is staked (i.e. it requires more ETH to control most of the network). The validators take on the risk of getting slashed and losing their staked ETH for misbehaving, according to the rules of the platform.
The supporting actors will be the users joining a staking pool by staking their ETH with their chosen validator. In addition, by staking their ETH, both the validators and their supporters add value by making ETH scarcer. Moreover, joining a staking pool provides an important signaling, to the rest of the network, of who is a "good" validator.
Later, in step #4, we will use this contribution-hierarchy to determine who is "more important" and thus deserves greater rewards.
Alienate Bad Actors
It is vitally important to map the type of users you want to stave off the service. Every service has its bad apples that reside on a spectrum from the annoying (Twitter bots) on one end, to the ones rendering the service unusable. In crypto, one user can single-handily bankrupt the service.
“Code is law” and as a web3 developer, you make the “rules of the game” through your smart contracts.
Here again (*with the current technology), you have the tradeoff between asking your users to complete a KYC to limit the number of wallets per user but you’ll lose the who can’t or don’t want you to “know them”. It is more than likely that in the future we’ll have some DID solution to potentially eliminate the bot problem but like computer viruses - they’ll always be lurking and we hope and believe that this will be a privacy conserving service and not the opposite.
More technical projects are trying to tackle the MEV problem. Using or Building on top of a service that provides a solution to MEV can [substantially] enhance/improve your product.
Another simple framework is to differentiate between investors and speculators. Investors are long-term players who care about the success of the project. These users not only invest their time, effort and tokens into the service but may add more value by helping others in the community and spreading the word – a by-product of having skin in the game and/or love for the product. There is a noticeable difference between projects with a cohesive and prospering community, and projects where users are just trying to reap as many rewards as possible while providing the minimal value possible - if any.
Warm to the Early Bird
The crypto community keeps repeating the mantras “crypto is in its infancy” and #WeSoEarly because it’s true. The UX is generally “frictionful”, clunky, clumsy, and cumbersome, which deters the tech-phobics. High volatility, known and unknown unknowns, and other associated risks deter the more risk-averse users.
This is both a blessing and a curse. The up-sides are: there is room for growth, room for improvement, and as a web3 builder, you have a more homogeneous user-type and a great number of untapped potential users. The downside is you (currently) have only a few hundred million users, instead of billions.
You can paint crypto users, with a broad brush, as being early adopters. At this stage (2022), we suggest focusing on these early adopters or “the believers” first and tackling closing the chasm later. This is no excuse for not investing in the UX/UI – on the contrary, it can be a great differentiator.
De facto, this means to design the product and Tokenomics around the crypto natives. Those users already have a wallet (probably Metamask), they probably have their favorite chain or two (Ethereum, Solana. Algorand, Terra, etc.). They are cognizant of the risks, which like most things seem less scary once you’ve experienced them, and they are well aware of the potential asymmetric rewards involved.
Focusing on these users will save you a lot of time and effort in acquiring users, especially at the bootstrapping phase of your platform. Once the network effects have started to kick in you can broaden your target audience.
Chickens and Eggs – Who to Court First?
A market is a place where buyers and sellers exchange value. The market’s value is derived from its participants. The one billion Satoshi question is how to get the flywheel going? Despite what you may hear on Youtube (compulsory) ads, there’s no magic formula of “this is how you build a viral product”. Given you’re building something people want, you need to also build trust and provide your users with “proof”.
Some users are more important than others, especially at the beginning. A decent rule of thumb is to start with the value creators i.e. the supply side. For Uber, it was with black-cars owners. For AAVE it’s the lenders, For data providers like SubQuery it’s the indexers and for Forta, it’s threat detection-bot devs.
Another tactic is focusing on a niche or specific segment. Amazon did this with books and Facebook (sorry, “Meta”) with college students. In crypto, this can mean focusing on one platform that is aligned with your user's needs. For a game developer, it may be choosing Solana or Polygon over the (currently) slow and expensive Ethereum. On the other hand, for a DeFi protocol, Ethereum offers the best liquidity out there with the biggest network effect.
Another way to provide quality evidence is by using a trustworthy witness. In a low-trust environment, KOLs and experts with a proven track record can foster trust, credibility, and highlight the benefits, obvious and obscure, associated with the product.
Many P2E projects, start with offering NFTs in the form of characters and/or lands to grow and build their community and later on work on building the game itself. This again is not a silver bullet and can work if done craftily by the right team and community development capabilities.
Step 2: Identify Their Needs
Which is better: a minivan or an electric scooter? CEXes or DEXes? P2E or PS6? Ethereum or Solana? The answer of course is "it depends". Different users of different products have different (and unique) needs, but there are universal needs that all users share. These needs reflect aspects of Maslow's hierarchy of needs. This is a modified version that fits the crypto world.
Like with Maslow’s pyramid, these steps are in order, meaning you don’t optimize the UX before securing their security needs. When trying to anticipate your users’ needs, some questions you can ask yourself are:
What is the risk tolerance of the average user?
What does each party want to achieve or gain?
How do you reward in proportion to contribution?
How can you articulate and communicate your solution in a way that promotes predictability?
What level of quality they will need?
How can you align the needs of all users?
Later, when you get to step #5 where you test and simulate your assumptions, you should return to this step with your gained insights and adjust them accordingly.
Different personas have different risk tolerance and are attracted to different APYs. If Degens are the users you want to attract, offer triple+ digit APYs with riskier strategies. For long-term investors, it may be better to offer lower rewards, with a less aggressive inflation/emission schedule.
Security is the bedrock of every crypto project and is thus positioned at the base of the pyramid. In the same way, a person does not care how tasty is his pizza if the roof above his head is about to fall off. It’s the single basic element your project must-have. The crypto-verse is notorious for its hacked and rugged projects and more often than not, it’s particularly hard to restore user trust in a project, once it’s hacked. Another word for security is certainty. User needs change with time. For example the longer a project exists, the safer it’s regarded to be and other needs come into play.
ROI is also a universal need and all our decisions are filtered through our mental cost-benefit function. Nexus Protocol provides both a level of certainty and ROI. It alleviates the stress and uncertainty commonly accompanied by having a leveraged position by its built-in anti-liquidation mechanism - while simultaneously providing the benefits of a greater return.
Oracles like Chainlink and data and infrastructure providers like Subquery provide Predictability, Consistency, and Reliability in many ways. For one, they use multiple data sources to prevent skewed unreliable information. Using these types of services can also boost the quality, performance, and variety of your to-be dApp. When you have a reliable data source you use it to foresee and predict future behavior using tools different tools like AI, ML, NLP (and other buzzwords/buzzworthy acronyms). You can offer more variety by adding support to more Wallets or additional smart contract platforms.
Another example is Subquery’s new and improved payment methods. It offers a variety of plans to best fit different users’ needs. Subquery created this new model after getting direct feedback from the community and indirect feedback from statistics and behavioral analysis.
After addressing these four levels you can give more attention to enhancing the user’s experience. This can be done through a better-looking and performing UI, enhanced tutorials, and guides, new features, and sometimes different forms of Easter eggs. The common goal of the above is to surprise the user (in a positive way) and to exceed expectations.
Combining all these steps can be the difference between a product no one wants, a product users are indifferent to or slightly like, and a product they love, appreciate, and feel compelled to share with their friends, family, or whoever is willing to listen.
To be continued…
Want to share thoughts?