How to Evaluate a Crypto Protocol

A protocol should be evaluated as a system, not a ticker. The useful question is not whether the story sounds plausible, but which technical, economic, and organisational assumptions must remain true for users to receive the promised service.

Define the product before the asset

Describe the user, the problem, and the action completed by the protocol without mentioning price. If that is difficult, the project may be organised around financing rather than a clear service. Compare the result with conventional databases, payment systems, exchanges, or contracts to understand why a blockchain is being used.

Draw the dependency map

List every component required for normal operation: base network, smart contracts, front end, domain, data feeds, bridges, sequencers, custodians, stablecoins, governance, administrators, and liquidity providers. Marketing may call the application decentralised even when one interface, oracle, multisignature wallet, or company remains essential.

For each dependency, ask who can change it, pause it, upgrade it, censor it, or allow it to fail. Read deployed permissions and current documentation, not only the roadmap.

Test the economic loop

Identify where value enters and leaves. Fees paid by real users are different from rewards financed by token issuance. Deposits are not revenue. Total value locked can rise because asset prices rise, because incentives attract temporary capital, or because users genuinely prefer the service.

Measure the system in units relevant to its job: settlements completed, borrowers retained without subsidies, fees paid, uptime, liquidity under stress, or costs saved. A token chart is evidence about market demand, not proof that the product works.

Read security as an operating process

Audits reduce uncertainty but do not certify permanent safety. Check upgrade authority, bug-bounty scope, incident history, dependency changes, admin-key controls, and the response plan. A protocol that cannot explain what happens during a failed oracle, bridge halt, liquidity shock, or governance attack has not completed its risk design.

Evaluate governance in practice

Formal voting is only one layer. Founders, foundations, delegates, exchanges, core developers, infrastructure providers, and large holders may each possess different kinds of power. Review proposal history: who writes proposals, who votes, which decisions occur off-chain, and whether minority participants can exit or fork.

The final memo

1. Write the strongest case for the protocol in plain language.
2. Write the strongest case against it without caricature.
3. List the five dependencies most likely to cause permanent loss.
4. Separate evidence available today from milestones promised later.
5. State what would change your conclusion and when you will review it.