Securitize: The “Vault = Investor” Model (feat. Vault Registrar)

Key Takeaways

• DeFi's pool-based model evolved around permissionless tokens. Under this architecture, it is difficult to implement compliance requirements such as investor-level ownership tracking and transfer agent obligations for permissioned assets.

• sTokens and Aave Horizon integrate regulatory compliance at the token level and the protocol level, respectively. However, both approaches introduce scalability bottlenecks, including reliance on wrappers and protocol-specific implementation overhead.

• Securitize's Vault Registrar deploys investor-bound vaults, standardizing ownership attribution and recordkeeping around the principle of "one vault = one investor position."

• Building on this, Securitize introduces the Vault Registrar ERC, which standardizes the integration surface between permissioned tokens and DeFi protocols at the vault level.

1. DeFi Has Evolved with Crypto Assets as the Default

Out of all issued RWAs, only around 9% are actually being used in DeFi today. While the total RWA market has surpassed $20B in outstanding assets, most RWA lending markets remain constrained by shallow liquidity or conservative risk parameters, resulting in single digit utilization rates across many protocols. This reflects the current reality of RWA DeFi.

A key bottleneck lies in the fact that DeFi infrastructure was originally designed around permissionless crypto assets such as BTC and ETH. DeFi has evolved over nearly a decade, but its default assumptions have consistently centered on crypto native collateral.

As a result, for RWA DeFi to scale meaningfully, the stack requires infrastructure upgrades purpose built for regulated assets. Above all, full regulatory compliance across the entire onchain lifecycle must be achievable. This is a prerequisite for enabling institution led borrowing and liquidity provision, and for bringing high quality assets such as private credit and U.S. equities into DeFi as collateral.

To address this gap, Securitize recently introduced Vault Registrar and submitted it as an ERC proposal. This article examines how RWA DeFi has evolved to date, the structural limits of the pool based model, and how Securitize is implementing a transition from pools to vaults.

2. Pools Destroy Attribution

Nearly all DeFi protocols operate on top of pools. Lending and borrowing occur dynamically around shared liquidity pools, while assets are rebalanced according to yield optimization strategies. By aggregating liquidity from many participants into a single unit, the pool model eliminates the need for counterparty matching and has become the most natural architecture for onchain finance.

However, once this model is applied to regulated RWA tokens that are treated as securities, several fundamental issues emerge.

1. Ownership Attribution Breaks Down Inside Pools

For permissionless tokens, aggregating assets inside a pool is not an issue. Investor positions can be expressed as proportional pool shares, and there is no requirement to track which specific asset belongs to which investor. Assets inside the pool are fully fungible, and the pool itself is treated as a single unit of collective liquidity.

Securities tokens, however, require continuous investor level ownership tracking. When regulated assets such as BUIDL or ACRED are deposited into a pool, it becomes difficult to deterministically attribute legal ownership at the investor level as assets are transferred, rehypothecated, or rebalanced. This in turn complicates core securities obligations such as dividend distributions, voting rights, and tax reporting.

2. Conflicts With Transfer Agent Obligations

Registered transfer agents such as Securitize are legally required to maintain real time investor level ownership records. In traditional securities markets, corporate actions including dividends, record dates, distributions, and redemptions all rely on this investor centric recordkeeping.

For example, to distribute dividends to holders as of Feb 27, the issuer must know exactly how many units each investor held at that point in time. Once assets enter a pool, however, only the pool address and aggregate balances remain visible. This alone is insufficient to satisfy regulatory requirements.

3. Inability to Attribute Subscriptions to Specific Investors

Consider a looping flow that follows the sequence: buy, collateralize, borrow, buy more, collateralize again. In most securities markets, the incremental purchase step is not a generic swap, but a subscription that must be attributed to a specific investor.

This means that when a protocol performs automated purchases or rebalancing, it must verify whose subscription the transaction represents, whether the investor is eligible, and whether subscription limits are respected. Pools, by design, operate as a single collective liquidity unit, making it impossible to attribute individual purchases to specific investors.

Take a simple example where a user borrows USDC against ACRED and then uses the borrowed funds to acquire more ACRED. Under a pool based model, the additional ACRED cannot be cleanly attributed back to the original investor. A pool cannot act as the subscribing party for regulated securities on behalf of an individual investor.

In practice, this makes it extremely difficult for pool based architectures to fully comply with securities regulation once RWA tokens must be processed at the investor level and at transfer agent grade accuracy. Pool models were designed with permissionless assets in mind, and regulated assets fundamentally require a different infrastructure approach.

3. Evolving Within the Pool Model: Aave Horizon and sTokens

Before Securitize introduced Vault Registrar, there were already meaningful attempts to patch the limitations of the pool model. Different approaches emerged to integrate compliance mechanisms into DeFi flows in ways better suited for RWAs, and these designs have established themselves as viable interim solutions in RWA DeFi.

3.1 Aave Horizon: Native DeFi Collateralization for RWAs

Among these, the most representative is Aave Horizon, where Securitize participates as an infrastructure partner. Aave Horizon is an RWA-focused market designed for institutions and eligible investors, operating as a separate instance of the Aave protocol.

Aave Horizon allows permissioned tokens to be supplied as collateral and used to borrow stablecoins. Securitize provides the compliance infrastructure covering issuance, ownership tracking, yield distribution, and rights management, enabling regulated assets to be used directly as DeFi collateral without wrappers.

The design of Aave Horizon centers on four principles:

• Permissioned collateral: Only whitelisted participants can supply RWAs as collateral.

• Non-transferable aTokens: When RWAs are deposited, users receive aTokens with ERC-20 transfer functions (transfer, approve, permit) disabled. This ensures the collateral position remains tied to the original investor, allowing stable calculation of each investor's share within the pool.

• Built-in safeguards: Exceptional cases requiring issuer intervention, such as lost keys or sanctioned wallets, can be handled without disrupting the collateral pool.

• Permissionless liquidity: The lending and borrowing mechanics remain DeFi-native. Anyone can supply stablecoins such as USDC or GHO, and borrowers using RWAs as collateral can access this deep liquidity.

In this structure, onchain collateral positions in Aave Horizon are synchronized with Securitize's Master Securityholder File (MSF), ensuring that yield accrual and rights calculations reflect the collateralized state. Regulatory requirements such as lost-share handling or recovery processes are also supported without breaking pool operations. As a result, Aave Horizon preserves the native RWA asset state while still satisfying compliance obligations.

Euler Finance takes a similar approach. Euler integrates Securitize's DS Protocol directly into its Vault Kit (EVK), allowing DS Tokens to be used as native collateral in isolated lending markets. Securitize deploys a collateral vault in its capacity as transfer agent, while curators deploy a separate borrowing vault, forming a dual-vault structure.

Only whitelisted investors can participate in deposits, borrowing, and liquidations, and vault share tokens are non-transferable. The fact that actual DS Tokens are directly incorporated into the protocol without wrappers reflects the same design philosophy as the Aave Horizon model.

3.2 sTokens: An ERC-4626 Based RWA DeFi Interface

Another approach is sTokens, a standard designed by Securitize. sTokens are ERC-4626 based vault wrappers that allow Securitize-issued RWA tokens such as BUIDL and ACRED to be used in DeFi.

Eligible investors deposit their RWA tokens into an sToken vault and receive DeFi-native sTokens (e.g. sBUIDL, sACRED) in return. These sTokens can then be used as collateral for lending, looping, or other DeFi strategies, and can be redeemed back into the underlying RWA when needed.

At the point of deposit into the sToken vault, Securitize pre-verifies all regulatory requirements, including investor eligibility, jurisdiction, transfer restrictions, and redemption rights. Investors who do not meet these criteria cannot mint sTokens.

Using this framework, Securitize partnered with Morpho, Polygon, and Gauntlet to launch a leveraged RWA strategy built on sACRED. Users deposit sACRED into a Gauntlet vault, which supplies sACRED as collateral to Morpho and borrows USDC. The borrowed USDC is then used to purchase additional ACRED, which is re-deposited as collateral. Repeating this cycle builds a leveraged position.

The key point here is that compliance and ownership are fully resolved before the asset enters the DeFi environment. Once Securitize verifies investor eligibility and legal ownership at the sToken level, the asset can move freely within DeFi without requiring repeated compliance checks.

However, sTokens have effectively been deprecated and are being replaced by other solutions such as Aave Horizon and Vault Registrar. The wrapper structure required an additional abstraction layer, and ownership, record dates, rights, distributions, and other regulatory information inevitably remained separated from the DeFi-native token representation. These structural limitations are the backdrop for this transition.

3.3 The Remaining Gap: Why Vault Registrar Is Needed

This is the path RWA DeFi has taken to address compliance constraints so far.

Aave Horizon and Euler Finance secure regulatory alignment at the protocol level. Both accept RWAs natively without wrappers, and Aave Horizon has already reached meaningful scale, exceeding $50 billion in AUM. sTokens, on the other hand, secured compliance at the token level. They offered the most flexibility for DeFi use cases.

Despite this progress, both approaches leave important limitations:

• sTokens: The underlying RWA must still pass through an intermediate wrapper. This is more than an added abstraction layer. Ownership, record dates, rights, distributions, and regulatory events necessarily remain separated from the DeFi-native token representation.

• Aave Horizon / Euler: Each design is tightly coupled to its respective protocol, limiting scalability. Aave Horizon's aToken structure and MSF integration, and Euler's EVK dual-vault structure and DS Protocol integration, are all solutions specific to those protocols' architectures. Other protocols such as Morpho, Compound, or Spark would need to re-implement comparable custom logic and compliance integration to achieve the same result.

In short, sTokens achieve regulatory alignment at the token level but require wrappers, while Aave Horizon and Euler achieve it at the protocol level but impose per-protocol reimplementation overhead. Vault Registrar is designed precisely at this intersection as a new alternative.

4. Vault Registrar: Vault = Investor

Vault Registrar takes a fundamentally different approach from the pool model. Instead of tracking ownership within a shared pool, it deploys dedicated vaults per investor. Each investor is assigned an independent smart-contract vault, shifting compliance from the token or protocol layer to the investor-bound vault itself.

4.1 Vault Registrar Contract

4.1.1 How Vault Registrar Works: EVM

The core component enabling this model is the VaultRegistrar contract, operated by Securitize. VaultRegistrar has authority to register and attribute wallet addresses for DS Tokens, which are tokens issued through Securitize's DS Protocol, a suite of smart contracts designed for compliant issuance and management of tokenized securities. BUIDL is an example of a DS Token.

VaultRegistrar is invoked alongside the user's deposit signature when DS Tokens are supplied to a DeFi protocol. It participates directly in the flow that deploys and registers investor-bound vaults. The process works as follows:

1. Investor authorization signature: The investor signs an EIP-712 structured message (Typed structured data hashing and signing) to explicitly grant a specific protocol (operator) permission to register vaults under their compliance identity. The signature includes the investor address, protocol address, token scope, and expiration.

2. Investor deposit request: The investor signs a deposit() transaction to supply DS Tokens to a DeFi protocol.

3. Dedicated vault deployment: An approved partner contract (an operator) calls VaultRegistrar during the deposit flow to atomically deploy an investor-bound vault. The investor's EIP-712 signature is submitted alongside this call.

4. Eligibility and authorization checks: VaultRegistrar verifies that the caller is an authorized operator, that the investor's EIP-712 signature is valid, that the investor has completed KYC, and that DS Token holding requirements are satisfied.

5. Vault registration: Within the same transaction, registerVault is called with the investor wallet address and the newly deployed vault address.

6. Registration finalized: Once all checks pass, the vault address is permanently attributed 1:1 to the investor's identity.

7. Asset transfer: The RWA tokens are transferred into the investor-bound vault.

All of this occurs atomically within the protocol's deposit transaction. While the protocol defines and controls the vault's execution logic, compliance enforcement is cleanly separated into the VaultRegistrar contract rather than being embedded at the token or protocol level. Ownership always remains with the investor. As a result, protocol builders can focus purely on financial logic without inheriting regulatory complexity.

As noted above, investor authorization in this process is based on EIP-712 signatures. In the initial design, VaultRegistrar operated under an implicit trust model where protocols could register vaults under an investor's identity without separate investor consent.

Through real-world integrations, this was improved so that investors can explicitly grant authorization (Explicit Vault Authorization) and revoke it at any time. Securitize transitioned to a model where investors sign a structured message readable in their wallet UI, containing the investor address, protocol address, token scope, nonce, and deadline.

This allows investors to approve with full awareness of which protocol is being granted permission for which token, and to immediately invalidate authorizations granted to a specific protocol. Because a single signature grants blanket authorization, there is no need for re-authorization at each step during collateral rebalancing or leverage loops. As a result, VaultRegistrar functions as a policy-enforcing registry that registers vaults only after verifying operator authorization, investor signatures, and compliance rules.

4.1.2 Vault Registrar for Solana

VaultRegistrar was initially designed for EVM, but Securitize has deployed a Vault Registrar program for Solana as the first step in multichain expansion. The core design goal is the same: protocol-deployed vaults must be registered under an investor's compliance identity, and the program handles registration only, without performing asset custody or transfers. It is an intentionally minimal, non-custodial, deterministic program that shares the same purpose as its EVM counterpart.

The implementation differs to accommodate Solana's architecture. While EVM relies on EIP-712 signatures for investor authorization, Solana achieves the same guarantees through transaction signer verification and Cross-Program Invocation (CPI) chains. The full flow is as follows:

1. Protocol call: The protocol (operator) calls register_vault during the investor's deposit flow.

2. Signer verification: The Vault Registrar program uses Solana's transaction model to confirm that the investor is the original signer of the transaction. This corresponds to the "explicit investor consent" role that EIP-712 signatures serve on EVM.

3. Compliance verification via CPI chain: The Vault Registrar verifies investor KYC eligibility and compliance requirements through a CPI (Cross-Program Invocation) chain running from Vault Registrar to rwa-rbac to Identity Registry to System Program, using the DS Token identity registry as the source of truth.

   A CPI chain is Solana's mechanism for one program to invoke other programs in sequence. When a vault registration request is submitted, role permission checks (rwa-rbac), investor identity verification (Identity Registry), and onchain account processing (System Program) are all executed sequentially within a single transaction.

4. PDA-based vault attribution: Once all verifications pass, the vault wallet is attributed 1:1 to the investor's identity using a PDA (Program Derived Address).

   A PDA is a Solana-native account address scheme that deterministically derives the same address from a given program ID and set of seeds (e.g. investor address, token address). Unlike regular wallet addresses, PDAs have no corresponding private key, meaning they cannot be arbitrarily signed or manipulated from outside. Only the deriving program can exercise authority over the address. This ensures that the mapping between vault and investor is fixed in an onchain-verifiable form.

In summary, the authorization mechanisms on EVM and Solana differ, but the guarantees are the same. Vaults are registered only in transactions where the investor explicitly participates, and are attributed only to compliance-verified investors. This allows Solana-based RWAs to use the same investor-bound vault model available on EVM.

4.2 Vault Registrar Use Cases

Investor-bound vaults open up a broad range of DeFi interactions while preserving ownership integrity and remaining fully compliant.

4.2.1 Smart Escrow (Conditional Asset Transfers)

VaultRegistrar's atomic transaction execution is primarily designed for compliance, but it also makes conditional asset transfers programmable at the vault level. Assets can be released only when predefined conditions are met, enabling financial logic tailored to RWAs.

• Institutional OTC transactions: Investor-bound vaults can be configured so that asset transfers execute only after conditions such as payment settlement or external verification are satisfied. This mirrors conditional OTC settlement in traditional finance, implemented onchain.

• Structured products: Structured products often release assets in stages or control cash flows based on performance or events. For example, borrowing can be permitted only if a private credit position achieves an annualized return of 8%, enforced through vault-level conditional execution.

• Conditional credit provision: Even when collateral is posted upfront, borrowing can be enabled only once predefined conditions are met, such as maintaining a certain financial state or reaching a specific time. Throughout this process, the collateral remains owned by the investor, while the vault permits borrowing only at the moment conditions are satisfied.

4.2.2 One-click Looping

Buy, collateralize, borrow, and buy again can be executed as a single transactional flow. Under the pool model, additional purchases made during looping cannot be directly attributed to a specific investor and must instead rely on ex post estimation through pool share ratios.

In the vault model, each incremental purchase is always attributed directly to the investor's dedicated vault. This allows leverage strategies to be implemented while maintaining precise attribution of the purchasing entity and satisfying compliance requirements.

4.2.3 Onchain Prime Brokerage Accounts

A prime brokerage account consolidates services such as collateral valuation, leverage provision, borrowing execution, risk limit management, and margin calls into a single account. It is an operational unit that independently manages assets, liabilities, and risk on a per-investor basis.

Investor-bound vaults make it possible to recreate this prime brokerage model onchain. Beyond acting as asset custody containers, vaults function as investor-specific smart contracts that execute collateralization, borrowing, rebalancing, and conditional actions in code. When composed with other DSApps built on the DS Protocol, this enables automated credit flows such as reinvesting borrowed funds or reducing positions once collateral ratios breach predefined thresholds.

4.3 ERC: Vault Registrar Interface

Source: Ethereum Magicians

Securitize did not limit this architecture to its own products. Instead, it submitted an ERC titled "Vault Registrar Interface for Permissioned ERC-20 Vaults" to the Ethereum Magicians forum.

Conceptually, Vault Registrar is the production implementation operated by Securitize, while the Vault Registrar interface on the ERC is the abstracted standard proposed for general adoption. The role and mechanism are the same, but the latter is designed so that multiple issuers and protocols can adopt a shared abstraction.

The need for such a general-purpose standard is threefold:

• Compatibility: If multiple DeFi protocols adopt the same vault registration interface, they can rely on the standard itself rather than individually validating issuer-specific attribution logic.

• Interoperability: Permissioned tokens issued by different issuers can be integrated into the same DeFi flows. This expands integrations from a 1:1 relationship between a protocol and an issuer to an N:N structure across many protocols and issuers.

• Simplified integration: Protocols do not need to implement token-specific compliance and transfer logic. A single call to a standardized registrar is sufficient to include regulated assets in DeFi flows.

The ERC-defined interface centers on two key entry points:

1. Vault registration function

registerVault(address vaultAddress, address investorWalletAddress, uint256 deadline, bytes calldata signature)

This function registers an investor-bound vault deployed by a protocol for a given investor wallet. The call must include the investor's EIP-712 signature and a deadline. If the signature is invalid, expired, or compliance verification fails, the transaction reverts. The call executes atomically within the same transaction as the deposit flow. Once completed, the vault is permitted to hold and manage regulated assets under the investor's authorization.

2. Standardized event for attribution

VaultRegistered(address indexed investor, address indexed vault, address token, string investorId, address indexed sender)

This event records onchain which vault has been registered for which investor and for which permissioned token. The sender field enables tracking of the protocol (operator) that executed the registration. Issuers, transfer agents, auditors, and reporting systems can use this event as the canonical source for investor-level ownership tracking.

The design principle behind this interface is clear. It is built as a standalone companion contract interface that does not extend ERC-20, defining only core functions and minimal events. This design assumes an environment where many existing RWA tokens cannot be upgraded, or where contract modifications are not permitted for regulatory or operational reasons.

• Fragmentation of token standards: The market already contains multiple permissioned token standards such as ERC-1400 and ERC-3643. Attempting to unify them through ERC-20 extensions would require reissuance or complex migrations, which is often impractical.

• Issuer-specific compliance implementations: Compliance functions such as KYC eligibility checks and transfer agent logic are frequently managed outside the token, either in external systems or separate onchain modules. For this reason, embedding regulatory logic into ERC-20 extensions is not realistic either.

The ERC therefore leaves token contracts untouched and isolates investor attribution and authorization into a separate Vault Registrar contract. This provides the minimum viable standard for integrating regulated assets into DeFi flows in practice.

5. From Pool Models to Vault Models

As the crypto bear market drags on, interest in RWA-based DeFi is likely to persist. In an environment where onchain money market APYs hover around 2~4% and U.S. Treasury yields remain in the 3~4% range, collateralizing private credit, Treasuries, or equities becomes more rational than relying solely on crypto-native assets. Expectations around RWA looping are also rising, driven by the ability to target annualized yields around 8% from private credit without depending on incentive farming or token inflation.

Compliance, however, remains the largest bottleneck for RWA DeFi. In this context, Securitize's Vault Registrar and the generalized Vault Registrar ERC present a credible path forward. While the ERC is still in its early stages, the precedent set by ERC-4626 becoming the standard for DeFi vaults suggests that a similar standardization trajectory could emerge for RWA DeFi.

In closing, the term "RWA" itself is somewhat awkward. It is borrowed to contrast real-world assets with crypto-native assets, yet onchain infrastructure is inherently capable of supporting any asset class. Through tokenization, real-world assets have already become part of the default asset universe. The next step is to implement higher-context financial logic onchain. In that progression, the shift of DeFi's core unit from pools to vaults through Vault Registrar may prove to be the inflection point that renders the RWA label obsolete.