What allocators should ask before investing in a tokenized fund

Eight questions separate a tokenized fund that has been structured properly from one that has been described well. They are the questions institutional allocators already ask under NDA. Below they are answered in general — and then answered for our own structures, in public.

What does the token represent, in legal substance?

Ask for the answer in one sentence, and check it against the offering documents. A token in a fund structure should represent a unit or share in that fund, carrying the rights set out in the documentation and no others. If the answer describes the token as representing "exposure to" something, or as a "digital twin" of an interest, press until you have the legal characterisation: unit in a collective investment undertaking, transferable security, or debt instrument.

The follow-up matters more than the answer. Where the domicile recognises a distributed ledger as the register of the security, holding the token is holding legal title. Where it does not, the token evidences an interest recorded in an authoritative off-chain register, and the documentation must state which record governs if the two diverge. Both are workable; only one of them is usually disclosed without being asked.

Red flags: an instrument described as a utility or access token while carrying economic rights; documentation silent on which record governs title; a structure where the token and the register are maintained by different parties with no reconciliation obligation between them. Any of the three should stop the process until resolved.

Under what regulatory framework is the fund registered?

You want the named legal entity, its authorisation, its supervisor, and the fund’s own domicile and status. "MiCA-compliant" is not a framework and is usually a signal that the classification work has not been done — a tokenized fund unit is a financial instrument under MiFID II, and MiCA excludes financial instruments from its scope.

For a European structure the expected answer names an authorised manager under AIFMD or the UCITS regime, a depositary, and a MiFID II investment firm responsible for issuance and placement. For a non-EU structure it names the equivalent local authorisations and the basis on which the units may be offered to you.

Two checks are worth doing yourself. Verify each authorisation on the relevant public register rather than relying on the deck. And distinguish authorisations that are live from those that are pending: a pending authorisation is not effective until granted, and a structure relying on one is relying on something that does not yet exist.

How is the official register maintained, and how is it reconciled to the on-chain record?

There should be a named party accountable for the register and a written reconciliation process with a defined frequency. If the answer is that the blockchain maintains the register, the question has not been answered: a ledger holds a record, and a legal person is accountable for its accuracy.

Ask what the reconciliation covers and how often. A credible answer at each NAV date includes the holder list against processed subscriptions, redemptions and transfers; units in issue on-chain against the administrator’s books; whitelist membership against current verification and sanctions status; failed or reverted transfers with reasons; and a dated sign-off retained for audit.

Then ask what happens when a break is found: who investigates, who authorises a correction to the register, and how the correction is evidenced. Funds that have operated a tokenized register for any length of time answer this immediately, because they have done it. Funds that have not tend to describe the process in the conditional tense.

How are transfer restrictions enforced at the smart contract level?

Enforcement should happen before the transfer executes, not after. A permissioned token validates the receiving address against on-chain identity and eligibility rules — verified identity, jurisdiction, investor category, holding period, holder limits — and rejects any transfer that fails. ERC-3643 is the standard most commonly used for this in European structures.

Ask three things. Which standard, and has the implementation been independently audited. Who maintains the whitelist, and how quickly is it updated when an investor’s verification lapses or their jurisdiction changes. And how are changes to the eligibility matrix handled once the token is live, since each change is a re-configuration and potentially a controlled migration.

The failure mode to test for is a token that transfers freely with restrictions enforced by review after settlement. That is not enforcement; it is remediation, and it exposes the fund to holders it is not permitted to have. A fund that cannot demonstrate a failed transfer to an ineligible address on request has not proved the control works.

How is custody of the fund’s underlying assets discharged?

Separate two things: custody of the fund’s assets and custody of the fund’s units. Fund assets are the depositary’s duty under AIFMD or the UCITS regime, and that obligation is unchanged by tokenization. Units are held by investors, in self-custody or with a custodian, and their safekeeping is a different question with different providers.

Where the fund holds digital assets, ask which authorised entity performs that custody and under which permission — crypto-asset custody in the EU is a MiCA service and is distinct from the safekeeping of financial instruments under MiFID II. A firm registered only as a Virtual Asset Service Provider under national anti-money-laundering law holds an AML supervision status, not a custody authorisation.

Also ask about keys and recovery. What happens if an investor loses access; who can update the register and under what documented procedure; and whether the depositary has reviewed and accepted that procedure. This is routine in mature structures and absent in immature ones.

How is NAV calculated, and who calculates it?

An independent administrator should calculate NAV on a published schedule, under the valuation policy in the fund documentation, with depositary or equivalent oversight where the structure requires it. Tokenization changes none of this, and a claim of continuous or real-time NAV for a private portfolio should be treated as a warning rather than a feature.

Ask for the valuation policy itself, not a summary: how illiquid positions are marked, how often, by whom, and what independent input is used. For venture and private credit strategies the honest answer involves periodic marks and judgement, which is acceptable and disclosable. What is not acceptable is a valuation process that cannot be described.

One tokenization-specific check: confirm that the units in issue used in the NAV calculation are taken from the on-chain register at the strike, and that the administrator has a documented method for reading it. Mismatches between units in issue and the ledger are the most common reconciliation break in tokenized funds, and the process should be designed to catch them at the strike rather than after distribution.

How does the cash leg work, and what stablecoins or fiat channels are used?

Get the specifics: which banks, which payment institutions, and if a stablecoin or e-money token is used, which issuer and under which authorisation. This is where settlement claims are tested. If payment is a bank transfer, the fund waits for confirmation before issuing units and settlement takes hours or days. If the cash leg is an e-money token or tokenized deposit on the same ledger, settlement can be atomic.

Where a stablecoin is used, you are taking exposure to its issuer and its reserves, and that exposure should be disclosed and sized. Under MiCA, an e-money token issuer must be an authorised credit or electronic money institution holding full backing in low-risk liquid reserves with redemption at par on demand; a token that does not meet that standard is a different risk proposition and should be named as such.

Then ask what happens on a failed payment, on a redemption when the cash channel is unavailable, and on a currency mismatch between the payment channel and the fund’s base currency. Any fund making instant-settlement claims should be able to identify which ledger holds the cash. Most cannot.

What does the offering memorandum disclose about the tokenized framework specifically?

The memorandum should address tokenization directly rather than treating it as an operational footnote. Expect: what the token represents, which record governs legal title and under which law, transfer restrictions and how they are enforced, key loss and recovery procedure, the technology providers relied on and the consequences of their failure, the cash-leg mechanics, and the risks arising from tokenization in addition to the fund’s own risks.

Two omissions are common and both are material. Provider concentration: if one technology provider maintains the register software, the memorandum should say whether the register can be reconstructed and operated independently. And pending authorisations: where a structure relies on a licence in process, that must be identified as pending and not effective until granted, in the document rather than in conversation.

Read the risk factors specifically for whether they were written for this structure or lifted from a template. Tokenization-specific risks — legal recognition of the register, smart contract defect, key loss, cash-leg counterparty, provider concentration — should appear with facts attached. Generic blockchain risk language is a sign that the structuring work stopped at the wrapper.