Why one SPV per claim

Every financial claim in the instrument catalogue — a letter of credit, a receivable, a warehouse receipt, a metal stream, a participation — is a different legal animal, governed by different law, in a different jurisdiction, with different transfer mechanics. Tokenizing each one directly would mean solving that legal problem once per claim type, forever.

The ADGM special purpose vehicle is what makes that unnecessary. It is the adapter: heterogeneous claims go in, one uniform investor-facing instrument comes out.

What the constraint actually binds is the token, not the vehicle count. A single-issuer debenture structure can sit outside the Fund definition — and what pushes it back inside is a token representing a discretionary portfolio of multiple notes, not the number of SPVs in existence. The precise fork is set out below, because it is easy to state it too strongly and we did.

The adapter pattern

The SPV does two things and nothing else:

1. It acquires the claim. Whatever the underlying is — a credit-linked note, a revolving loan, secured project debt, a discounted receivable — the vehicle takes ownership of it under its own governing law, with security perfected wherever the collateral sits.
2. It issues its own debenture against it. The investor never holds the underlying claim. They hold a debt security issued by a vehicle whose only asset is that claim.

All the legal heterogeneity is absorbed at step 1, which is a private acquisition governed by the underlying's own law. Step 2 is uniform: the same instrument shape, the same transfer rules, the same disclosure, every time. That is why the corpus can carry 101 different archetypes and still present one token — the variety lives below the vehicle, not above it.

This is also why the claim schema matters more than the token contract. The scarce work is the adapter that turns this particular facility into the canonical shape. The token is the easy part.

The fork is about the token, not the vehicle count

The source that drives this design states it as an architecture fork:

One-facility sdrUSD is legally much cleaner than a token representing a discretionary portfolio of multiple SPV notes. Do not silently turn the v1 note structure into a fund.

Read that carefully, because two different questions hide behind "one SPV per facility", and only one of them is a licensing question.

Question 1 — how many facilities may one vehicle hold? Not settled by the fund definition. A single-issuer debenture structure can sit outside the Fund definition in specified circumstances, and final classification depends on substance and terms. Putting two facilities from the same obligor into one vehicle does not automatically create a fund; it does merge their credit and re-open the substance question. This is a structuring decision — ring-fencing, creditor isolation, investor clarity — not a permission gate.

Question 2 — may one token represent many vehicles, managed as a portfolio? This is the licensing question, and it is where the fund regime attaches.

FSMR section 106 defines a Collective Investment Fund by cumulative limbs. The two that matter here are that contributions are "pooled", and that the property is "managed as a whole by or on behalf of the Fund Manager". Units in a Collective Investment Fund are Securities under FSMR Schedule 1, and Managing a Collective Investment Fund is itself a Regulated Activity requiring permission.

A token whose value derives from a discretionarily managed basket of notes satisfies both limbs almost by construction: contributions are pooled, and the portfolio is managed as a whole. At that point the structure is a fund, and the fund regime attaches in full:

Our own formalization lands exactly there. On today's facts the pooled route evaluates to provedInfeasible with the blocker named in full — Managing a Collective Investment Fund (FSMR Schedule 1; FUNDS 1.1.1(a)). Not a warning: a closed route, until the permission exists.

What the route actually requires

Here the formalization is narrower than the prose above it used to be, and the narrower version is the accurate one. spvNoteRouteStatus turns on three conditions — and the number of facilities in the vehicle is not one of them:

• The vehicle is passive. No regulated function is performed inside the SPV. If it is not, the route is provedInfeasible with spvActivityNotPermitted — this is the condition that fails first and hardest.
• The notes are Securities. If the instrument falls outside the Security paragraphs the route returns unresolvedInterpretation and needs re-analysis rather than a workaround.
• Every regulated function sits in a permitted entity. Arranging, custody and management happen around the vehicle, in entities that hold the relevant permissions.

With all three satisfied the route resolves to feasible with conditions — the conditions being the MKT offer-route obligations and the Companies Regulations provisions.

What this route does not do

It would be easy to read the above as "no licence required". That reading is wrong, and the project's own analysis says so directly: the thesis is narrower than that. An own-debenture exclusion may cover the issuance, while the offer, custody and trading rules still apply in full. The offer leg is anchored at MKT 4.3.1(1) — the exempt-offer route — not waived.

Three further cautions, stated because a reader will otherwise supply the optimistic version:

Classification depends on substance, not labels. A single-issuer debenture structure can sit outside the Fund definition in specified circumstances, and whether it does depends on the actual terms. Calling a vehicle passive does not make it passive.

Tokenization does not remove the securities layer. A tokenised debenture is still a debenture. Digital-securities guidance applies on top, not instead.

Secondary transfer is a separate question. Do not assume permissionless transfers; whitelisting and eligible-venue treatment have to be designed and cleared, and the venue analysis is its own route.

So do you need a vehicle per counterparty?

No. Nothing in the route conditions counts entities or facilities, and no theorem in the development encodes a facility limit per vehicle. What forces granularity is weaker and more ordinary than a licensing rule:

• Ring-fencing. You generally do not want facility A's creditors reaching facility B's collateral, which is the usual reason each financing gets its own vehicle in structured finance — with or without a fund regime in the picture.
• Investor clarity. A noteholder should be able to say exactly what backs the note. That is a disclosure and diligence virtue, not a permission.
• The token boundary. Keep sdrUSD tied to identified claims rather than to a managed basket, or the fund analysis attaches regardless of how the vehicles are arranged.

On cost, the registry fee is not the constraint. Incorporation runs about USD 1,900 plus a company-charge filing fee for the secured structure, with modest annual official fees. The corporate-service provider, counsel, custody, trustee and KYC quotes dominate — and our source is explicit that those are provider quotes to be obtained, not estimated. The fee page carries the issuer-level cost base; per-vehicle marginal cost is not yet quoted.

Could one unified vehicle hold everything instead?

This is the natural question once the adapter exists, and the answer separates two things that are easy to merge.

What is unified is the abstraction, and that is the whole point. One claim schema, one adapter interface, one investor-facing instrument shape. That is what makes the next facility cheap to onboard, and it is the actual moat — the scarce work is the adapters, not the vehicle.

Unifying the legal vehicle is a different move, and it cuts the wrong way. A single entity holding every facility, with one token over it, is the configuration most exposed to the fund analysis, not least: contributions are pooled into one vehicle, and its property is managed as a whole. Those are precisely the two FSMR s.106 limbs. The single-issuer debenture exclusion is strongest when the vehicle is borrowing against identified assets; it weakens as the vehicle becomes a growing, actively selected portfolio, because classification depends on substance and terms rather than on the label.

It also gives up the thing SPVs exist for. One vehicle is one estate. If every facility sits in it, facility A's creditors reach facility B's collateral, and a single obligor's insolvency contaminates claims that had nothing to do with it. Ring-fencing is not a regulatory nicety here — it is the mechanism that makes a note about this metal a claim on this metal.

The structure that would reconcile both is a cell or compartment company: one legal entity, statutory segregation per cell, so operational overhead stays near-single-vehicle while each facility keeps its own estate. That pattern exists in other jurisdictions.

Whether ADGM offers it is an open question this documentation cannot answer: the ADGM Companies Regulations are published as portal HTML only, no consolidated text was captured, and nothing in our corpus is parsed on cell structures. It is a specific, cheap question for counsel, and a favourable answer would materially simplify operations without touching the fund boundary. Until it is answered, assume separate vehicles and price accordingly.

The consequence for the product

This is why the two tokens are shaped the way they are. The payment leg is a fiat-referenced token governed by COBS 19A, backed by treasuries and redeemable at par. The yield leg is a claim on facility economics — and it is legally far cleaner as one facility's debenture than as a share in a pooled multi-facility vehicle, which re-creates the fund analysis the single vehicle exists to avoid.

Scaling therefore means more identified claims, not a discretionary basket. Whether each claim sits in its own vehicle is a structuring choice driven by ring-fencing and creditor isolation; what must not drift is the token becoming a managed portfolio. That is the line the source warns against crossing silently, and it is the one worth holding.

Every provision cited on this page is sourced and hashed, and the ADGM position records which routes resolve and which remain open.