DeFi Tokens: Investment Evaluation Framework

When we had the explosion of tokens happened in 2017, we saw hype and mania for anything which sounded remotely promising. Prices and valuations for openly traded coins have been met with high skepticism, and sometimes irrationality (XRP being a top 5 coin). Whenever product milestones were met, charts would often be silent. Empty partnerships and listing announcements were what drove prices up.

Over the past few months, this has started to change. Tokens with real utility, cash flows and solid teams executing are seeing their prices increase. Presented below is an initial attempt of creating a framework to evaluate DeFi tokens/coins with subsequent posts around token/coins worth evaluating. Some examples include: $MKR (MakerDAO’s token), $SNX (Synthetix’s token), $KNC (Kyber Network’s token)


1. Executive Summary

This should cover what the protocol in question does and how it generates fees for network participants.

Within this section, there will be 3 major risks and 3 rewards for what the potential upside if things go to plan.


2. Valuation

Due to the wide discrepancy in total supply of crypto coins/tokens, market cap is a much easier standardised metric as it tracks:

Price Per Coin * Total Supply = Market Capitalisation

Once we have standardised valuations, I’ve come up with the following mental metrics in order to benchmark the market:


  1. $1M – $10M range = seed stage, live product functioning with live product on main-net. Examples in this range at this point in time would include: Opyn, Hegic, FutureSwap. This is probably where the most alpha exists but getting in these deals isn’t as straight forward and teams are hesitant to put out a token.

  2. $10M – $45M range = are visibly finding product market fit with clear numbers demonstrating traction. Getting access to these tokens is easy for most people, there is still risk at this stage about continued traction although other key risks are mitigated (team, execution).

  3. $45M – $200M range = are market leaders in their respective niche and have clear traction, community and technology to back this up. There’s not a crazy amount of risk here as projects are fairly established, however in order for their valuation to climb from here requires significant institutional money, market expanding significantly or many more newer buyers.

  4. $200M – $500M range = extremely dominant position. The only token that I can think of that fits this bill is $MKR due to it’s widespread usage and institutional investor base (a16z, Paradigm, Polychain). Purchasing tokens in this valuation relies on another bull run for any serious price action to happen realistically.


3. Code Rating

With majority of these decentralised protocols, the quality of the code is extremely paramount as too much risk can result in the protocol itself being hacked. Any major bank run typically leaves protocols empty-handed and impairs future growth in a very large way. Below are key metrics to asses the code quality of a protocol:

  1. Complexity of architecture. Smart contracts are delicate programs as they handle millions of dollars of money and the more complex the architecture, the more attack vectors are present. Teams which opt for simplicity in their technical design demonstrate experience writing software and auditors/developers can reason about the code base much easier.

  2. Quality of automated code tests. In software development, writing tests before writing code is a common practice that ensures that robust, high quality software is written. While writing smart contracts, this practice is extremely critical as it guards malicious or invalid calls from being made as the smallest pieces of the program are written. Code bases which don’t have high code coverage or very low should be taken with extreme caution. bZx was a team that blatantly ignored this practice and caused $2m worth of investor’s money to be lost.

  3. General development practices. This one isn’t necessarily a critical performance/security factor but tells more about the experience of the team writing code. Code formatting, git flow, management of published addresses, continuous integration/deployment pipelines are all minor factors but give a hint as to the writers behind the code.

  4. Assessment of audit results. What key findings did auditors find (assuming audits have been done), how did the team respond and have practices been put in place to ensure that repeated exploits can’t be found/are patched up in the development process. Bug bounties are a good signal for the team’s confidence and commitment to security.

  5. Protocol control, key risk and upgrade processes. The higher the protocol risk and quicker upgrade process, the more users need to hope that protocol owners don’t get kidnapped and held at ransom.


4. Token Metrics

Due to markets around tokens ranging from illiquid to liquid, knowing about how the current circulating supply looks like and what the potential total supply looks like. Networks which have been around for a while give assurances that the tokens are fairly distributed out and the chances of single actors causing damage by selling a large portion is minimised.

In addition, a high level overview of how the token works and what value it provides to the network is just as crucial since empty speculation is dangerous to bet on.

That being said, the following factors are important:

  • Current circulating supply

  • Total supply

  • Tokens held by the foundation/team

  • Vesting schedules/lockups still present

  • How it is used within the native ecosystem and what kind of cash-flow can users expect?

  • What supply sinks are built into the token


5. Future Growth

Given the current valuation of the token, what key factors should investors be tracking/looking at to assess if the token can continue to appreciate in price.

Key factors include:

  • Market size of the opportunity

  • Value capture mechanics of the token

  • Growth of the product and levers that could drive it


6. Team

This is a commonly overlooked section and often tells you more about the future execution capability of the team and how the product may turn out in the future.

What’s important to know in crypto is that does the team have the correct blend of crypto expertise while having experience building traditional technology products (websites, apps etc). Some teams may be heavier on one side than the other, however a skew on one side can slow down the path to finding product market fit.

In my experience, teams that have too much experience building technology businesses without understanding the dynamics of crypto will:

  • Pivot too quickly to another idea to due lack of conviction, derived from not knowing the market well enough

  • Not choosing careful trade-offs between security, user-experience and business models

On the flip side, teams that don’t have any experiencing building technology businesses and pure crypto end up:

  • Focusing too much on the ideals of what crypto should be, and not enough time figuring out what users want

  • Have trouble establishing product/market fit as marketing materials about the product are sparse, go-to market is weak and branding doesn’t invoke trust

That being said, everyone has to start from somewhere and these pre-requisites are hard to meet. However, as investors the risk of the team not having the correct expertise of both sides should factor into their investment thesis and be taken accordingly.


Wrapping Up

I’m super excited to get everyone’s feedback on this framework as I can start using it to certain upcoming tokens that are worth taking a look at and digging into.

If you disagree with any of these metrics or think something should be changed up, please don’t hesitate to reach out as I’d love to make this as objective and useful as possible.

Credit to Simply Wall St for inspiration on how to create a framework that’s easy to understand and comprehend.

—Source link—

What do you think?

TUSD and USDC-B Approved by Maker Governance as Collateral Types in the Maker Protocol

Invest in DeFi like a Financial Planner