What is the token actually for?

A few years ago the interesting question was whether an asset could be put onchain. As a technical matter, that question is largely settled. In most cases, it can. I have been approached about tokenising everything from artwork and real estate to carbon credits and public stocks, and the wrapping itself is rarely the obstacle. The harder question, the one that actually decides whether a product works, is what the token is meant to do, meaning who it is for, what it gives the holder, and whether the structure behind it supports the way the product is meant to be used. Minting the token is the easy part. Everything that makes it worth holding is decided before it exists.

In practice the question breaks into four decisions: what the token represents, what the holder is actually entitled to, how the token is meant to be used, and what legal and regulatory characterisation follows from those choices. If those four answers are not clear, the product is not ready to be tokenised, whatever the technology allows.

Tokenising is not a strategy

Too often the token comes first and the reason comes later. I have seen projects wanting to tokenise an asset with no clear commercial objective, no defined audience, and no real answer to why anyone would want to hold the token, as if structuring something as a non-security were enough to guarantee demand, which it is not. Tokenisation can unlock genuinely new models, but only where there is a clear role for the token and the product market fit to support it. Without that, it puts capital into a wrapper nobody needs, wastes money, and chips away at the credibility of the whole category. So the first question is what the token is for.

Two tokens can look identical and be completely different products

Two tokens can look the same on a screen and be entirely different things underneath. One might be a direct ownership interest. Another a claim on assets held by a custodian. Another a note that pays an economic return. Another an interest in a fund, or an interest in a fund that holds an interest in another fund. Another a contract that simply tracks a price, with no ownership at all. These are not interchangeable. The structure decides who is allowed to hold the product, where it settles, whether it can be financed or used as collateral, and whether it can connect to onchain markets, to traditional institutional infrastructure, or to both. The economic outcome can look similar across all of them, which is exactly why the differences get overlooked until they matter. I have seen teams spend months on structure without asking what the chosen structure closes off.

A good asset in the wrong wrapper may still have no market

Even when the underlying asset is sound, the wrong wrapper can leave it with little or no use onchain. Issuance does not automatically translate into usage. A token can be created, listed and held, while still doing very little in the markets it was supposed to reach. What gets tokenised is not necessarily what gets used, because onchain usability depends on far more than the quality of the asset. It depends on transferability, eligible holders, redemption mechanics, liquidity, collateral value, and whether the token can sit inside a vault, a lending market or a structured strategy.

Composability rewards assets that fit the market structure around them. The right wrapper can make an otherwise ordinary asset actually useful onchain, while the wrong one can strand even a top-tier asset. The wrapper is where the design work lives, not a detail to tidy up after launch, and it determines whether the token has a market at all.

The structure shapes the regulatory characterisation

Legal and regulatory characterisation works the same way. Labels matter much less than the rights, obligations, controls and economic arrangements built into the product. The same economic exposure can be characterised very differently depending on whether the token represents ownership, a contractual claim, a fund interest, a note, a governance right or access to a managed strategy.

Onchain vaults are a good example. It is sometimes argued that a vault is automated through smart contracts and therefore just code, with no management and no regulatory trigger. But that argument is hard to sustain. Someone decided how the assets are deployed, someone changes the parameters or rebalances, and in most cases someone holds the upgrade keys. That fact pattern is closer to a managed product with an automation layer than to an unmanaged protocol, and depending on the jurisdiction and the rights attached to the deposit token, may raise collective investment scheme or managed-product questions. The characterisation, and everything that follows from it, is a consequence of how the product was built, and it cannot be bolted on afterwards.

The same problem from both sides

This matters whichever side of the market you are on. For a traditional institution, the danger is treating tokenisation as a distribution or technology project when it is really an operating model decision, one that changes how governance, custody, settlement and distribution work. For a crypto native team, the danger is assuming that a token, wrapper or vault structure that works in crypto markets will hold up under institutional, banking and regulatory scrutiny. They approach it from opposite ends, but the structural problem underneath is the same.

The real work happens before the token exists

Those decisions are the real work, and they happen before the token exists. Before launch, the team behind a token should be able to explain in plain terms what it represents, what the holder can actually do with it, and how it behaves if the structure comes under stress. Where those answers are clear, the token has a market and a defensible position. Where those answers are not clear, no amount of onchain packaging will make up for it. Tokenising an asset was never the hard part. The harder, more valuable work is designing something worth holding, using and defending, and that is what decides whether a tokenised product succeeds.