How to Evaluate a Tokenized Product

A smart contract audit evaluates onchain code. A traditional credit analysis evaluates the underlying asset. Neither covers the full product.

This piece is written for issuers, allocators, and operators who need a practical way to understand what a tokenized product actually depends on.

A tokenized financial product is a system that spans both sides. The token is a claim on something. That claim has a legal structure, an economic model, operational dependencies, a distribution path, and a liquidity profile. Some of those elements live onchain. Many do not. The product is what happens at the interface between them.

Tokenized products cannot be evaluated only as code, only as legal instruments, or only as underlying assets. They need to be evaluated as systems.

For example, a tokenized credit product may have a valid legal structure, audited smart contracts, and attractive yield. But if the NAV updates monthly while the token is used as collateral in a DeFi protocol that liquidates in real time, the risk is not only credit risk or smart contract risk. It is the interaction between valuation, liquidity, and protocol design.

The framework below evaluates tokenized products across five categories. They are designed to be applied together, because the risk in tokenized products is rarely confined to a single category.

Structure

Legal wrapper, claim path, token rights, issuer entity, fund/entity structure, what the holder actually owns.

Structure is the starting point because it determines what you are actually underwriting. A tokenized product is a claim, and the first question is what kind of claim it is.

A tokenized fund share, a tokenized note, a tokenized LP interest, and a tokenized certificate are different legal instruments. They carry different rights, different recourse paths, and different regulatory treatment. The token itself does not tell you which one you hold.

Structure also determines the issuer entity and its jurisdiction, the legal chain between the token and the underlying asset, and whether the holder has a direct claim or an indirect one through an SPV, trust, or nominee. Two products with similar yield and similar underlying assets can have completely different structural risk depending on how the claim is constructed.

The question Structure answers: if something goes wrong, what does the holder actually own, and what is the path to recovery?

Economics

Yield source, fee stack, value flow, distributions, leakage, incentive alignment, whether economics reach the holder.

Economics traces how value enters the product, moves through it, and reaches (or fails to reach) the holder. The yield a product quotes is the end of a chain that starts with an underlying strategy and passes through management fees, performance fees, platform fees, gas costs, bridge fees, and protocol incentives.

The gap between gross yield and net yield is often larger than it appears. A product quoting 8% built on a 6% underlying strategy is subsidizing the difference with token incentives, leverage, or temporary fee waivers. Each of those has a shelf life.

Economics also covers incentive alignment. Does the issuer earn fees regardless of performance? Are there gates or high-water marks? Does the fee structure create incentives that diverge from the holder’s interest? A product where the issuer profits from AUM growth regardless of returns creates different dynamics than one where fees are performance-linked.

The question Economics answers: does the value the product generates actually reach the holder, and is the yield sustainable without subsidy?

Operations

Issuance platform, custody, admin, transfer controls, oracle/valuation, reporting, what the product depends on offchain.

Operations maps the infrastructure the product depends on to function. This includes the issuance platform, the custody arrangement, the fund administrator, the transfer agent, the oracle or valuation feed, and the reporting and disclosure practices.

Many of these dependencies are offchain. They involve counterparties, service agreements, and manual processes that do not appear in the smart contract. When one of them fails, the onchain product continues to trade at a price that may no longer reflect reality.

Oracle design is a good example. A product with weekly NAV updates from a third-party valuation agent will trade on stale prices between updates. If the product is used as DeFi collateral, that staleness becomes a liquidation risk: the lending protocol acts on a price that may be days old. The oracle is an operational dependency that creates structural risk.

The question Operations answers: what does the product depend on to function, and what fails first when those dependencies break?

Distribution

Eligibility, compliance gates, protocol integrations, composability, advisor access, listing venues, who can actually hold or use the product.

Distribution determines who can actually access the product and through what channels. A token that exists on a public blockchain is not necessarily accessible to the capital it needs to attract.

Eligibility requirements (accredited investor, qualified purchaser, non-US), jurisdictional restrictions, KYC/AML requirements, custodian support, and platform availability all constrain who can hold the product. A product available only through the issuer’s own platform to US accredited investors has a different distribution profile than one available across multiple custodians and jurisdictions.

Composability adds another layer. When a tokenized product is integrated into DeFi protocols as collateral, the distribution surface expands beyond the issuer’s control. The product may be accessible to participants the issuer did not anticipate, creating compliance exposure that neither party has fully addressed.

The question Distribution answers: can the product actually reach the capital it needs, and does the access model create risks the issuer has not accounted for?

Liquidity

Redemption, secondary market reality, NAV timing, settlement, gates, discounts, exit under stress.

Liquidity is last because it is the stress test. A product can have sound structure, sustainable economics, reliable operations, and broad distribution, and still fail if holders cannot exit when they need to.

Token transferability is not the same as liquidity. A token can be freely transferable on a blockchain with no secondary market, no market maker, and no bid. The question is not whether the token can move, but whether there is a buyer at a reasonable price when the holder needs to sell.

Redemption mechanics matter as much as secondary markets. What is the redemption window? What are the notice requirements? Are there gates or queue limits? What happens when redemption requests exceed available liquidity? How long does settlement take? What is the gap between the NAV at which you request redemption and the NAV at which you actually receive proceeds?

For products used as DeFi collateral, liquidity interacts directly with operations and structure. A liquidation event on a lending protocol requires the collateral to be sold quickly. If the underlying product has a quarterly redemption window and a 45-day settlement period, the liquidator cannot use the primary market. The only exit is a secondary market that may not have the depth to absorb the position without a significant discount.

The question Liquidity answers: what does exit actually look like, and does it work when conditions tighten?

Where the risk actually sits

The five categories are not independent. The risk in tokenized products tends to concentrate at the intersections between them.

An oracle lag (Operations) creates a pricing gap that becomes a liquidation risk (Liquidity) when the product is used as DeFi collateral. A redemption gate (Liquidity) interacts with a concentrated holder base (Distribution) to create correlated selling pressure. A fee structure (Economics) that incentivizes AUM growth regardless of performance creates structural misalignment (Structure) between the issuer and the holder.

These interactions are where many evaluations fall short. A category-by-category review that does not examine the connections between categories will miss the scenarios that actually cause losses. A product can score well on each dimension individually and still carry concentrated risk at the seams.

A strong evaluation should therefore ask two questions: how does each category work on its own, and what happens when the categories interact? The goal is not to grade each dimension in isolation but to understand how the product behaves as an integrated whole, especially under conditions the issuer did not design for.