Before diving into evaluating protocols, make sure you have taken the time to understand the fundamentals of why blockchain technology exists, how it works at a basic level, and what problems it is intended to solve. Having this context will help ensure you are evaluating protocols on the right metrics, rather than simply choosing based on hype, rapid growth, or other vanity metrics.

The Introduction to Blockchain and Crypto course that we designed with Codecademy is a great starting point.

When looking at the community, remember that you’ll be leaning on them frequently throughout the life of your career. Jump into Discord, forums, GitHub, etc. and get a feel for the activity level and the level of helpfulness you can expect to get. This is especially telling during a bear market, when the money chasers leave and the only people left are the true believers. Is the community relatively stable through these periods?

More questions to consider:

1. Is the community welcoming and encouraging to newcomers?
2. Are there developers outside of the founding team and employees of foundations/core companies that are active and willing to help?
3. What does the support system for developers look like from the founding team/foundation in the form of grants or building opportunities?

There’s an interesting paradox you have to navigate when you’re a developer in the crypto world. The technology itself, starting with Bitcoin, was purpose-built to be as immutable and indestructible as possible. Longevity was built into the design. But at the same time, the crypto landscape has its share of money chasers, pump and dump schemes, and other bad actors that are looking to take advantage of the hype. The ethos of the technology does not always match the ethos of the protocols and companies using it. This is where developers need to find the right balance between working on exciting new tech and making sure that you are building something that actually provides value, to either your customers or yourself.

Part of the fun of being a developer is tinkering on new, exciting ideas, so build on whatever you want if it’s just for fun/learning, just make sure not to hitch your career/business horse to something without substance.

When you are choosing a protocol, look at longevity both from a past and future perspective. How long has the protocol been around? While the brand new, shiny protocols often have the most hype around them, they are often a flash in the pan and can quickly dissipate due to either outright fraud or just the realization that they don’t actually do anything all that novel.

Which brings us to the second piece of looking at longevity - and some important questions to ask yourself:

1. What is the project’s long term vision?
2. How is the project progressing? (see also: progression section)
3. Are they deliberately tackling real, specific problems?
4. How well-funded are they?
5. Do you think the ecosystem is healthy and will be around a long-time or are you building on top of something that is going to be a ghost town in a few months?
6. Are they just another chain that popped up that has no real differentiator?

You can assess a protocol by analyzing the legitimacy of the challenges it is solving and evaluating the expected quality of the follow-through.

Remember that the entire purpose of building on Web3 is to create decentralized technology. There isn’t much point in doing it otherwise. Despite that, an alarming number of protocols are not actually decentralized when you look at how they operate. One of the core values of Web3 is real ownership, so building on technology that is decentralized is a MUST. The reality is, most base layers and platforms aren’t actually that decentralized and building on them can put you and your customers right back to square one problems like deplatforming that we came here to avoid. Decentralization is a spectrum, so the level of technological compromise you’re comfortable should align with your values and the needs of your application and your users.

Let’s take Bitcoin as an example. The requirements to run Bitcoin are very low, which means more computers are able to run full nodes. Contrast that with something like Solana, that has much higher requirements for running a node, drastically decreasing decentralization so that they can achieve a much higher throughput.

As a developer, you need to decide what is most important to you and your project/goals and choose the chain that prioritizes those.

Hot take: Developers shouldn’t be looking at the token action at all.

The soundness and the properties of the underlying technology are much more important than the speculation surrounding the token. For more established projects that have proven themselves in the market for longer, then I’d advise they look at the relative concentration of tokens to key parties on the network, especially if they are in a chain where these amount to voting power, validation, mining, or other forms of governing the network.

You might find that the chosen platform is actually controlled by a select few and you’ll have to get lucky for their agenda to stay aligned with yours long-term. It’s exciting to be building on a network who’s token is mooning, but it can also come crashing down if the fundamentals aren’t there and it’s a ghost town in a year.

Also look at the overall token economics:

1. Is it a ponzi?
2. Is the token a security?
3. Is it necessary?
4. Is it widely available so your users can access it when needed?
5. What wallet support is there?
6. Was the chain or official wallets audited?

Remember, your choices affect your users, you have a duty to pick smartly and do your due diligence to protect them.

Take some time to learn more about the team behind the protocol. What made them want to take on the project initially? Chances are, if they're still involved somehow (even for projects that have been around for a while), they believe in it for the long-term.

1. What is their background and experience?
2. Do they have academic credentials?
3. Have they worked on other projects before?
4. Are they still working on the protocol or have they left?

This is a big one for developers. The resources and tooling that are available will determine how easily you can actually start building things.

1. What tutorials or courses are available?
2. What starter kits and frameworks are available?
3. If you wanted to build a full-stack application, do you have a clear path for how you would go about doing that?

Something to note here is that a lack of these things may not be a reason to bail on an ecosystem, depending on your goals. If a project is new and lacking sufficient content and tooling, that can be a golden opportunity for you to step in and create it, planting yourself firmly in the early adopter role and gaining a strong reputation in your ecosystem of choice.

You should look for steady growth and progress, but it should be intentional and organic. Do you see an explosive level of growth but can’t really pinpoint why it’s happening? That can be a red flag. On the flip side, if nothing is happening and the project is stale, that’s another red flag.

Hype can open the door, but you still have to go get your own users. And to do that, you have to provide value. Always pick the tech stack that is going to help you provide the most value and that allows you to create a product with a defensible differentiator. Hype will come and go, and it's often more lucrative to join under-the-radar projects when there is little to no hype than to pile into an already popular project anyway. Hype is tricky, because it can be a great sign, but also a huge red flag. Dig deeper to see if the hype is based on substance or if it’s based on clever marketing and paid influencers and pop-up bot heavy communities.

Because so much of crypto is being built by relatively new organizations, you may want to offset some of that unknown to do with the core team by looking at who is backing them. If smart money is supporting a project, you might have an indication that the team is capable and that project is around to stay. It’s certainly not perfect as all investors ‘make mistakes,’ but there are VCs with great track records and investors that provide rationale (A16z) on their new investments to help you better understand why they backed a project. If you’re aligned, you now have some validation for the core team behind the project AND know that the team has some level of financial capacity to do work since they were able to fundraise.