Why I left Web3 consulting, and what I kept

I did not leave Web3 consulting because cryptography stopped being interesting. I left because too many new projects had stopped solving a problem.

The pattern became predictable.

Create a token. Presell it at an outrageous price. Invent a reason for it to exist. Let early buyers fund the project and give the founders a fast path to getting rich.

The product itself could often work perfectly well without a token.

That was the problem.

When the token becomes the product

A token is a technical component. Like any component, it should earn its place in the system.

Let’s be clear. 99.99% of projects do not need a token to work. The token is there to fund the project and make the founders rich before the product has proved anything. This is a toxic environment.

Ask a simple question: what stops working if you remove it?

If the answer is nothing, the token is not infrastructure. It is a financial layer attached to a product that does not need it.

Sometimes the product barely existed. There was a white paper, a presale, and a roadmap full of claims. The token had a price before the software had users. The founders could make money before proving that the project created any value.

Don’t fall for the hype. This is not decentralization. It is an incentive problem.

The system rewards the founders for selling the promise early. Users and token buyers carry the risk. Once the presale succeeds, shipping a useful product becomes one possible outcome instead of the condition for getting paid.

Good engineering cannot repair bad incentives.

Trustless until someone upgrades it

Smart contracts are supposed to reduce trust. Instead of trusting a person or company to apply the rules correctly, you put those rules in code that everyone can inspect.

Many projects wanted to sell that promise without accepting its consequences.

So they added a way to upgrade the contract later.

An upgrade mechanism can be useful when a contract contains a bug. It also means someone can replace the logic after users have committed their money. If a founder, administrator, or small committee controls that mechanism, users still need to trust those people not to change the rules.

The trusted intermediary was not removed. It was given an upgrade key.

A multisig, governance process, or timelock may distribute that power or make abuse harder. It does not make the trust assumption disappear. You still need to know who can change the contract, under which conditions, and how much time users have to react.

The tradeoff is real. Immutable code preserves both its guarantees and its mistakes. Upgradeable code can fix mistakes, but it recreates authority and adds another attack surface.

Both designs can be valid when the tradeoff is explicit. What is not valid is selling a system as trustless while keeping centralized control over its future behavior.

Too many projects wanted decentralization for the marketing and centralization for the control.

The consultant still has a choice

It is easy to hide behind the scope of the work.

The client asked for a smart contract. You built the smart contract. The code works. The audit passed. Job done.

I don’t accept that separation.

Technical competence does not remove responsibility for what the system is designed to do. Clean code can still make a bad incentive machine more effective.

Not every Web3 project was a scam. Not every token was useless. But more and more of the new work I saw followed the same pattern: a shitcoin, an unnecessary token, or a complicated way to transfer money from late buyers to the people who created it.

At some point, filtering out those projects became a larger part of the job than building anything worth shipping.

That was my stop condition.

I did not want to spend my time helping founders manufacture artificial scarcity, presell it, and call the result innovation. So I left Web3 consulting.

What I kept

Web3 forced me to take security seriously.

When software controls money, a bug is not an inconvenience. It is an opportunity with a price attached to it. Someone will eventually calculate whether exploiting it is profitable.

That changes how you build.

You cannot treat security as a checklist added before release. You need a threat model before you trust the architecture.

Start with the uncomfortable questions:

• What are we protecting?
• Who benefits if this breaks?
• Which actors can behave maliciously?
• What do we trust, and what happens when that trust is misplaced?
• Which actions are irreversible?
• How do we detect a failure?
• Can we recover without making the damage worse?

These questions sound obvious after an incident. Before an incident, teams routinely replace them with assumptions.

Web3 does not give you much room for that. Contracts are public. Transactions often cannot be reversed. Attackers can inspect the same code, automate an exploit, and move money before anyone understands what happened.

The numerous hacks were not random bad luck. They were reachable attack surfaces meeting strong financial incentives.

That lesson stayed with me.

Threat models are useful outside Web3

Most software is not a smart contract, but every serious system has assets, trust assumptions, and failure modes.

An authentication system protects identities. A billing system moves money. A knowledge system holds information people expect to retrieve later. An AI agent may receive credentials, call tools, change files, or deploy code.

The technologies differ. The questions remain:

• What can this component access?
• What authority does it have?
• Which input can it trust?
• What happens if it is wrong?
• Where is the final gate?

Security starts by defining those boundaries. Otherwise, you are trusting a diagram that only describes the successful path.

Edge cases matter because attackers live in them.

Security is a way of thinking

The most useful skill I kept from Web3 is not Solidity or token economics. It is the reflex to look for the assumption that makes the whole system fail.

Threat modeling makes that reflex explicit.

It forces you to identify the assets, actors, incentives, boundaries, and recovery options before an incident turns them into an expensive lesson. It also gives you a stop condition. If you cannot explain who you trust and what happens when they fail, the design is not ready.

This way of thinking now shapes how I build ordinary SaaS products and AI systems. The attack surface changes. The need to verify independently does not.

I left the tokens, the presales, and the get-rich-quick projects behind.

I kept the paranoia.

In security, that is often the useful part.