A note on what this is. This paper is editorial analysis, not legal advice. It works from the primary texts (Directive 2011/61/EU, ESMA's Guidelines on Key Concepts of the AIFMD (ESMA/2013/611), and the deployed contract code of the protocols discussed) rather than from any firm's client briefings, because the argument advanced here is my own and should be judged on its reasoning. Nothing in what follows has been blessed by a competent authority, and as we shall see, there is no court judgment anywhere in the EU that has tested the questions this paper raises.

---

Introduction: the perimeter runs through the function table

Ask most people in digital assets whether a DeFi vault is a fund and you will get an answer based on vibes. A vault with a named curator charging a performance fee "feels like" a fund. An immutable lending pool "feels like" infrastructure. A tokenised money market product from BlackRock is "obviously" a fund, and an automated liquidity manager rebalancing a Uniswap position is "obviously" not.

The thesis of this paper is that these intuitions are not merely unreliable but in several important cases exactly backwards, and that the only way to answer the question properly is to stop looking at branding and start reading the function table of the deployed contract. The Alternative Investment Fund Managers Directive does not ask whether something feels like a fund. It asks four specific questions, set out in Article 4(1)(a) and elaborated by ESMA in its 2013 Guidelines on Key Concepts: is there a collective investment undertaking; does it raise capital; from a number of investors; with a view to investing it in accordance with a defined investment policy for their benefit. Every one of those questions can be answered, with unusual precision, by examining which addresses are permitted to call which functions on a vault contract, and what those functions do to depositor capital when called.

That is a genuinely novel situation for fund regulation. In the traditional world, the regulatory analysis of a fund structure involves reconstructing who has power over what from a stack of documents: the limited partnership agreement, the investment management agreement, side letters, delegation arrangements. The allocation of discretion is a matter of contractual interpretation, and the gap between what the documents say and what actually happens is where most regulatory disputes live. In a smart contract vault, the allocation of discretion is not described. It is enforced. The onlyCurator modifier on a function is not a covenant that the curator will refrain from doing something; it is a machine-level guarantee that no other address can do it. The regulatory analysis can therefore proceed from the code with a confidence that has no analogue in traditional structures, and this paper attempts to do exactly that.

The argument proceeds in five parts. Part I sets out the mechanical anatomy shared by nearly all vaults, because the ERC-4626 standard turns out to do a surprising amount of regulatory work on its own. Part II delineates six vault archetypes, distinguished not by protocol branding but by where discretion sits and what it operates on, and traces the flow of funds through each at the level of individual function calls. Part III sets out the AIFMD test as it actually exists at EU level: the Directive text, ESMA's guidelines, and the striking absence of any judicial gloss. Part IV, the core of the paper, applies each limb of the test to each archetype, tying specific contract interactions to specific definitional elements. Part V turns to the question the industry has barely begun to confront: if a vault is an AIF, who exactly is its manager, and can the Directive's assumptions about what a manager is survive contact with a role-based permission system spread across multisigs?

Two conclusions emerge that are worth stating up front, because they cut against the prevailing assumptions. First, the vault archetype most commonly described in the industry as "not asset management" (the curated lending vault, where a named risk curator sets caps but never picks positions) has, on a close reading of ESMA's guidelines, one of the strongest claims to being an AIF of any structure in the market, stronger in one important respect than vaults run by fully discretionary managers. Second, the structure with the weakest claim to being an AIF is not the one with the least human involvement per se, but the one where no allocation function exists at all, and the distinction between those two things (automated discretion versus absent discretion) is the line on which the entire regulatory analysis ultimately turns.

Part I: What a vault mechanically is

Before archetypes, the shared substrate. The overwhelming majority of vaults in production today implement, or wrap something that implements, the ERC-4626 tokenised vault standard, finalised as an Ethereum improvement proposal in 2022. The standard defines a minimal interface for a contract that holds a single underlying ERC-20 asset and issues fungible shares against it. Four state-changing functions matter: deposit(assets, receiver) and mint(shares, receiver) on the way in, withdraw(assets, receiver, owner) and redeem(shares, receiver, owner) on the way out. Alongside them sit the accounting functions: totalAssets(), which reports the current value of everything the vault holds including accrued yield, and the conversion pair convertToShares(assets) and convertToAssets(shares), which define the exchange rate between the underlying asset and the share token.

It is worth dwelling on what this mechanism does in economic substance, because it will bear directly on the legal analysis. When a depositor calls deposit(), the vault pulls the underlying asset from the depositor's address via transferFrom and mints share tokens to the receiver at the prevailing rate. From that moment, the depositor no longer owns any identifiable assets. They own a pro-rata claim on totalAssets(), whatever that pool comes to contain and however its composition changes. If the vault's strategies earn yield, totalAssets() rises while the share supply does not, and every shareholder's claim appreciates identically. If a strategy suffers a loss, every shareholder absorbs it identically. There is no mechanism in the standard by which one depositor's capital can be traced to one position, or by which one depositor can be exposed to a different risk profile from another. Gains and losses are mutualised by construction, at the level of the share-price arithmetic itself.

The standard also fixes, precisely, what a depositor can and cannot do. The complete set of powers held by a vault shareholder, as a shareholder, is: deposit, redeem, and transfer the share token. Nothing in ERC-4626 gives shareholders any function for directing where the pooled assets go. Whatever allocation machinery exists sits behind separate, access-controlled functions callable only by designated role addresses, and it is the shape of that machinery, not the deposit interface, that differentiates the archetypes in Part II.

One extension deserves mention. ERC-4626 assumes atomic, synchronous entry and exit: you call redeem() and receive assets in the same transaction. ERC-7540 extends the standard for asynchronous flows, introducing requestDeposit() and requestRedeem(), so that vaults holding illiquid or off-chain assets (tokenised private credit, real-world asset structures) can queue subscriptions and redemptions for later settlement. The regulatory reader will recognise this immediately: it is subscription and redemption machinery with a notice period, which is to say it is the liquidity management architecture of an open-ended fund, reimplemented as an interface standard. The fact that the ecosystem found it necessary to standardise a notice-period redemption queue is itself weak but genuine evidence of what these structures functionally are.

Part II: Six archetypes, defined by where discretion lives

The taxonomy that follows is organised around a single variable: who can call the functions that move pooled capital, and what constraints bind them when they do. Total value locked, protocol age and brand recognition are all irrelevant to the legal analysis. The function table is not.

Archetype 1: The tokenised fund wrapper

BlackRock's BUIDL, issued through Securitize, is the paradigm. Here the blockchain performs no allocation whatsoever. The token contract is a transfer-restricted ERC-20: its transfer and transferFrom functions contain a hook that reverts unless both sender and recipient appear on a whitelist maintained by Securitize as SEC-registered transfer agent. Minting and burning are not open functions but administrative acts performed by the transfer agent against off-chain subscription and redemption instructions, and the investment decisions (what Treasuries to hold, at what duration) happen entirely off-chain inside a conventionally regulated fund managed by a conventional manager.

The flow of funds never really touches the chain at all: fiat or stablecoin moves through the transfer agent, units are minted as a bookkeeping consequence, and the on-chain artefact is a share register, not a fund. This archetype is included as the control case. Nobody disputes its classification (it is a fund because it is, quite literally, a registered fund), and its function table shows why: the only on-chain discretion that exists is the discretion to update a whitelist.

Archetype 2: Discretionary on-chain asset management

Enzyme is the cleanest example. A depositor calls buyShares() on the fund's comptroller contract, transferring the denomination asset in and receiving shares out. From there, a designated manager address exercises live, continuing investment discretion: through callOnExtension(), the manager routes the vault's pooled assets into whitelisted integration adapters that execute swaps on decentralised exchanges, open lending positions, provide liquidity, or take leveraged exposure. Each trade is a discrete discretionary decision by an identified manager, executed against pooled capital, with the results flowing back into the vault proxy that holds the assets.

The flow of funds is therefore: depositor to vault via buyShares(); vault to venue via manager-initiated adapter calls; venue back to vault as positions are unwound; vault to departing depositor via redeemSharesInKind() or its equivalents. Strip out the terminology and this is a separately pooled discretionary mandate: a portfolio manager making buy and sell decisions over commingled client capital, with the custodian replaced by a contract. The discretion operates at the level of individual positions, continuously, and is bounded only by whichever policies (investor whitelists, asset universes) the vault owner configured at setup.

Archetype 3: The curator vault

This archetype, of which Morpho's vault system is the defining implementation, is the analytical centre of this paper, because its permission architecture was designed precisely to avoid looking like archetype 2, and the legal question is whether the avoidance succeeds.

The structure separates four roles, each an address, each holding a disjoint set of callable functions. The owner deploys the vault and sets fees. The curator decides which lending markets the vault may touch and how much of the pool may be exposed to each: in the first-generation contracts by calling submitCap(marketParams, supplyCap) to propose a per-market ceiling, which becomes effective only after a mandatory timelock elapses and acceptCap() is called; in the second-generation contracts through increaseAbsoluteCap() and increaseRelativeCap() against abstract risk identifiers (a collateral asset, an oracle, a protocol), with increases timelocked and decreases immediate. The allocator moves capital within the space the curator has defined: setSupplyQueue() orders the markets into which fresh deposits flow, and reallocate() (or allocate() against adapters in the newer architecture) shifts existing pooled capital between enabled markets, subject always to the caps. A guardian or sentinel can veto pending curator actions during the timelock window and pull emergency brakes, but cannot itself direct capital.

Follow a unit of capital through this machine. A depositor calls deposit() on the vault, an ordinary ERC-4626 entry, and receives shares. The deposit is routed automatically down the supply queue the allocator has configured, landing as supply-side liquidity in one or more underlying lending markets. Interest accrues in those markets; totalAssets() rises; the share price appreciates for everyone pro rata. When the allocator judges that rates or risks have shifted, it calls reallocate(), and pooled capital moves from one market to another, within caps, without any depositor being consulted or even notified beyond the public mempool. When the curator wants to admit a new market or raise a cap, the proposal sits in public view for the timelock period (days, sometimes weeks), during which any depositor who dislikes the change can exit at the prevailing share price, and the guardian can revoke it.

The industry description of this arrangement is that the curator is not an asset manager because it never touches positions, holds no custody, and cannot act without notice. Every element of that description is true at the level of the function table. Whether it matters legally is the question Part IV answers, and the answer, I will argue, is no: in fact the very features cited as distinguishing the curator from a fund manager are the features that most cleanly satisfy the statutory test.

A further wrinkle in the newer contracts deserves flagging now, because it returns with force later: the curator can install compliance gates (setSharesGate(), setReceiveAssetsGate(), setSendAssetsGate()), contracts that condition who may hold shares or receive assets. A vault with gates configured is a vault with a programmable investor eligibility regime, which is to say, a subscription policy.

Archetype 4: The allocator-of-strategies vault

Yearn's v3 architecture generalises archetype 3 by one level of indirection. Here the objects being allocated between are not lending markets but strategies, and the strategies are themselves standalone ERC-4626 vaults (Yearn calls them tokenised strategies) with their own deposit() and report() functions. A management role calls add_strategy() to plug a strategy into the parent vault, update_max_debt_for_strategy() to cap how much of the pool it may absorb, and a debt allocator contract calls update_debt() to push pooled capital into, or pull it back from, each strategy according to target weights, informed by an on-chain APR oracle. Each strategy periodically calls report(), crystallising its gains or losses into the parent vault's accounting, at which point totalAssets() and therefore every depositor's share value adjusts.

The flow of funds is depositor to parent vault via deposit(); parent vault to strategy vault via update_debt(), which is mechanically a deposit() by the parent into the child; strategy vault to underlying venue via the strategy's own _deployFunds() logic; and back up the same chain on the way out. The parent vault is, in the most literal structural sense, a fund of funds: an ERC-4626 vault whose portfolio consists of positions in other ERC-4626 vaults, with a designated role deciding the weightings. This observation is not rhetorical. As Part IV shows, ESMA's guidelines treat fund-of-funds structures as a paradigm case in one of the four definitional limbs, which makes this archetype in some ways the easiest of all to classify.

Archetype 5: The rules-based liquidity vault

Concentrated liquidity managers (Arrakis, Gamma and their peers) pool depositor capital to run market-making positions on automated market makers, and the archetype is best understood through the three-way split that Arrakis itself formalised in its own product line, because that split maps directly onto the legal analysis.

In a managed vault, a designated manager address holds the right to call executiveRebalance(newLowerTick, newUpperTick, ...), repositioning the vault's entire pooled liquidity into a new price range on the underlying pool, and deciding what to swap to fit the new range. That is a single-parameter discretion, but it is live, continuing, and dispositive of the pool's entire risk profile: the choice of range is the choice of exposure. In a trustless vault, no such address exists; the rebalancing logic is fixed in the strategy code at deployment, executed by keeper networks against predefined triggers, and can be changed by nobody. In a self-managed vault, the manager and the sole depositor are the same entity.

The flow of funds is common to all three: depositor calls the vault's mint or deposit function, contributing both pool tokens; the vault holds a fungible wrapper over what is otherwise a non-fungible AMM position; trading fees accrue into the position and are periodically harvested and compounded back in; rebalances withdraw the liquidity, optionally swap, and redeposit in the new range. What differs is solely who, if anyone, can call the function that moves the range. The legal analysis will split precisely along that line, which is the paper's clearest illustration of the general method: three products, one flow of funds, three different answers, distinguished by nothing except access control on a single function.

Archetype 6: The immutable pool

Aave and Compound style base-layer lending pools are routinely lumped into the same conversation as everything above, and the central claim of this section is that their function tables show them to be a categorically different object.

A supplier calls supply(asset, amount) and receives a rebasing receipt token. A borrower posts collateral and calls borrow(). The interest rate paid by borrowers to suppliers is not decided by anyone: it is computed continuously by an interest rate strategy contract as a deterministic function of pool utilisation. Undercollateralised positions are closed by permissionless liquidationCall(), executable by anyone. And here is the decisive point: there is no allocation function. No address, anywhere in the system, holds the power to move pooled supplier capital from one use to another. Capital is not deployed by a manager; it is drawn down by borrowers, at their own initiative, against parameters that change only through slow, infrequent protocol governance votes in which suppliers as such have no special voice.

The distinction between this and archetype 5's trustless vaults is subtle but essential, and it is the distinction between automated discretion and absent discretion. A trustless Arrakis vault still does something with pooled capital: its code embodies a strategy, chosen by its deployer, that actively repositions the pool's assets in pursuit of return. An immutable lending pool does nothing with pooled capital except make it available to be borrowed. One is a strategy that has been frozen; the other is the absence of a strategy. Part IV argues this is exactly the line the AIFMD definition draws, even though the Directive's drafters had never heard of either.

Part III: The test as it actually exists

The Directive and the four limbs

Article 4(1)(a) of Directive 2011/61/EU defines an alternative investment fund as a collective investment undertaking, including investment compartments thereof, which raises capital from a number of investors, with a view to investing it in accordance with a defined investment policy for the benefit of those investors, and which does not require authorisation as a UCITS. Four limbs, all cumulative: fail any one and the vehicle is outside the Directive entirely; satisfy all four and it is inside, whatever it calls itself and whatever technology it runs on.

The Directive itself defines almost none of its own key terms. "Collective investment undertaking" is defined nowhere in EU legislation. The interpretive weight is carried by ESMA's Guidelines on Key Concepts of the AIFMD (ESMA/2013/611, August 2013), soft law with which national competent authorities must make every effort to comply, and which for over a decade was the only EU-level text unpacking the definition. It has since been joined, though not displaced, by ESMA's guidelines on the conditions and criteria for the qualification of crypto-assets as financial instruments (ESMA75-453128700-1323, 2025), issued under MiCA, which apply the 2013 concepts to crypto-assets directly and to which this paper returns below. Its key moves are worth setting out precisely, because the vault analysis lives in their exact wording.

On collective investment undertaking, the guidelines identify three cumulative characteristics: the undertaking has no general commercial or industrial purpose; it pools capital raised from investors for the purpose of investment with a view to generating a pooled return; and the unitholders or shareholders, as a collective group, have no day-to-day discretion or control. Two defined terms sit underneath. "Pooled return" means the return generated by the pooled risk arising from acquiring, holding or selling investment assets, including activities to optimise or increase their value, irrespective of whether investors receive differentiated payouts. "Day-to-day discretion or control" means a direct and ongoing power of decision over operational matters relating to the daily management of the undertaking's assets, extending substantially further than ordinary shareholder voting on matters such as mergers, liquidation, director appointments or account approval.

On raising capital, the guidelines describe a commercial activity of taking direct or indirect steps, by the undertaking or a person acting on its behalf, to procure the transfer or commitment of capital by one or more investors, for the purpose of investing it in accordance with a defined investment policy. It is expressly immaterial whether this happens once or on an ongoing basis, and whether contributions are in cash or in kind.

On number of investors, the guidelines adopt a capacity test rather than a headcount: an undertaking not prevented by binding legal arrangement from raising capital from more than one investor is treated as raising capital from a number of investors even if it in fact has only one. Even a genuinely single-investor vehicle is caught if that sole investor is itself an aggregator, and the guidelines give as paradigm examples master-feeder structures, fund-of-funds structures where the fund of funds is the sole investor in an underlying vehicle, and nominees aggregating multiple investors' interests.

On defined investment policy, the guidelines say an undertaking has one if it has a policy about how the pooled capital is to be managed to generate a pooled return, and list indicative factors: the policy is determined and fixed at latest by the time investors' commitments become binding; it is set out in or referenced by the rules or instruments of incorporation; the undertaking or its manager is under a legally enforceable obligation to investors to follow it, including all changes to it; and it specifies investment guidelines by reference to criteria including categories of assets, restrictions on asset allocation, particular strategies, geographies, restrictions on leverage, minimum holding periods, or other restrictions designed to provide risk diversification. Then, in paragraph 22, a sentence that will do heavy work below: leaving full discretion to make investment decisions to the legal person managing an undertaking should not be used as a means to circumvent the provisions of the AIFMD.

What does not exist

Two absences frame everything that follows. First, there is no judgment of the Court of Justice of the European Union interpreting the Article 4(1)(a) definition itself. The Court has decided AIFMD cases on adjacent questions (the 2022 HOLD Alapkezelő judgment on remuneration rules, for instance), but the foundational questions of what constitutes a collective investment undertaking or a defined investment policy have never reached Luxembourg. Everything in this area is being reasoned from a directive drafted in the shadow of the 2008 crisis and a soft-law text from 2013, applied to instruments neither could have contemplated, with zero judicial gloss.

Second, no purpose-built EU regime fills the gap from the other side. MiCA, the crypto-asset framework in application since the end of 2024, expressly declines the territory twice over: recital 22 places crypto-asset services provided in a fully decentralised manner without any intermediary outside its scope without ever defining what fully decentralised means, and Article 2(4) excludes from MiCA altogether any crypto-asset that qualifies as a financial instrument under MiFID II. That second exclusion has an underappreciated consequence for this paper's subject matter: units in collective investment undertakings are themselves MiFID II financial instruments (Annex I, Section C(3)). If a vault is an AIF, its share token is not a crypto-asset governed by MiCA at all. It is a fund unit governed by the fund acquis. The two regimes are not alternatives that overlap; they are mutually exclusive, and the AIF analysis decides which one applies.

ESMA has, in fact, already walked partway down this road. Its 2025 guidelines on the qualification of crypto-assets as financial instruments, issued under MiCA's boundary-drawing mandate, apply the 2013 key concepts to crypto-assets expressly, instructing authorities to test tokens against the general commercial or industrial purpose criterion and against whether token holders, as a collective group, hold day-to-day discretion or control. Most strikingly, the guidelines offer a worked example: a crypto-asset entitling holders to a proportional share of the returns generated by a managed portfolio, without any participation in governance regarding investment strategies, and redeemable for a share of the portfolio's value, should be considered a unit in a collective investment undertaking. Read that sentence against Part I of this paper and the conclusion is unavoidable: ESMA has described, as its paradigm case of a token that is a fund unit, the economic mechanics of an ERC-4626 share. What neither those guidelines nor the joint EBA and ESMA report of January 2025 under Article 142 of MiCA attempt is the next step, the mapping of the definitional limbs onto the actual permission architectures of deployed vault systems, and the identification of where, within the vault design space, the perimeter falls. That mapping remains open at every level of the EU system, with no judicial gloss and no supervisory decision on record, which is precisely why working it through from first principles is worth doing.

Part IV: Reading the function table through the four limbs

The method of this Part is to take each limb and ask what specific contract behaviour satisfies or defeats it, then assemble the results per archetype. Archetype 1 is set aside: a registered fund whose token is a share register raises no perimeter question.

Raising capital: deposit() and the irrelevance of permissionlessness

The guidelines require a commercial activity of taking direct or indirect steps to procure the transfer or commitment of capital, by the undertaking or a person acting on its behalf. A public, permissionless deposit() function, advertised through a front-end interface displaying projected yields, integrated into aggregators, and promoted by the vault's curator or the protocol's growth team, sits comfortably within this language on a plain reading. The steps taken to procure capital are the deployment of the entry function itself, the publication of the interface, and the marketing of the advertised APY; the transfer of capital is the transferFrom executed inside deposit(); and the contributions are subscriptions in kind (ERC-20 tokens rather than cash), which the guidelines expressly say is immaterial, as is the fact that subscription is continuous rather than a one-off raise.

Two industry counterarguments fail quickly against the text. The first is that nobody solicits anyone: the contract is simply there, and depositors come to it. This is difficult to sustain on the facts of any commercially operated vault, where curators compete publicly on performance, front-ends surface yields, and fee revenue depends on attracting deposits; the "commercial activity" is not hypothetical, it is the business model. The second is that the protocol merely deploys neutral infrastructure and is not "acting on behalf of" any undertaking. That argument has more force for archetype 6, as we shall see, but for a curated vault the curator's economic position (typically a share of the performance fee, configured through the vault's own fee functions) makes it the person procuring capital for the undertaking in as direct a sense as any placement agent.

Number of investors: the limb no public vault can escape

The capacity test does the work here. An ERC-4626 vault with an unrestricted deposit() function is not merely not prevented from raising capital from more than one investor; it is architecturally incapable of preventing it. The limb is satisfied before the first deposit arrives.

The interesting cases are the restricted ones, and they get caught by the aggregation rule instead. Consider a vault whose gate contracts restrict shares to a single whitelisted address, where that address is another vault. This is not a hypothetical: composability means vaults hold other vaults routinely, and archetype 4 is built on exactly this pattern, the parent vault being the depositor of record into each tokenised strategy. ESMA's paradigm examples of caught single-investor structures are the master-feeder and the fund of funds where the fund of funds is the sole investor in the underlying undertaking. A Yearn v3 tokenised strategy whose sole depositor is the parent allocator vault is that example, translated into Solidity with almost eerie fidelity. Where the sole investor is itself an aggregating pool, the underlying undertaking counts as raising capital from a number of investors, which means the AIF analysis potentially runs at both layers of the stack: the parent vault against its depositors, and each strategy vault against the parent.

Collective investment undertaking: the depositor's power set

Take the three characteristics in turn, at the level of what depositors can actually call.

No general commercial or industrial purpose: a vault does not purchase, sell or exchange goods, supply non-financial services, or produce anything. Its entire object is deploying pooled financial assets for return. Satisfied trivially, for every archetype including archetype 6.

Pooling for a pooled return: this is where the ERC-4626 share arithmetic described in Part I becomes legally load-bearing. The definition of pooled return is the return generated by pooled risk arising from acquiring, holding or selling investment assets. The convertToShares() mechanism is pooled risk, implemented as arithmetic: every depositor's claim is a fraction of totalAssets(), every gain and loss anywhere in the vault's positions passes through that single number, and no depositor can be insulated from any position's outcome. In traditional structures one sometimes has to argue about whether returns are genuinely pooled or merely administered together; in an ERC-4626 vault the pooling is provable from the share-price formula.

No day-to-day discretion or control by the unitholders as a collective group: recall that the depositor's complete power set under the standard is deposit, redeem, transfer. None of these is a power of decision over the daily management of the undertaking's assets. The allocation functions (reallocate(), update_debt(), executiveRebalance(), callOnExtension()) all sit behind role modifiers that exclude depositors categorically. It is worth being precise about what the guidelines require, because the vault industry sometimes points to timelocks and exit windows as depositor "control": the defined term requires a direct and ongoing power of decision over operational matters, extending substantially further than shareholder-style voting on structural matters. The ability to exit during a timelock window is not a power of decision over management at all; it is the fund-law equivalent of a redemption right with notice, which every open-ended fund investor has and which has never taken any fund outside the definition. Even vaults whose governance tokens let holders vote on parameters do not escape, both because governance token holders and depositors are distinct (and usually mostly disjoint) groups, and because voting on parameter proposals is precisely the merger-and-liquidation style of influence the defined term expressly carves out as insufficient.

The conclusion is uncomfortable for the industry but hard to resist: every archetype in this paper, including the immutable pool, likely constitutes a collective investment undertaking. The perimeter is not going to be drawn by this limb. It is going to be drawn by the last one.

Defined investment policy: where increaseAbsoluteCap() meets paragraph 20(d)

Now the decisive limb, and the paper's central argument.

Begin with archetype 3, the curator vault, because the industry consensus holds it furthest from fund management and the text points the other way. Set the curator's function table against ESMA's indicative list of investment guidelines and read them side by side. The guidelines say a defined investment policy is indicated by guidelines referencing categories of assets to invest in; the curator's market-enabling decisions (which lending markets, which collateral assets, which oracles the vault may touch, enacted through submitCap() and adapter listing) are exactly that. The guidelines say restrictions on asset allocation; a supply cap set through increaseAbsoluteCap() is a machine-enforced restriction on asset allocation, not a description of one. The guidelines say restrictions designed to provide risk diversification; a relative cap limiting exposure to any single collateral across all markets to a percentage of the pool, set through increaseRelativeCap(), is a diversification restriction in the most literal sense available. The curator role does not merely have an investment policy within the meaning of paragraph 20(d). The curator role is an investment policy compiler: its entire function surface consists of writing paragraph 20(d) criteria into storage, where they bind.

Now the supporting factors. Paragraph 20(a) asks whether the policy is determined and fixed at latest when investors' commitments become binding. A depositor's commitment becomes binding at the moment deposit() executes, and at that moment the vault's entire policy (enabled markets, caps, queue ordering, fee, timelock duration) is on-chain, immutable within the block, and readable by anyone. No traditional fund achieves that degree of fixity at subscription; a limited partner commits against a prospectus, a vault depositor commits against state. Paragraph 20(b) asks whether the policy is set out in or referenced by the rules or instruments of incorporation. The vault's constitutive document is its deployed bytecode plus configuration; the policy is not referenced by the constitution, it is stored in it. Paragraph 20(c) asks whether there is a legally enforceable obligation to follow the policy, including all changes to it. Here sits the one genuinely contestable point, and it deserves honest treatment. A smart contract constraint is not an obligation enforceable by investors in a court; it is a constraint that makes the obligation unnecessary by making breach impossible. A formalist reading could say paragraph 20(c) is therefore unsatisfied. But three things count against the formalist reading. First, the paragraph 20 factors are expressly indicative and non-cumulative (they operate singly or cumulatively), so 20(d) alone can carry the limb. Second, the change-control machinery cuts the other way: the timelock on cap increases, with a guardian empowered to revokePendingCap() and depositors free to exit before effectiveness, is a mechanism for binding the manager to the policy including all changes to it that is stricter than anything a fund-side letter achieves, and a purposive reading of a text aimed at investor protection should not penalise a structure for over-delivering the protection through a different enforcement medium. Third, paragraph 22's anti-circumvention instruction tells competent authorities not to let breadth of managerial discretion defeat the definition; it would be perverse to read the same guidelines as letting narrowness of discretion, enforced in code, defeat it instead.

The conclusion for archetype 3 is the paper's first counterintuitive result, and it bears stating starkly. The curated vault's defence against fund characterisation ("the curator only sets risk parameters, it never picks positions") is a description of an entity whose only outputs are the precise items on ESMA's list of what constitutes a defined investment policy. The archetype does not sit near the perimeter. On the text as it stands, it sits inside it, and more comfortably than archetype 2, whose fully discretionary manager satisfies the limb only via the anti-circumvention route, whereas the curator satisfies it on the plain words.

Archetype 2 itself is quickly dealt with: the mandate configured at vault setup (asset universe, permitted adapters, any policies) plus paragraph 22's instruction that full discretion cannot be used to escape the definition together leave no plausible exit. Archetype 4 follows archetype 3 with the added force of the fund-of-funds point made under the number-of-investors limb, and one addition: the debt allocator's target weights, maintained through update_max_debt_for_strategy() and executed through update_debt(), are restrictions on asset allocation under 20(d) at the strategy level, so the limb is satisfied twice over, once per layer of the stack.

Archetype 5 splits three ways along its access control, exactly as trailed. The managed vault, where executiveRebalance() sits with an external market maker, has pooled capital managed under a policy (the vault's mandate: this pool, this pair, ranges set by this manager to optimise fee capture) toward a pooled return, and is inside the definition on the same reasoning as archetype 2, with the caveat that the policy is unusually narrow. The self-managed vault fails the raising-capital limb before the policy question arises: an entity depositing its own treasury into a wrapper it controls raises nothing from anyone. The trustless vault is the genuinely hard case. Its strategy is determined and fixed at deployment (paragraph 20(a) satisfied maximally), embodied in the instrument of incorporation (20(b) likewise), and it plainly constitutes a strategy in the 20(d) sense: the code actively repositions pooled assets to optimise their value, which falls within the pooled-return definition's phrase "activities to optimise or increase the value of these assets". The best argument against classification is not the absence of a policy but the absence of anyone managing pooled capital: the limb speaks of a policy about how capital "is to be managed", and one can argue that a frozen algorithm, changeable by nobody, is not management but a product feature, closer to a structured product's payoff formula than to a mandate. I do not think the text resolves this, and unlike the curator case I decline to force it. What can be said with confidence is that the question is live, that it turns entirely on whether "managed" implies an ongoing manager, and that the industry's habit of treating "trustless" as a synonym for "unregulated" assumes the answer rather than establishing it.

Archetype 6 is where the definition finally, and correctly, runs out. The immutable pool satisfies the first three limbs (it pools, its suppliers lack any discretion, its supply() function is open to the world). But there is no policy about how the pooled capital is to be managed, because the pooled capital is not managed. No allocation function exists; no address holds any power to deploy supplier capital anywhere; the capital's deployment is decided unilaterally and continuously by borrowers, exercising their own demand against a deterministic price curve. A rate formula is not a strategy; a collateral factor set by open governance is a product parameter, not an investment guideline binding a manager, because there is no manager for it to bind. The contrast with archetype 5's trustless vault is the sharpest available illustration of the distinction that, on this paper's reading, actually draws the EU fund perimeter in DeFi: not human versus automated, not custodial versus non-custodial, not centralised versus decentralised, but the presence or absence, anywhere in the function table, of a power (living or frozen) to direct pooled capital in pursuit of return. Where such a power exists, the structure tends into Article 4(1)(a) however decentralised its branding; where it genuinely does not, the structure is infrastructure, however large its pool.

Part V: If it is an AIF, who is the AIFM?

Classification as an AIF is not, in itself, the regulatory event. AIFMD regulates managers, not funds: the obligations (authorisation, capital, conduct, depositary appointment, transparency) attach to the alternative investment fund manager, defined in Article 4(1)(b) as a legal person whose regular business is managing one or more AIFs, and Article 5 requires each AIF to have a single AIFM responsible for compliance. Annex I then defines what managing means: an AIFM performs, at minimum, the investment management functions of portfolio management and risk management. This is where the vault architecture, having walked into the AIF definition, collides with assumptions the Directive never states because its drafters never imagined they could fail.

The Annex I mapping is embarrassingly clean

Start with what should be the hard question and is not: does anyone perform Annex I functions for a curator vault? Recall the role split. The curator sets the risk framework: which markets are permissible, what the exposure limits are, enacted through timelocked cap functions. The allocator executes positioning within that framework: setSupplyQueue(), reallocate(). Now read Annex I(1): portfolio management and risk management, the two functions whose joint performance constitutes managing an AIF. The vault architecture has not escaped the Directive's model of management. It has decomposed the Directive's own two-function definition of management into two on-chain roles, with a fidelity that no traditional delegation structure achieves, since in traditional structures portfolio and risk management blur inside one firm, whereas on-chain they are separated by access modifiers. The industry's role terminology (curator as risk, allocator as execution) reads like a paraphrase of Annex I. If the question is whether investment management functions are being performed in respect of these vehicles, the function table answers it against the industry.

The real difficulties are elsewhere, and they are three.

The legal person problem

Article 4(1)(b) requires the AIFM to be a legal person. The curator role in a production vault is typically held by a multisig: in the better-run cases, a Safe controlled by a named risk management firm, and there the analysis is straightforward, since the firm behind the keys is a legal person performing risk management as its regular business for a fee, which is to say the statute maps onto it without strain (subject to the sub-threshold regime noted below). But roles can be held by DAOs without personality, by unincorporated key ceremonies, or by addresses whose controllers are simply unknown. The Directive contains no mechanism for an AIF whose manager cannot be resolved to a legal person; it assumes the resolution is always possible. Three outcomes are conceivable and none is comfortable: a competent authority pierces through to whoever factually controls the keys (workable for identified multisigs, arbitrary for genuinely distributed control); the vehicle is treated as internally managed, making the AIF its own AIFM, which fits awkwardly since the vault contract is not a legal person either; or the arrangement is treated as an AIF being managed by no authorised person, which is not a gap in regulation but an ongoing breach by whoever is found to be performing the Annex I functions. The last of these is the reading a motivated regulator would reach for, and the on-chain record, unlike in any traditional enforcement context, supplies a complete, timestamped log of every exercise of management discretion, attributable to specific addresses, forever.

The single-manager assumption

Article 5's model of one AIFM responsible for the whole is challenged by architectures in which curator, allocator and owner are unrelated entities whose only relationship is the contract's permission graph. Traditional fund law would analyse this as delegation: the AIFM delegates portfolio management to a third party but remains responsible, subject to the letter-box entity constraint in Article 82 of Delegated Regulation 231/2013, under which an AIFM that delegates to the point of retaining no substantive function ceases to qualify as the manager at all. Applied to a vault, the delegation frame generates a genuinely novel question: if the curator is the AIFM and the allocator its delegate, does a curator who has configured caps and then gone dormant, leaving all live decisions to the allocator, become a letter-box, shifting AIFM status down the permission graph to whoever actually exercises the ongoing discretion? On-chain, unlike anywhere else, that question is empirically answerable: the relative activity of curator and allocator addresses is public data. One can imagine, without much strain, a supervisory methodology that identifies the AIFM of a vault by measuring which role's key ceremonies actually fire. The determination of who manages a fund would become, for the first time in the history of fund regulation, a query against a public ledger.

The depositary impossibility

Article 21 requires the AIFM to ensure a depositary is appointed for each AIF it manages: a credit institution or equivalent, holding custody of the fund's financial instruments and verifying its cash flows. A non-custodial vault has no assets capable of being given to a depositary; the assets are held by the contract, and the entire architecture is a machine for ensuring no intermediary can hold them. This is not a compliance burden, it is a compliance impossibility, and it exposes the deeper truth of the collision: AIFMD's investor-protection toolkit assumes that the dangers to be mitigated are intermediary dangers (a manager absconding, a custodian failing), and it mitigates them by inserting supervised intermediaries. The vault mitigates the same dangers by deleting the intermediaries and replacing them with constraints. A curator vault's timelock plus guardian plus caps plus exit window is, functionally, a depositary oversight regime and a mandate compliance regime, implemented in a medium the Directive does not recognise as capable of performing them. Whether the answer is to deem the code arrangements equivalent, to carve these structures out, or to force them into wrappers that reintroduce the intermediaries the technology removed, is the genuine policy question underneath everything in this paper, and it is notable that the January 2025 joint EBA and ESMA report under Article 142 of MiCA, for all its length, does not reach it.

The sub-threshold safety valve

One practical note tempers the severity of all of the above. Article 3(2) of the Directive provides a registration-only regime for managers whose total assets under management remain below EUR 100 million (or EUR 500 million for unleveraged vehicles with a five-year lock-up, a limb of little use to structures offering block-by-block liquidity). A large share of curated vaults, and a larger share of curators aggregated across their vaults, sit below the lower threshold on current numbers; for them, the consequence of the analysis in this paper is registration and reporting in a home Member State rather than full authorisation. But the threshold cuts across the industry's growth thesis directly: the flagship curators already manage aggregate pools well above it, and every step of institutional adoption pushes more of the sector across the line at which the full Directive, depositary impossibility included, applies.

Part VI: Summary of positions

The mapping this paper defends, stated in one place. The tokenised fund wrapper is an AIF or equivalent regulated fund by construction, and uses the chain only as a register; it anchors the scale but tells us nothing. The discretionary on-chain vehicle is an AIF on any reading, with paragraph 22 closing the only escape route, and its open questions are managerial, not definitional. The curator vault is, on the plain text of ESMA's guidelines, an AIF with an unusually well-evidenced defined investment policy, its cap functions and timelocks satisfying paragraph 20's factors more cleanly than most traditional funds manage; its serious questions are the legal person problem and the depositary impossibility, not the perimeter. The allocator-of-strategies vault is an AIF at the parent level and arguably at each strategy level, via the aggregation rule ESMA wrote for fund-of-funds structures. The rules-based liquidity vault splits on the access control of a single function: managed variants fall inside, self-managed variants fail raising capital, and trustless variants present the one genuinely undecided question in the taxonomy, whether a strategy frozen at deployment is still capital being managed. The immutable pool falls outside, not because it is decentralised but because no power to direct pooled capital exists anywhere in its function table, and a definition built around a defined investment policy cannot capture a structure that has no policy and nobody to hold one.

Three implications follow for how the industry talks about itself. First, the phrase "we only curate risk parameters" should be retired as a regulatory defence, because under ESMA/2013/611 paragraph 20(d) it is a confession: risk parameters are the guidelines whose presence indicates a defined investment policy. Second, the design energy now spent making vault roles look less like managers would be better spent on the questions that actually bite (who is the legal person, what substitutes for the depositary), because the perimeter analysis is largely lost on the text as written and the managerial analysis is where structures will succeed or fail. Third, and for the policy audience: the absence of CJEU authority, the silence of the Article 142 report on the fund question, and MiCA's mutual exclusivity with the fund acquis together mean that the classification of several tens of billions of euros of pooled capital currently rests on how national authorities choose to read two soft-law documents, the 2013 key concepts guidelines and the 2025 qualification guidelines, against Solidity, one enforcement decision at a time. And the 2025 text has already loaded the dice: its paradigm example of a token constituting a fund unit is, in economic substance, a vault share. That is not a stable equilibrium. The function tables are public; the analysis in this paper can be run by any supervisor with a block explorer; and when it is run, the industry should not expect the answers to track its branding.

Conclusion

The recurring pattern of this paper is that the vault ecosystem has, mostly without intending to, reimplemented the conceptual architecture of EU fund law in a new medium: ERC-4626 shares reimplement pooled return, deposit() reimplements subscription in kind, ERC-7540 queues reimplement notice periods, curator caps reimplement the investment policy, timelocks reimplement change control, the curator and allocator split reimplements Annex I's two functions, and gates reimplement eligibility regimes. Reimplementation is not escape. A directive that defines its object functionally will capture functional equivalents, however alien the substrate, and the anti-circumvention instruction in ESMA's guidelines exists precisely to make sure of it. What the reimplementation has changed is everything downstream of classification: the medium in which the policy binds, the observability of the manager's every act, and the impossibility of complying with obligations designed for intermediaries in structures designed to have none. The perimeter question, this paper has argued, is more settled than the industry believes. The question of what supervision means for a fund whose mandate is bytecode and whose manager is a permission graph is not settled at all, and it is the one worth spending the next several years arguing about.

---

Primary sources: Directive 2011/61/EU (AIFMD), Articles 3, 4, 5, 21 and Annex I; ESMA, Guidelines on Key Concepts of the AIFMD, ESMA/2013/611 (13 August 2013); ESMA, Guidelines on the conditions and criteria for the qualification of crypto-assets as financial instruments, ESMA75-453128700-1323 (2025); Commission Delegated Regulation (EU) 231/2013, Article 82; Regulation (EU) 2023/1114 (MiCA), recital 22 and Article 2(4); Directive 2014/65/EU (MiFID II), Annex I Section C(3); EBA and ESMA, Joint Report on Recent Developments in Crypto-Assets (Article 142 of MiCAR), EBA/Rep/2025/01 (13 January 2025); EIP-4626 and EIP-7540; deployed contract documentation and source repositories of the protocols discussed (Morpho MetaMorpho and Vault V2, Yearn v3, Enzyme, Arrakis, Aave v3).