Overcoming ‘Token Debt’

How protocol teams can think about technical, financial, and social debt when designing (or re-designing) a token.

One of the primary momentum killers for crypto projects is a phenomenon I call “token debt.” 

We all know about “technical debt,” in which the accumulation of product decisions creates codebase issues that must be addressed later. Token debt works similarly, afflicting crypto protocols that have issued a token but must make significant protocol changes and re-architect the token to capture value. If the tokenomics aren’t optimized, projects need to be diligent about fixing them.

Token debt is even more damaging than technical debt alone because it typically bundles three problems together: financial, social, and technical debt.

Financial debt

Projects leverage tokens (NFTs and fungible assets) to incentivize network participants to take a particular action, such as trade or provide liquidity. If those incentives aren’t having the desired effect, the project is spending resources incentivizing suboptimal activity. While this isn’t too significant for one-time distributions, the longer an incentive distribution goes on, the bigger the financial opportunity cost can become for projects. 

Social debt

Tokens don’t exist in a vacuum. They are held by a community of users. So, if a token loses utility or fails to bring the value users expect, it can eventually cause rifts in communities. An analog to social debt in the web2 world is post-Musk Twitter, as each algorithmic adjustment causes grumbles among users who don’t like the updated product experience. We’ve also seen social debt during the crypto bear market, during which tokens lose some of their desirability. This has caused some protocols to remove their tokens altogether (e.g., Pollen), which risks fracturing their communities because the promised utility is no longer there.

Technical debt 

Rearchitecting a token midstream often requires rearchitecting the protocol, which comes with inherent technical debt. As the name suggests, technical debt builds over time. Tokens act as mechanisms for bootstrapping projects and incentivizing users, which can expedite a virtuous flywheel. But tokens also compound technical debt at an even faster rate given their direct financial value.

A word on token design

Broadly speaking, tokens can be core or adjacent to the protocol. Core tokens often act as native economic units and provide network security — the product cannot function without them (e.g., Ethereum, Arweave, Helium). Core tokens are more likely to face future issues with token debt because the token and protocol are fused together. 

By contrast, adjacent tokens (e.g., governance tokens) are loosely tied to the protocol, offering greater flexibility in future token utility and design. Protocol or product-adjacent tokens are less encumbered by token debt — with the tradeoff that they capture less value. That said, devs must still anticipate future decisions regarding the needs of the protocol/product when designing the token

Overcoming token debt in the wild

The easiest way to deal with token debt is to avoid having too much of it in the first place, but like in all startups, adapting to changing circumstances is part of the game. This means thinking through the financial, social, and technical challenges from the outset and swiftly iterating on protocol tokens as issues arise. Protocol-adjacent tokens are slightly different because they offer more flexibility and allow teams that are still finding product-market fit to adapt their tokens to new user and protocol needs. 

While the history book is littered with crypto protocols and blockchains that failed to overcome token debt, that doesn’t mean it’s impossible. It’s worth quickly looking at three teams overcoming significant token debt.

Helium: Redesigning a multi-token network 

Helium, a decentralized wireless network, pioneered one of crypto’s most exciting business models with its burn-and-mint equilibrium model combined with a unique token-distribution mechanism. However, when it launched new networks in mobile and IoT, it had to rearchitect its HNT token to test a new crypto-economic model that aligned HNT with its new networks. The revamped tokenomics also incorporated a transition from its own blockchain to Solana and the advent of a new subDAO architecture. 

Helium chose to keep its HNT token as the core value-accrual token instead of launching new tokens untethered to HNT. While this decision aligned the project with early stakeholders who still owned HNT, it made it more challenging to redesign the system. Creating a new system and new token from scratch would undoubtedly have been easier, but it would also have incurred significant social token debt from the existing HNT community, which has spent time, labor, and capital building the Helium network.

Ultimately, if Helium successfully overcomes its token debt, HNT will become a valuable case study for entrepreneurs and teams seeking to overcome their own token debt.

Ethereum: Simplifying token value accrual 

Ethereum has obviously evolved significantly from its initial launch, overcoming various challenges along the way, from the early hard fork to its more recent merge to proof of stake. All of these upgrades required devs to scale amid existing technical constraints (technical debt) while maintaining social consensus (social debt) among a diverse set of stakeholders. 

But a pivotal part of Ethereum’s tokenomics was its value-accrual narrative. Many forget that pre-EIP 1559, the value-accrual relationship between ETH (the asset) and Ethereum (the protocol) was inefficient. Direct usage of Ethereum resulted in higher fees, which went to Ethereum miners for marginal increased benefits (financial token debt); ETH was predominantly seen as a store-of-value asset (e.g., collateral in DeFi). However, EIP 1559 introduced dynamic pricing for Ethereum base gas fees to increase gas-price stability and, more critically, rolled out the mechanism to burn excess fees instead of effectively giving them to miners. This benefits other Ethereum stakeholders by reducing the supply of ETH. 

Redesigning a token in midflight is challenging and contentious, but it can be incredibly rewarding if done properly. Ethereum now has a succinct value-capture narrative (more Ethereum usage → more fees burned → more ETH value accrual). In token design – and redesign – simplicity in value accrual often wins. 

Friends With Benefits: Product pivot combined with new token design

Product pivots can kill or reinvigorate startups to profound success, as was the case with Slack. In that same vein, introducing new products and protocols can be a perfect catalyst for re-architecting tokens with a renewed focus. 

Friends With Benefits (FWB) started as an exclusive token-gated social community that required owning a certain number of tokens to access the FWB Discord community. But, FWB token volatility limited the scale of the FWB community because as the token price went up, fewer users could join. 

Over time, FWB evolved into a suite of products and a social network for the FWB community and shifted its token model. As part of its product evolution, FWB introduced a multi-token approach that uses a non-transferrable NFT for FWB membership. The FWB fungible token, meanwhile, unlocks enhanced experiences (e.g., events, content, etc.) Now, joining FWB effectively requires a payment of $750 for the membership NFT, with half exchanged to FWB tokens and reserved for the new member after a three-month staking period. 

This new network and dual-token design enables more people to join the network (i.e., the membership NFT is a fixed cost), aligns existing FWB holders with continued value accrual for members accessing premium services and experiences, and creates a more scalable token-based community overall. 

Final thoughts on token debt

Teams can overcome future token debt by thinking about tokens as products, ensuring that a token’s value is directly related to the needs of the protocol and its users.

Although building tokens core to the product is typically better for value capture, teams that are unsure about their token’s immediate protocol utility should either wait to issue a token until they have clarity on the token’s relationship to their product or opt for flexibility in token design versus pigeonholing themselves into poor token design and future token debt. 

Tokens are in their infancy. Therefore, some of the brightest and most forward-looking teams will be saddled with token debt in the coming years, and unfortunately many teams will never be able to pay off their token debt. However, teams that proactively attempt to overcome token debt will be poised for greater success than those who put potential token redesigns on the back burner until the next bull market.

+++

Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by Variant. While taken from sources believed to be reliable, Variant has not independently verified such information. Variant makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This post reflects the current opinions of the authors and is not made on behalf of Variant or its Clients and does not necessarily reflect the opinions of Variant, its General Partners, its affiliates, advisors or individuals associated with Variant. The opinions reflected herein are subject to change without being updated.