Diligence checklist for tokenized assets

If you are evaluating whether to participate in a tokenized project (any tokenized project, in any category) you need a checklist. Not because checklists are magic, but because tokenized assets present a specific cluster of failure modes that are easy to miss without one.

This is not a one-pager. It is also not the eighty-page institutional checklist that gets paid attention only by lawyers. It is the working version: the questions that, in our experience, actually separate the serious projects from the rest. You can use it in an hour. You should use it before you put any meaningful money into anything tokenized.

The checklist is structured in five sections, in order of "what you should check first." If a project fails at any stage, the later stages do not matter. Stop and walk away.

Section 1: Is the asset real?

The first stage is the strict-RWA test from the previous lesson, applied to whatever category the project claims to be in.

1. Does the underlying asset actually exist outside the chain right now? For real-world assets, this is a literal question: is there a physical thing, or a contractual claim, or a stream of cash flows, that exists today and would still exist if the project never tokenized it. For tokenized stakes in a company, is there a working business with revenues and operations, or only a plan to build one. "We will use the proceeds to acquire" is not the same as "the asset exists today."
2. Is there public, verifiable evidence the asset exists? Title documents. Photos, third-party reporting, regulatory filings, audit statements, on-the-ground confirmation by parties not affiliated with the issuer. The standard of evidence depends on the asset class, but the question is the same.
3. Is the asset's economic function clear? What does it do that produces value. Rental income, usage fees, sale value, dividend distributions, royalty streams. If you cannot explain in two sentences how the asset produces economic value, you are in trouble before you start.
4. Is the asset's category legally established? Tokenizing a category that has clear legal precedent (real estate, debt instruments, equity in companies, royalty streams) is much safer than tokenizing a category whose legal status is being figured out in real time.

If any of these fail, the rest of the checklist is academic. Stop here.

Section 2: Is the connection to the chain solid?

If the asset exists, the next question is whether the on-chain token actually represents it.

1. What does holding the token legally entitle you to? Read the documentation that defines the holder's rights. Not the marketing page, the actual legal document. Are you a fractional owner of the asset, a lender to the project, a partner in a structured vehicle, a member of a community with rights to the asset's outputs? The answer determines everything else.
2. Who holds the asset on behalf of token holders? Identify the custodian, trustee, or operator. They have a name. They have a legal jurisdiction. They have a track record (or they do not, which is itself information). If the custodian is not identified, the chain-to-asset bridge has no responsible party.
3. What is the legal structure linking holders to the asset? A trust, a partnership, a fund, a special-purpose vehicle. Each structure has its own implications for what holders can demand and what protections they have. A clean structure is documented; a vague structure is a warning sign.
4. What attestations exist of the connection, and how often? Periodic audits, signed statements, third-party confirmations. Without ongoing verification, holders are trusting the issuer's word that the chain still corresponds to the world. Trust is fine in some contexts; in others, periodic verification is essential.
5. What happens if the chain-to-asset connection breaks? If the custodian fails, if the issuer disappears, if the legal structure dissolves: what is the procedure. Documents that answer this question protect holders; absence of those documents leaves holders with no recourse.

This section is where most "loosely RWA" projects fail. The asset may exist; the connection to the token may be more aspirational than enforceable. Read the documents, not the marketing.

Section 3: Is the token structure intentional?

Apply the issuance-pricing-distribution lens.

1. What is the issuance pattern? Fixed supply, capped emission, governance-controlled, uncapped. Does the supply pattern match what the token is supposed to represent? A tokenized share of a fixed asset should have fixed supply; a token that grows with usage should have a defined emission pattern; "we will issue more later if it makes sense" is not a defensible supply policy.
2. What is the pricing structure? Single-price, tiered, auction-based, free distribution. Does the pricing reflect what the token is supposed to represent, or is it set arbitrarily?
3. Who got tokens before the public, on what terms? Insider allocations, team allocations, advisor allocations, pre-sale allocations. How much. At what price. With what vesting. A project where the team holds 50% with no vesting is structurally different from one where the team holds 10% with five-year vesting. Read the cap table; do not skip it.
4. Is there a secondary market, and what does it look like? Tradable on day one, locked for a period, deliberately non-tradable, redemption-only. Match the choice to what the token represents and what the project's stated goals are. Mismatches signal deeper problems.
5. Does the structure align with the stated purpose? This is the synthesis question. Look at the issuance, pricing, distribution, and secondary-market design as a single design. Does it produce the holder relationship the project says it wants? Inconsistency between stated values and actual structure is the strongest signal that the project has not fully thought through what it is doing.

A project whose token structure is internally coherent has done the work. A project whose structure is incoherent has not.

Section 4: Who is the team, and why are they doing this?

Tokenized projects depend on the people running them. Smart contracts can encode rules, but only people can execute the operational work that maintains the chain-to-asset bridge.

1. Are the principals identified? Names, professional backgrounds, contact information, public histories. Anonymous teams are not always disqualifying (some projects have legitimate reasons for pseudonymity), but they substantially raise the bar of trust required.
2. What is their track record? Prior projects, prior outcomes, public reputation, demonstrable expertise in the asset class. Pattern of completing projects matters more than pattern of starting them.
3. Why this asset, with this team? Does the team have specific expertise in the underlying asset class? A team tokenizing real estate should have real estate experience. A team tokenizing music royalties should understand music industry economics. A team tokenizing infrastructure should have infrastructure development experience or the right partners.
4. What is the alignment of incentives? How does the team get paid? How are they exposed to the project's success or failure? Are they compensated upfront in cash, or do they have skin in the long-horizon outcome?
5. What outside parties have signed on? Legal counsel, auditors, custodians, named partners. The list of identifiable third parties willing to be associated with the project is a useful signal of the project's professional standing.

A project with named, qualified, aligned principals and identifiable third-party partners is doing one kind of work. A project with anonymous teams, no clear third-party involvement, and no track record is doing something else.

Section 5: Practical operational checks

Quick tactical questions, applicable to almost every project.

1. Can you read the smart contract? On verified-source explorers, the contract code is publicly viewable. If you cannot read it yourself, can someone you trust read it? Has it been audited by a reputable firm? Audit reports are not perfect, but their absence is its own signal.
2. What chain is it on? The choice of chain affects security, transaction costs, regulatory posture, and ecosystem maturity. Major chains have established conventions. Minor or newer chains require additional diligence on the chain itself.
3. Where does the project communicate? Active project websites, real social presences, regular updates, responsive teams. Ghost projects with year-old updates are a warning. Projects with daily marketing posts and no operational substance are the opposite warning.
4. Is there a working product, or just a plan? For tokenized projects in operating businesses, the business should already be operating. For tokenized infrastructure, the infrastructure should be under construction or in operation. For tokenized creative work, the work should exist. "Coming soon" tokens for assets that do not yet exist are a different category of project, with substantially higher risk.
5. What is the regulatory posture? Has the project been structured for any specific regulatory framework? Does it operate in jurisdictions that have clear digital-asset rules? Is there documentation of compliance work that has been done?
6. What is your exit story? If you participate, how do you exit? Sale on a secondary market, redemption events, defined exit windows, beneficiary transfer at death only. Match the exit options to your own liquidity needs. A non-tradable token is not the right fit for someone who needs to liquidate in a year.

These questions take an hour, on a project, if you have the documents in front of you. The hour is the cheapest insurance you can buy.

What this checklist gives you

A pass on every section means a project that is, by the visible signs, doing the serious work. It does not guarantee the project will succeed. Markets change, teams stumble, assets fail to perform as expected. The diligence checklist tells you the project is legitimate; it does not tell you the project will be successful. These are different questions, and the second is harder.

A failure on any section means a project where you should have substantially more questions before participating. Some failures are recoverable with additional information; some are disqualifying.

The checklist is also a useful tool for builders. If you are issuing a token, or considering it, run your own project through this list. The places it fails are the places you have not yet done the work. Do the work before the launch, not afterwards. The diligence questions external participants will ask are the same questions you should be asking yourself first.

A short note on humility

Even with a perfect checklist, applied perfectly, you can still get tokenized investments wrong. Real assets behave in ways nobody anticipated. Markets shift. Teams handle failure differently from how they handle success. Documents that looked airtight turn out to have ambiguities that nobody saw at the time.

The checklist does not eliminate risk. It eliminates the risk of being surprised by things that were knowable in advance. The unknowable surprises are real, and they are part of any investment in any asset class. The point of diligence is to make sure that when something goes wrong, it is the kind of thing that nobody could have seen coming, not the kind of thing that anybody who read the documents could have seen.

That distinction, applied consistently across the projects you evaluate, will keep you out of most of the avoidable losses in this category. The unavoidable ones are everyone's risk; the avoidable ones are yours to avoid.