How Securitize’s CETs and APIs make launching a Tokenized Securities Venue for U.S. stocks and ETFs a much simpler engineering problem.

The SEC’s Innovation Exemption is opening the door to a new type of market for tokenized stocks and ETFs.

Under the exemption (Release 34–106402), qualifying Tokenized Securities Venues (TSVs) can operate permissioned AMMs and liquidity pools for tokenized NMS stocks, subject to specific conditions and a 30-day public notice requirement.

A TSV isn’t just a traditional exchange with a blockchain settlement layer. It allows securities to trade through programmable liquidity pools, with atomic execution and settlement, new asset pairings and potentially a much broader set of liquidity providers.

But for any of this to work with real U.S. equities, those pools need access to actual securities, eligible participants, inventory creation and redemption, and the corporate actions that come with owning stocks.

That’s the part we’ve built at Securitize.

Where do the shares come from? How do you ensure tokens are backed by real stocks? How do you onboard investors and permission their wallets? How do market makers mint and redeem inventory against the underlying market? And what happens when a stock splits, pays a dividend or gets halted while its tokens are sitting inside a liquidity pool?

These are problems we’ve spent years solving at Securitize. And the good news for prospective TSV operators is that you don’t need to solve them again.

We’ve built the infrastructure to handle the securities side of the equation, and exposed it through APIs so that TSV operators can focus on building their markets.

This isn’t just a theoretical architecture. It’s the mechanism we’re using to support the OKXICE TSV launch, and the same infrastructure we’re leveraging in our work supporting Formation’s TSV, enabling both stocks and ETFs to trade through the same CET infrastructure.

Here’s how it works.

First, what exactly is a TSV trading?

Not all tokenized stocks are the same.

Brett Redfearn, our President, recently explained the distinction between the different models and why it matters for TSVs.

There are two main ways to tokenize real equities.

• Issuer-Sponsored Tokens (ISTs) are shares tokenized with the participation of the issuer, typically through its transfer agent. The token represents the issuer’s shares directly.
• Custodial Entitlement Tokens (CETs) represent a security entitlement to a real share held through a broker-dealer and custody structure. The issuer doesn’t need to tokenize its shares for these tokens to exist.

Both are different from synthetic tokens, which provide economic exposure to a stock through a derivative or contractual arrangement rather than the same legal interest in the underlying security.

This distinction is particularly relevant for TSVs.

If we had to wait for every publicly traded company to tokenize its own shares before those stocks could trade onchain, the addressable market would be very limited. CETs let us tokenize existing stocks and ETFs today, with actual shares backing the tokens 1:1 and clear beneficial ownership attribution to the token holder.

At Securitize, CET also stands for Convertible Entitlement Token.

If the issuer later decides to tokenize its shares directly, our architecture is designed to support converting the CET into an IST while preserving the token’s onchain identity. A TSV could therefore start trading CETs and potentially transition to issuer-sponsored shares later without having to replace the token or relist it. That’s a pretty important property if you’re building market infrastructure intended to last.

This chart can help to explain the distinction:

The securities infrastructure is the hard part

The Innovation Exemption doesn’t mean securities stop being securities.

A TSV still needs to operate within the conditions of the exemption. The tokens need to represent real securities, participation must be permissioned, corporate actions need to be handled, and the venue must respect trading restrictions, issuer objections and other requirements.

The problem is that these capabilities traditionally live in several different systems.

You need a broker-dealer and custody infrastructure to handle the underlying shares. You need investor identity verification and eligibility checks. You need transfer restrictions. You need a mechanism for market makers to create and redeem token inventory. And you need a corporate actions processor that understands what happens when securities are held inside smart contracts.

At Securitize, we’ve already built all these components.

Our CET model provides the legal and operational structure for the underlying securities. Our APIs expose the functionality needed to integrate them into a trading venue.

The TSV doesn’t need to replicate that infrastructure.

1. Onboarding and permissioning: SecID API

The first question for any permissioned securities venue is straightforward: who is allowed to hold and trade these tokens?

We’ve built Securitize ID to handle investor identity, screening, eligibility and wallet permissioning.

For a TSV, there are different integration options:

• You can direct users to a Securitize-hosted onboarding flow, or integrate onboarding directly into your application using our APIs.
• If your platform already performs KYC, we can also structure an integration that relies on your existing verification process, subject to the applicable agreements and requirements. There’s no reason to make every investor go through the same process twice if we can reuse the relevant information. We still perform the required screening, including sanctions and politically exposed person checks.

Once the investor is approved, their wallets can be registered and whitelisted to hold and transfer CETs.

So the integration is essentially:

Connect wallet → Verify investor → Register wallet → Whitelist → Trade.

You don’t need to build your own identity registry, sanctions screening infrastructure or token permissioning system.

Your venue can concentrate on the trading experience. We handle the underlying investor eligibility and token permissions.

2. Inventory management: CET Underlying API

A TSV needs liquidity. And if you’re trading tokenized public equities, that liquidity needs a mechanism to connect with the underlying stock market.

Our CET Underlying API gives authorized market makers a way to buy and sell the underlying stocks or ETFs and mint or burn the corresponding CETs.

The interface uses an authenticated WebSocket connection for orders, execution updates, balances and mint/burn events.

Here’s the basic flow.

Creating inventory:

1. A market maker submits an order to buy the underlying stock through our API.
2. Securitize executes the order through its brokerage infrastructure.
3. The corresponding CETs are minted to the market maker’s approved wallet as executions are processed.
4. The market maker can deploy that inventory into the TSV’s liquidity pools.

Redeeming inventory:

1. The market maker transfers CETs to the designated redemption address.
2. It submits the corresponding sell order through our API.
3. The underlying shares are sold and the CETs are burned as the process completes.
4. The market maker receives execution and reconciliation information.

That’s it.

The market maker has a programmatic path between traditional equity inventory and onchain tokens.

And importantly, the minting and burning happen through Securitize, outside the TSV itself.

The TSV handles secondary-market trading. We handle the creation and redemption of the tokens against the underlying securities. That separation is important under the Innovation Exemption, which restricts primary issuance activity on the venue. It also means the TSV doesn’t need to build its own stock brokerage, custody and issuance infrastructure.

The market maker can manage inventory against the underlying market, subject to normal execution, funding, settlement and market-hour constraints.

3. Corporate actions: Corporate Actions API

Stocks and ETFs don’t just trade. They pay dividends, split, merge, get suspended, undergo tender offers and experience all kinds of other corporate actions.

And these events become more complicated when the tokens representing those stocks are sitting inside AMMs.

Take a 2-for-1 stock split.

If you implement this by changing the token balances held inside a liquidity pool, you can create accounting and liquidity problems. The pool’s reserves change, the quantities represented by liquidity positions change, and the contracts need to account for those adjustments.

We’ve designed our token infrastructure to avoid unnecessary balance changes for splits.

On supported EVM deployments, we use display multipliers based on the ERC-8056 approach. On Solana, we can use Scaled UI Amount mechanisms.

The economic representation of the position changes without requiring liquidity providers to withdraw and recreate their positions just because a stock split.

Dividends and other entitlements are another challenge.

A token holder shouldn’t lose the economic rights associated with the underlying shares because the tokens are deposited in a liquidity pool.

Securitize handles the underlying corporate actions processing, including the attribution and distribution of entitlements to eligible holders, while the venue integrates the mechanisms needed to identify and account for positions held through its contracts.

Our Corporate Actions API gives the TSV the information needed to stay synchronized with the underlying securities. It covers corporate actions, relevant dates and terms, changes to announced events, and trading restrictions such as halts and suspensions. The integration is event-driven.

We provide signed webhooks, versioned events, status queries and replay capabilities, so operators can process changes reliably and recover if their systems go offline.

There’s also a sandbox with scripted scenarios to test how the venue reacts to corporate actions and trading restrictions.

This is one of those areas where building the infrastructure yourself can become a much larger project than expected.

With our APIs, you integrate with a corporate actions processor rather than trying to become one.

What the TSV still needs to do

None of this means Securitize takes over the responsibilities of the venue operator.

The TSV still needs to build and operate its trading infrastructure, including permissioned pools, execution logic, market controls and liquidity management.

It needs to integrate market makers, enforce its own participant restrictions and make sure its smart contracts comply with the conditions of the exemption.

It also remains responsible for its regulatory Notice, issuer notifications, applicable volume limits, public trade data and other venue-specific obligations.

For example, if trading in an underlying stock is halted, the TSV needs to stop trading that stock. We can provide restriction information through our APIs, but the venue must implement and operate the controls that enforce the halt.

Similarly, our investor onboarding and wallet permissioning infrastructure doesn’t automatically replace every obligation the TSV or its participants may have.

Securitize handles the securities infrastructure. The TSV handles the market.

That’s the model we’re using to support the OKXICE initiative and our work with Formation’s TSV, and it’s the same approach we can offer to other operators.

Can you really launch a TSV in 30 days?

The exemption requires a public Notice at least 30 calendar days before commencing operations, together with other applicable notification requirements.

That creates an interesting opportunity, but it’s important to distinguish the notice period from the engineering work.

The SEC expects the venue to be operationally ready when it publishes its Notice. So the objective isn’t to start building everything on Day 0 and hope it’s finished by Day 30.

The objective is to have the integration ready before filing, and this is where using existing infrastructure makes a big difference.

If you’ve already built your trading technology, the remaining integration can be relatively contained.

You need to connect to SecID for investor onboarding and permissioning, integrate the eligibility checks into your pools, connect your market makers to the CET Underlying API, and subscribe to the Corporate Actions API for lifecycle events and restrictions.

You also need to test the operational scenarios, validate the market controls and complete the applicable regulatory preparations.

We provide sandbox environments to support that work.

For a team with existing trading infrastructure, getting ready to publish the Notice in weeks is a realistic engineering objective, depending on the architecture, chain, market design and operational requirements.

Once the Notice is published, the applicable 30-day periods run. Trading can start when those periods have elapsed, the relevant issuers haven’t objected, and the venue satisfies the other conditions of the exemption.

The important point is that you don’t have to spend those weeks building the securities stack.

You can integrate with ours.

One infrastructure, multiple venues

There’s another reason I think this model is important.

We shouldn’t need a different tokenization infrastructure for every new trading venue.

The whole point of putting securities onchain is to make them more interoperable, not to recreate isolated markets with their own incompatible representations of the same stock. A CET is backed by the same underlying security regardless of which compatible venue trades it. The investor eligibility, token permissioning, corporate actions and inventory mechanisms can be shared across venues, subject to their individual requirements.

That allows each TSV to compete on the things it actually wants to differentiate: execution quality, liquidity, pricing, market design, user experience and integrations with the broader onchain ecosystem.

It also creates a path toward issuer-sponsored tokenization.

Today, a venue can support CETs backed by existing publicly traded shares. Tomorrow, if an issuer decides to tokenize its shares directly, our convertible architecture can provide a path from the custodial entitlement model to an IST.

The venue doesn’t need to bet on issuers adopting tokenization before it can launch.

We operate broker-dealer infrastructure for CETs and transfer agent infrastructure for issuer-sponsored securities. And we expose the relevant functionality through APIs rather than requiring every integration to be a bespoke project.

The work we’re doing with OKXICE and Formation is an application of that approach.

We expect other TSV operators to have different market designs and technology choices. That’s fine. Our objective isn’t to prescribe how a venue should trade, but to make sure the underlying securities infrastructure isn’t what prevents it from launching.

If you’re building a TSV, talk to us

We’ve spent years building the regulated and technical infrastructure required to bring real securities onchain.

With CETs, the underlying shares, investor eligibility, token permissioning, market-maker inventory and corporate actions can be handled through Securitize.

And with our APIs, integrating those capabilities doesn’t need to become a multi-year infrastructure project.

The technical documentation is available at https://developers.securitize.io.

If you’re building a TSV under the Innovation Exemption, or evaluating how to connect an existing trading platform to tokenized U.S. stocks or ETFs, we’d be happy to discuss the integration.

You build the venue. We bring the stock.

The services described are subject to applicable regulatory requirements, agreements, eligibility criteria and technical availability. TSV operators remain responsible for compliance with the conditions of the applicable exemption.

Disclosures

Developer documentation / Technical overview / Not an offer or solicitation.

Securities are offered through Securitize Markets, LLC, (“Securitize Markets”) a registered broker-dealer and member FINRA/SIPC and Securitize Europe Brokerage and Markets, a broker-dealer (Sociedad de Valores) and operator of a EU DLT Pilot Regime TSS registered with the Spanish National Securities Market Commission (CNMV). Securitize Markets, LLC, and Securitize Capital, an Exempt Reporting Adviser, are not involved in Real-World Asset (RWA) tokenization, a service provided by Securitize. Assets such as digital assets or tokens using blockchain, are speculative, involve a high degree of risk, are generally illiquid, may have no value, have limited regulatory certainty, are subject to potential market manipulation risks and may expose investors to loss of principal.

Securitize, Inc. (Securitize) is a Delaware corporation. Securitize is a technology provider which, together with its affiliates, maintains an end-to-end web-based platform used by issuers for issuing securities, specifically including digital asset securities. Securitize is not a registered broker-dealer.

Securitize Transfer, LLC is a transfer agent registered with the U.S. Securities and Exchange Commission.

Securitize Markets also operates Securitize Markets ATS, an alternative trading system. Securitize Capital, LLC is an exempt reporting adviser filed with the State of Florida.

The TSV Stack: You Bring Execution and Liquidity. We Bring the Stock. was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

How we used ERC-7540 to bring the ARK Venture Fund onchain without hiding end-of-day processing

Today, ARK Invest and Securitize announced the tokenization of the ARK Venture Fund (ARKVX) on Ethereum. For me, this is exciting not only because it brings one of ARK’s flagship investment strategies onchain, but because it required us to solve a fundamental market-infrastructure problem in a reusable way.

ARKVX is an actively managed closed-end interval fund focused on long-term capital growth through investments in private and public companies aligned with disruptive innovation. Bringing a product like this onchain requires much more than issuing a token. Investors also need to be able to subscribe, receive their tokens, request redemptions and receive the corresponding proceeds. And those operations should be transparent, programmable and accessible to other protocols.

This has been one of our objectives at Securitize since we began building the DS Protocol: bring as much of a security’s lifecycle onchain as possible.

For some products, we can make subscriptions atomic. An investor provides an asset such as USDC and receives the corresponding DSTokens in the same transaction. Redemptions work in reverse: DSTokens are burned and the investor receives the payment asset. Adan Carreno described this model in more detail in On and Off Ramps as DSApps: Expanding DSToken Capabilities.

ARKVX required a different model.

ARKVX is a registered closed-end interval fund under the Investment Company Act of 1940. An investor can submit a subscription during the day, but the applicable NAV (and therefore the number of ARKVX tokens they will receive) is determined later. Atomic settlement is not possible when one side of the transaction is not yet known.

This creates a natural separation between two events:

1. The investor requests a subscription and provides the funds.
2. Once the NAV is available, the subscription is processed and the corresponding DSTokens can be minted.

Redemptions have a similar lifecycle.

We wanted to support this without moving the subscription and redemption workflow offchain. Fortunately, there is an Ethereum standard designed specifically around this problem: ERC-7540.

ERC-7540 and asynchronous vaults

ERC-7540 extends the ERC-4626 tokenized vault model to support asynchronous deposits and redemptions.

The important idea is relatively simple: requesting an operation and completing it don’t need to happen in the same transaction.

Instead of a deposit immediately producing shares, ERC-7540 introduces a request lifecycle. An investor can submit a deposit request, that request can remain pending while the necessary offchain processes take place, and once it has been processed the resulting shares become claimable.

The same model works in the opposite direction for redemptions.

This maps very naturally to funds where pricing, liquidity or other operational processes make immediate settlement impossible.

Credit where credit is due: ERC-7540 was originally proposed by the Centrifuge team together with other contributors, and gives the ecosystem a common interface for solving this problem rather than every tokenization platform creating its own asynchronous subscription mechanism.

For us, using a standard here is particularly important.

It means that even though the lifecycle has asynchronous components, its state can still be represented and tracked onchain. It also means that wallets, vaults and protocols that understand ERC-7540 have a known interface they can integrate with.

How it works with DSTokens

For an ARKVX subscription using USDC, the simplified lifecycle looks like this:

1. The investor requests a subscription

The investor provides USDC and creates an onchain deposit request.

At this point we know how much the investor wants to invest, but we don’t yet know exactly how many ARKVX tokens should be issued because the applicable NAV has not been calculated.

2. The request remains pending

The subscription can be tracked onchain while the fund completes the corresponding processing and calculates its NAV.

3. The subscription is fulfilled

Once the NAV is known, the number of DSTokens corresponding to the subscription can be determined and the request becomes claimable.

4. The DSTokens are delivered

The corresponding ARKVX tokens are minted and delivered to the investor.

There is an operational advantage to separating these steps as well. Multiple subscriptions can be processed together once the NAV is available, allowing, for example, all the subscriptions in a cycle to be minted with a single onchain transaction instead of requiring an independent administrative transaction for each investor.

So while the process is asynchronous from the investor’s perspective, the underlying blockchain operations can actually become more efficient.

ERC-7540, with DS Protocol compliance built in

ERC-7540 defines a very useful common model, but it is intentionally generic. Tokenized securities have some additional requirements.

We have therefore extended the basic model with capabilities specific to DSTokens while maintaining compatibility with ERC-7540. A protocol that already knows how to interact with an ERC-7540 vault doesn’t need a special Securitize integration to understand the basic lifecycle.

There are a few additions worth explaining.

Eligibility is checked when requesting a subscription

A wallet cannot simply deposit USDC and request DSTokens.

When requestDeposit is called, we verify that the investor is eligible to receive the corresponding security under the DS Protocol. The wallet needs to be associated with an eligible investor in the corresponding Registry Service.

This brings the same compliance model used for DSToken transfers into the subscription process itself.

Investors can skip the manual claim transaction

The standard ERC-7540 lifecycle separates fulfillment from claiming. This is useful for composability, but for an individual investor it can also mean an additional transaction after their subscription has already been processed.

We added a convenience mechanism that allows an operator to be specified as part of the deposit request.

This makes it possible for Securitize to complete the standard claim step on the investor’s behalf and deliver the DSTokens directly to their wallet, without requiring the investor to return and submit an additional transaction.

Importantly, the standard claim model remains available.

A vault, protocol or other smart contract that prefers to control the claim itself can use the normal ERC-7540 lifecycle.

Redemptions can be partially filled

There is another practical situation that a generic vault standard does not fully address: a redemption request may not always be fulfilled in its entirety.

Our implementation supports partial redemption fills.

If only part of a redemption request can be processed, the investor receives the payment corresponding to the portion that was redeemed, while the excess DSTokens that could not be redeemed are returned to them.

This also allows the mechanism to support pro-rata redemption scenarios while keeping the result of the process explicit onchain.

Accessible from Securitize ID

Standards and smart contracts are useful, but investors shouldn’t need to understand any of this to invest.

The complete flow is available through the Securitize ID portal.

Existing Securitize investors can use their current account, while new investors can complete the corresponding onboarding process. Once eligible, an investor with USDC in their wallet can submit a subscription in a few clicks.

The complexity of the asynchronous lifecycle, compliance verification and eventual token issuance is handled underneath.

This is an important principle for us: onchain doesn’t have to mean complicated.

We want the infrastructure to be available onchain and programmable without requiring every investor to interact directly with smart contracts.

For a less technical walkthrough of what this means for investors, see our simple explanation of asynchronous onchain subscriptions.

But you can interact directly with the smart contracts too

For protocols and more advanced integrations, the exact same infrastructure supports what we call headless subscriptions.

Instead of going through the Securitize ID interface, a protocol can interact directly with the smart contracts to request subscriptions and redemptions.

This opens the door to automating these flows as part of other onchain strategies.

It also becomes particularly interesting when combined with ERC-8245, the Permissioned Vault Registrar interface we have been working on for DSTokens.

The ERC-8245 proposal is designed to provide a standard mechanism through which an onchain protocol can operate investor-bound vaults while preserving the compliance identity associated with the underlying investor. Combined with an ERC-7540 subscription flow, this means a protocol can potentially manage the lifecycle from the initial subscription request to holding and using the resulting DSTokens without requiring a bespoke integration for every step.

This is where standards become especially valuable.

ERC-7540 provides a standard interface for asynchronous investment flows. ERC-8245 provides a standard interface for protocols interacting with permissioned assets through investor-bound vaults. The DS Protocol provides the compliance and ownership infrastructure underneath the token.

Each solves a different part of the problem, but they can work together.

Starting with ARKVX, but not ending there

ARKVX is the first product where we are launching this new asynchronous subscription and redemption capability, but the infrastructure is not specific to ARKVX.

There are many investment products where subscriptions or redemptions cannot happen atomically. NAV calculations, liquidity windows, approval processes and other characteristics of traditional funds naturally introduce asynchronous steps.

Instead of hiding those steps in an offchain system, we can now represent the lifecycle onchain using a standard interface.

We will be expanding this capability to additional new and existing Securitize products.

For us, this is another step in making tokenized securities more useful onchain. Not by pretending that every traditional financial process can suddenly become instantaneous, but by creating the infrastructure to represent those processes transparently and programmatically even when they cannot.

The blockchain doesn’t need every operation to happen instantly.

It needs the operation to be understandable, trackable and composable.

ERC-7540 gives us a very good foundation to do exactly that.

Disclosures

Developer documentation / Technical overview / Not an offer or solicitation.

Securities are offered through Securitize Markets, LLC, (“Securitize Markets”) a registered broker-dealer and member FINRA/SIPC and Securitize Europe Brokerage and Markets, a broker-dealer (Sociedad de Valores) and operator of a EU DLT Pilot Regime TSS registered with the Spanish National Securities Market Commission (CNMV). Securitize Markets, LLC, and Securitize Capital, an Exempt Reporting Adviser, are not involved in Real-World Asset (RWA) tokenization, a service provided by Securitize. Assets such as digital assets or tokens using blockchain, are speculative, involve a high degree of risk, are generally illiquid, may have no value, have limited regulatory certainty, are subject to potential market manipulation risks and may expose investors to loss of principal.

Securitize, Inc. (Securitize) is a Delaware corporation. Securitize is a technology provider which, together with its affiliates, maintains an end-to-end web-based platform used by issuers for issuing securities, specifically including digital asset securities. Securitize is not a registered broker-dealer.

Securitize Transfer, LLC is a transfer agent registered with the U.S. Securities and Exchange Commission.

Securitize Markets also operates Securitize Markets ATS, an alternative trading system. Securitize Capital, LLC is an exempt reporting adviser filed with the State of Florida.

Asynchronous onchain subscriptions and redemptions for tokenized funds was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

BCAP holders can now keep their tokens and USDC in their own wallets while placing limit orders on the Securitize Markets Web3 ATS and settling matched trades atomically on Ethereum.

BCAP was created in 2017 as the first security token, representing an interest in a venture capital fund directly onchain.But issuing a security as a token does not automatically make every part of its market onchain.

Until now, trading BCAP through the Securitize Markets Alternative Trading System (ATS) followed a model that will be familiar to anyone who has used a centralized crypto exchange. Before trading, an investor had to move assets into accounts controlled through the platform:

• A seller deposited BCAP into their Securitize account.
• A buyer funded a cash account.
• Both sides could then place orders using the balances held inside the platform.

This model supports regulated secondary trading, but it also creates an odd result for a tokenized security: when investors want to trade the asset, they first have to move it out of their own wallet and into a centralized account.

With Web3 Trading for BCAP, we are changing that.

Eligible BCAP holders can bridge their tokens into Ethereum, connect their wallet to the Securitize Markets Web3 ATS, and place limit orders without depositing those tokens into a centralized Securitize account. Buyers can do the same with USDC. Until a trade executes, the assets remain in their respective wallets.

When a buy order and a sell order match, BCAP and USDC are exchanged atomically onchain, directly between the wallets, while the trade still executes through the regulated ATS and the required operational and regulatory processes happen as part of the transaction.

The wallets become the settlement endpoints. The ATS remains the trading venue.

A tokenized asset with an account-based trading model

The existing model separates the investor’s external wallet from the balance available for trading.

An investor may hold BCAP in a wallet, but that wallet balance cannot immediately be used to place an order. The tokens first need to be deposited into the Securitize platform. Similarly, a buyer who holds stablecoins in a wallet must fund the corresponding cash account before using that value for a purchase.

This means that trading starts with two funding operations:

1. Move the security into the platform.
2. Move the cash needed for the other side of the trade into the platform.

Only then can those balances be used in the order book.

There are good reasons why regulated markets developed around this kind of account structure. The broker-dealer and ATS need to know who is trading, confirm that participants are eligible, control which assets can be exchanged, maintain records, and perform the reporting associated with each execution.

The assumption has usually been that doing those things requires the assets to be held inside the same centralized environment.

But blockchain allows us to separate two concepts that have traditionally been bundled together: control of the trading process and custody of the assets before execution.

Trading from the wallet

In the new model, an investor starts from the BCAP trading page and connects an eligible Ethereum wallet.

The platform can then recognize the investor, verify that the wallet is authorized to hold and trade BCAP, and display the balance available from that wallet. There is no separate BCAP deposit into a Securitize-controlled trading balance.

To place a limit order, the investor defines the same basic parameters they would in the current ATS:

• Whether they want to buy or sell BCAP
• The number of tokens
• The desired price per token in USDC

The difference is the source of those assets. A sell order is backed by BCAP in the connected wallet. A buy order is backed by USDC in the connected wallet. Investors do not have to transfer either asset into a funded platform account just to make it available for trading.

The investor then confirms the operation through the wallet. This makes the authorization explicit: the platform prepares the order, but the investor approves it using the wallet that controls the assets.

Once confirmed, the limit order can participate in the ATS order book.

What happens when an order matches

Suppose one investor places an order to sell 1,000 BCAP at $100 per token, while another places a compatible order to buy the same amount using 100,000 USDC.

The ATS performs the matching. But instead of updating two balances held inside a centralized account structure, execution takes place on Ethereum:

1. The seller’s wallet delivers 1,000 BCAP.
2. The buyer’s wallet delivers 100,000 USDC (plus the ATS fees).
3. The BCAP moves to the buyer and the USDC moves to the seller as a single atomic transaction.

Atomicity is important here. The security transfer and the payment are not two separate operations that must later be reconciled. Either both sides of the exchange complete, or neither does.

That removes the settlement gap in which one asset has moved while the other has not.

The onchain transfer is only one part of the execution, though. The trade must still satisfy the controls that apply to BCAP and to activity on the Securitize Markets ATS. Investor eligibility, wallet authorization, execution records, and the relevant regulatory reporting remain integrated into the trading flow.

This uses the atomic settlement capability that Securitize Markets is now approved to facilitate: exchanging tokenized securities and stablecoins onchain inside the broker-dealer and ATS framework.

This is not an unregulated peer-to-peer transfer that happens to use the same interface. The order is placed and matched through the ATS. What changes is how the assets are held before the match and how they settle after it.

Limit orders rather than a liquidity pool

Web3 trading is sometimes used as shorthand for swapping assets through an automated market maker. That is not the model here.

BCAP investors are using a regulated order book and placing limit orders. They choose how many tokens they want to trade and the price per token they are willing to accept. An execution occurs when compatible orders meet.

This distinction is relevant for an asset such as BCAP. It preserves the price-discovery mechanics of an order-driven market while using smart contracts for settlement. We are not replacing the ATS with a DeFi pool. We are making the ATS operate with onchain assets held by its participants.

That combination is the point:

• Regulated participant onboarding and wallet authorization
• An ATS order book for matching buyers and sellers
• Investor-defined limit prices
• BCAP and USDC held in investor wallets before execution
• Atomic onchain delivery-versus-payment when a match occurs
• Integrated books, records, and regulatory reporting

Removing the need to pre-fund trading accounts

For investors, the most immediate change is simple: they no longer need to fund a Securitize cash account or deposit BCAP into a centralized trading account before placing an order.

Their assets can remain in their wallets and be used from there.

That reduces the number of transfers required to start trading and avoids keeping idle balances inside a separate account merely in case an order executes. It also makes the ownership model easier to understand. Before the trade, the seller controls the BCAP and the buyer controls the USDC. After the trade, they control the assets they received. The change happens onchain in one transaction.

For Securitize, this demonstrates that the regulatory responsibilities of operating a market do not require us to recreate every part of the traditional account model. The ATS can control who participates, how orders are matched, and how trades are processed, while blockchain handles the exchange of the assets between authorized wallets.

Why start with BCAP

BCAP is a natural asset for this launch.

It was created to show that ownership in a private investment fund could be represented through a blockchain token.

Web3 trading extends that history into secondary-market execution.

The relevant evolution is not that BCAP can move between Ethereum addresses. A token could already do that. It is that two eligible investors can express trading interest through a regulated market, keep control of their assets while their orders are open, and complete the resulting securities transaction through atomic wallet-to-wallet settlement.

From tokenized issuance to tokenized market structure

Much of the tokenization industry has focused on issuance: putting a fund, bond, or equity onchain. But if investors must move those assets back into conventional account structures whenever they want to trade, only part of the market has actually changed.

Web3 Trading for BCAP brings the order and settlement experience closer to the architecture of the asset itself.

The investor connects a wallet. The investor defines the order. The ATS matches it. The wallets settle it atomically. And the regulated processes remain part of the execution.

BCAP started by demonstrating that a venture fund interest could exist as a token.

Now it can also demonstrate how that token can trade as one.

Disclosures

Developer documentation / Technical overview / Not an offer or solicitation.

Securities are offered through Securitize Markets, LLC, (“Securitize Markets”) a registered broker-dealer and member FINRA/SIPC and Securitize Europe Brokerage and Markets, a broker-dealer (Sociedad de Valores) and operator of a EU DLT Pilot Regime TSS registered with the Spanish National Securities Market Commission (CNMV). Securitize Markets, LLC, and Securitize Capital, an Exempt Reporting Adviser, are not involved in Real-World Asset (RWA) tokenization, a service provided by Securitize. Assets such as digital assets or tokens using blockchain, are speculative, involve a high degree of risk, are generally illiquid, may have no value, have limited regulatory certainty, are subject to potential market manipulation risks and may expose investors to loss of principal.

Securitize, Inc. (Securitize) is a Delaware corporation. Securitize is a technology provider which, together with its affiliates, maintains an end-to-end web-based platform used by issuers for issuing securities, specifically including digital asset securities. Securitize is not a registered broker-dealer.

Securitize Transfer, LLC is a transfer agent registered with the U.S. Securities and Exchange Commission.

Securitize Markets also operates Securitize Markets ATS, an alternative trading system. Securitize Capital, LLC is an exempt reporting adviser filed with the State of Florida.

Web3 Trading for BCAP: From Funded Accounts to Wallet-to-Wallet Settlement was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve open-sourced a reference dApp that shows how to integrate directly with Securitize tokenized assets.

It is intentionally minimal. One page, no backend, no SDK. Just React, ethers, and the contract calls.

The timing here is not accidental.

The SEC just published a staff statement on “Covered User Interfaces” for crypto asset securities. The definition is straightforward: software that takes user-defined parameters, prepares the transaction, and lets the user interact with smart contracts from a self-custodial wallet.

That maps almost exactly to how integrations with tokenized assets already work onchain.

This repository (repo) could be used to implement a Covered User Interface (You should consult with your own counsel to determine if you satisfy the conditions listed in the SEC’s statement). And it is not just code. Alongside the sample dApp, we included a SECURITIZE_SKILL.md file that developers can use as a technical guide directly or hand to tools like Claude or Codex to accelerate integration work. The repo documents it as the deep-dive reference for DS Protocol architecture, asset discovery, compliance checks, ABIs, chain metadata, edge cases, and the implementation checklist.

Why we built this

Securitize assets are ERC-20s deployed on public chains. BUIDL, ACRED, VBILL, SCOPE. The contracts are live, the registries are onchain, and the subscription and redemption flows are implemented as smart contracts.

We’ve written before about how the DS Protocol works and how the different pieces fit together at the token level, and also about on-ramp and off-ramp contracts as first-class components of the system. Those posts explain the architecture.

What tends to be missing is the first end-to-end integration.

The pieces are there but assembling them together for the first time usually takes a couple of days. Which contract to call, how the registry check fits in, what changes per chain, where the swap actually happens.

So we implemented the full flow in its simplest form and kept it in one place.

The reference implementation

https://github.com/securitize-io/securitize-dapp-sample

The repo is deliberately stripped down. There is a working dApp, but the important part is that all the logic lives in a single file, SamplePage.jsx.

What you get:

• A fully working React dApp that lists every tokenized asset we publish, connects any EVM wallet, checks whitelist status on-chain, and executes atomic buy / sell / redeem flows
• A single commented file, `src/pages/SamplePage.jsx`, that contains the entire business logic — no hidden hooks, no service layer, no custom build
• A bundled JSON snapshot of the public feed so the app works offline out of the box
• `docs/SECURITIZE_SKILL.md` — a deep-dive developer guide with every ABI, every chain id, every known edge case
• Apache 2.0 license (trademarks excluded — see the `NOTICE` file)

No hooks hidden elsewhere, no service layer, no SDK wrapping calls.

You can read it top to bottom and see the full integration.

It fetches the list of assets, connects a wallet, checks whether the wallet is allowed to interact, and executes buy, sell, or redeem flows directly against the contracts.

That is the full surface area.

The model

Everything reduces to three pieces, which map directly to the protocol components described in the DS Protocol posts.

1. The public feed returns the list of assets and the contract addresses for each chain. On-ramp, off-ramp, token, redemption wallet. This is where your app should read from. Hardcoding addresses do not hold once new deployments are added.
2. The registry is the compliance layer. Every token exposes a DS Protocol service that points to the investor registry. You query it with a wallet address and you either get a result or you don’t. That single onchain read determines whether the wallet can interact.
3. The ramp contracts are where the interaction happens. As described in the on-ramp and off-ramp post, these are DSApps that extend the token with subscription and redemption flows. From an integration perspective, they behave like any other contract. Approve the stablecoin, get a quote, execute the swap.

Once these three pieces are clear, the rest follows.

What the flow looks like for Tokenized Funds

The sample keeps everything explicit, so the buy flow is a few calls.

Approve the stablecoin if needed. Call calculateDsTokenAmount to get the expected output. Apply slippage. Call swap.

Here’s the entire on-ramp transaction, lifted straight from the repo:

async function buyAsset(signer, rampAddress, stableAddress, stableDecimals, amount) {
 const rawAmount = ethers.parseUnits(amount, stableDecimals);
 const stableContract = new ethers.Contract(stableAddress, ERC20_ABI, signer);
 const onramp = new ethers.Contract(rampAddress, ONRAMP_ABI, signer);
// 1. Approve stablecoin spend
 const allowance = await stableContract.allowance(await signer.getAddress(), rampAddress);
 if (allowance < rawAmount) {
 await (await stableContract.approve(rampAddress, rawAmount)).wait();
 }
// 2. Preview output, apply 1% slippage
 const [estimated] = await onramp.calculateDsTokenAmount(rawAmount);
 const minOut = estimated * 99n / 100n;
// 3. Swap
 return (await onramp.swap(rawAmount, minOut)).wait();
}

A whitelisted wallet with USDC and the correct on-ramp address can subscribe to a fund in one transaction.

Redemptions follow the same pattern, with one difference. On some chains there is an off-ramp contract, so the redemption is atomic and returns stablecoins in the same transaction. On others, tokens are transferred to the fund and processed offchain.

This is the same distinction covered in the on/off-ramp post, just expressed here at the integration level. The public feed tells you which path applies and the sample reflects that.

How to use it

git clone https://github.com/securitize-io/securitize-dapp-sample
cd securitize-dapp-sample
npm install
npm run dev
# → http://localhost:3000/securitize-sample

You can run the repo locally in a couple of minutes, but the main value is using it as a starting point for your own integration.

Different teams will plug this into very different contexts.

• A custody platform can expose this flow to its users as part of treasury management, while keeping the interaction at the wallet level. In this context, the custody provider is already acting in its capacity as a custodian or as a technology provider to custodial workflows. The interface layer simply prepares the transaction, the user defines the parameters and signs, and the contracts handle execution onchain. The UI itself does not take custody or act as an intermediary in the transaction.
• A DeFi protocol can integrate the ramp layer to let users move between stablecoins and tokenized funds as part of a strategy. Instead of treating these assets as passive ERC-20s, the protocol can incorporate subscription and redemption flows directly into its logic.
• Wallets can expose these assets to users in the same way they surface tokens today, but with the ability to subscribe and redeem from within the wallet. The registry check and ramp calls are already onchain, so there is no need for a separate integration path.
• Vault curators and allocators can build on top of this to construct strategies that move capital across tokenized funds, using the same primitives shown in the sample.

This is also where models like Vault Registrar start to matter. If the wallet interacting with the asset is not the end investor but a contract acting on their behalf, authorization and delegation become part of the flow. We have written about this in the Vault Registrar work, and we will be releasing more tooling around it, but the integration surface remains the same. The difference is who is calling the contracts and under what permissions.

Across all of these cases, the pattern is the same.

The interface prepares the transaction. The user defines the parameters. The execution happens onchain.

This is also the boundary the SEC is describing in the Covered User Interface statement. Interfaces that stay on this side of the line, without taking control of execution, custody, or decision-making, fit within a much clearer model than traditional broker-style integrations.

The sample dApp is not meant to cover all of these cases. It shows the base interaction. From there, each team can adapt it to its own product.

What this is

This is a reference implementation of the integration layer for Securitize assets.

It shows how to:

• discover assets and contracts
• check whether a wallet can interact
• execute subscription and redemption flows

directly onchain.

The point is not the UI or the exact code structure. It is the shape of the interaction.

Once that is clear, the same model can be reused across different types of applications, from custody platforms to DeFi protocols to wallets and allocation layers.

Everything else sits on top of these primitives.

What comes next

This repo is the starting point. We’ll keep it working against the feed as we add chains and assets, and we’ll publish more focused examples over time — starting with tools to integrate with Securitize’s Vault Registrar.

If you build something with it, we’d love to see it. Open an issue, tag us, or drop a line to protocol@securitize.io.

Tokenized assets are on-chain. Now the integrations are, too.

Disclosures

Developer documentation / Technical overview / Not an offer or solicitation.

Securities are offered through Securitize Markets, LLC, (“Securitize Markets”) a registered broker-dealer and member FINRA/SIPC and Securitize Europe Brokerage and Markets, a broker-dealer (Sociedad de Valores) and operator of a EU DLT Pilot Regime TSS registered with the Spanish National Securities Market Commission (CNMV). Securitize Markets, LLC, and Securitize Capital, an Exempt Reporting Adviser, are not involved in Real-World Asset (RWA) tokenization, a service provided by Securitize. Assets such as digital assets or tokens using blockchain, are speculative, involve a high degree of risk, are generally illiquid, may have no value, have limited regulatory certainty, are subject to potential market manipulation risks and may expose investors to loss of principal.

Securitize, Inc. (Securitize) is a Delaware corporation. Securitize is a technology provider which, together with its affiliates, maintains an end-to-end web-based platform used by issuers for issuing securities, specifically including digital asset securities. Securitize is not a registered broker-dealer.

Securitize Transfer, LLC is a transfer agent registered with the U.S. Securities and Exchange Commission.

Securitize Markets also operates Securitize Markets ATS, an alternative trading system. Securitize Capital, LLC is an exempt reporting adviser filed with the State of Florida.

Build your own dApp on Securitize tokenized assets in a weekend was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using assets as collateral for borrowing other assets is one of the great unlocks of utility in DeFi, but most protocols deal with that using pools. And pooling collateral is great for composability… until you need to preserve who owns what, at all times, with transfer-agent grade accuracy.

That tension shows up immediately when you try to use regulated securities tokens as collateral or building blocks inside onchain protocols. You want automation, atomicity, and flexibility — but you also need beneficial ownership to remain clean, attributable, and regulated.

Today we’re introducing a new primitive that helps square that circle: Vault Registrar, powered by a new onchain component we call the VaultRegistrar contract.

This capability unlocks a cleaner pattern for:

• Dynamic, smart-contract escrows that still preserve beneficial ownership
• Protocol-owned “vaults” that act as smart wallets on behalf of a specific investor
• One-click looping flows (buy → collateralize → borrow → buy more) without running into the “pool attribution” wall
• Easier integrations for protocols that want to reason about whether RWAs are available and unencumbered, while still being held by the original investor

The problem: collateral is easy — ownership attribution is not

When tokenized securities move into shared pools, you introduce a set of problems that DeFi protocols typically don’t have to deal with:

1. Attribution inside the pool
2. Pools aggregate balances. For regulated securities, we can’t lose sight of which investor owns which underlying position.
3. Transfer agent obligations and lifecycle events
4. Corporate actions, record dates, distributions, redemptions, and other events are inherently investor-centric. Pools make this messy fast.
5. Subscription / primary issuance tracking
6. For many securities, “buying more” is not a generic swap — it’s a subscription tied to a specific investor (individual or entity). Pools generally can’t “subscribe” on behalf of many investors without additional platform machinery.

We’ve been trying to address this issue for a long time and we have seen the industry solve parts of this with specialized pool designs (including our own work in this area, like the integration with Aave Horizon, but that path typically requires protocol-specific changes designed for compliance, and recordkeeping and reporting adaptations to preserve investor-level tracking.

We wanted a model that’s simpler to integrate and scales across protocols.

The model: investor-bound vaults as “smart wallets”

Instead of depositing tokenized securities into a shared pool, this pattern keeps the tokens inside a dedicated vault (smart contract) that is bound to a specific investor.

Think of it as a programmable escrow / smart wallet:

• It can hold and manage DS Tokens
• It can interact with protocols (lend, borrow, escrow, loop, etc.)
• But from an ownership standpoint, the vault is not a “pool share” abstraction — it is an extension of the investor identity, onchain

That last part is the key.

To make it work safely, we need a way to register vault addresses under the investor’s identity in a way that’s:

• regulated
• atomic
• easy for protocols to integrate in their deposit flows

Introducing the VaultRegistrar contract

To facilitate vault authorization, we’re introducing the VaultRegistrar contract.

At a high level:

• The VaultRegistrar is controlled by Securitize and holds permission to register wallet addresses for DS Tokens.
• Approved partner contracts (we call them operators) call the VaultRegistrar during their deposit flow, at the moment they deploy a new vault for an investor.
• The protocol passes:

1. the investor address (the account initiating the deposit)
2. the newly deployed vault address

• The VaultRegistrar verifies:

1. the caller is an authorized operator
2. the transaction was initiated by an investor who is already registered / KYC-approved
3. the investor holds DS Tokens

If those checks pass, the vault address is registered under the investor’s identity.

And importantly:

All of this happens atomically inside the protocol’s deposit transaction, and the logic of the vault is fully defined and controlled by the protocol, so each vault can “do its thing”.

So partners get a clean, composable integration point: deploy vault → call VaultRegistrar → proceed, knowing the vault is permitted to hold/manage DS Tokens for that investor.

(If you want more background on how we think about DSApps and composable building blocks around DS Tokens, check out how our broader DS Token interfaces and components work)

Why this is better than pool-based collateral (in many cases)

Pools are powerful — and they absolutely have a place. But for regulated RWAs, vault-based collateral can be dramatically simpler.

1) No protocol changes required to preserve ownership attribution

With vaults, ownership doesn’t get “mixed”. Each vault is bound to a single investor identity, so a protocol doesn’t need to implement additional accounting to keep the transfer agent view consistent.

2) Fewer conflicts with investor-specific obligations

Investor-level tracking becomes a default property of the architecture — not something you retrofit after the fact.

3) It enables looping and primary-market style flows

Looping isn’t just “re-hypothecate and re-supply.” A real looping experience often needs the ability to buy more of a security mid-loop.

In pool-based models, that’s where things break: a pool can’t cleanly “subscribe” to a security in a way that attributes the purchase to a specific investor.

With this model:

• the vault is the smart wallet
• it can decide to invest in the name of its assigned investor
• it can do that by composing with other DSApps (including our on-ramps)

So you can build one-click looping where each incremental purchase is still attributable to the correct investor — cleanly.

The integration surface & Proposed Standardization

To make integration as seamless as possible for DeFi protocols and other smart contract services, we’re exposing a standardized on-chain interface for vault registration that partners can call as part of their deposit flows.

This model aligns with a broader proposal we’ve put forward on the Ethereum Magicians forum in the form of an Ethereum Improvement Proposal (EIP) titled “Vault Whitelister Interface for Permissioned ERC-20 Vaults.”

The motivation for the EIP is simple: many regulated or permissioned token ecosystems — particularly real-world assets — require investor-level ownership attribution that typical pooled models obscure. The proposed interface standardizes the authorization surface between protocols and permissioned token ecosystems so that:

• protocols can atomically deploy an investor-bound vault and register it in a single transaction,
• issuer logic (KYC, compliance checks, transfer-agent duties) remains issuer-defined and implementation-specific, and
• permissioned token standards themselves do not need to be modified.

We are proposing this as an EIP so that other permissioned token protocols and infrastructure providers can adopt the same pattern, making this capability a standard operation in the RWA DeFi ecosystem — not just a bespoke pattern tied to a single token or issuer.

Standard Interface (Shape & ABI)

Below is the core interface we’ve prototyped as part of this proposal (simplified for clarity):

interface IVaultRegistrar {
/// @notice Emitted when a vault is successfully registered
event VaultRegistered(
address indexed investor,
address indexed vaultAddress,
address indexed token
);
/// @notice Register a newly deployed investor vault for a specific investor
/// @param vaultAddress The address of the deployed vault
/// @param investorWallet The wallet address of the investor
function registerVault(address vaultAddress, address investorWallet) external;
/// @notice The underlying permissioned token this registrar applies to
function token() external view returns (address);
}

Protocols and services wanting to leverage this model simply need to integrate the VaultRegistrar contract into their process.

And once integrated, the process will be as follows:

- Investor interacts with some service or DeFi protocol that requires them posting their RWA as collateral.

- Investor signs the typical deposit() transaction (or similar semantics) that will move the assets from their wallet to a vault.

- As part of that same transaction the protocol deploys a new vault smart contract specific for this investor (via some factory model) and uses the VaultRegistrar contract to assign the fresh vault to the calling investor identity

- Then the RWA tokens are transferred to the vault address, which will work because as part of the process the address is now registered to the investor

In this pattern:

1. A DeFi protocol or partner (an “operator”) deploys a new vault contract (e.g., via a factory) for a specific investor during a deposit/lockup flow.
2. In the same transaction, the partner calls registerVault(vaultAddress, investorWallet) on the VaultRegistrar.
3. The VaultRegistrar contract:

• verifies the caller is an authorized operator,
• checks the investor is an authorized holder(KYC/KYB, accredited if required),
• confirms the investor holds permissioned tokens,
• then atomically registers the vault as attributed to that investor.

Once registered, the protocol can safely transfer the investor’s DS Tokens or RWAs into the vault without obscuring beneficial ownership.

This interface standardizes only the bridge between protocols and the issuer’s permissioned token ecosystem — it does not define how vaults themselves account for assets or shares (and is intentionally orthogonal to standards like ERC-4626).

Why A Standard?

By proposing this as an EIP companion standard, we enable:

• Composability: multiple protocols can adopt the same registration interface and trust the vault ownership logic
• Interoperability: permissioned tokens from different issuers can interoperate with DeFi flows without bespoke per-issuer integration.
• Simplified integrations: protocols don’t need to implement bespoke registration logic per token — they call the standard registrar.

This proposal is currently in early discussion and we’re actively seeking feedback from the community. If adoption gains traction, it has the potential to become the de facto standard for permissioned vault registration in RWA DeFi.

What this unlocks: HyFi use cases that actually scale

Once you can bind vaults to investor identities safely and atomically, a bunch of higher-level HyFi experiences get much easier:

• Smart escrow between parties (vault-mediated settlement and conditional transfers, while beneficial ownership stays attributable)
• Posting RWAs as collateral with clean “available/unencumbered” reasoning
• One-click looping built from composable DSApps, without pool attribution complexity
• DeFi protocol integrations that remain lightweight because ownership tracking is inherent in the vault model

In short: this expands the reach of Securitize’s RWAs in HyFi by giving partners a clean way to build “DeFi behaviors” without sacrificing the ownership model required by regulated assets.

Want to build with this?

If you have an idea where investor-bound vaults could unlock a better product — looping, escrow, collateralization, structured credit flows, prime-broker style automation, you name it — reach out to Securitize and let’s make it real.

Because the next wave of HyFi won’t be won by who can pool the most liquidity.

It’ll be won by who can make regulated assets programmable without losing the integrity of ownership.

Disclosures

Developer documentation / Technical overview / Not an offer or solicitation.

Securities are offered through Securitize Markets, LLC, (“Securitize Markets”) a registered broker-dealer and member FINRA/SIPC and Securitize Europe Brokerage and Markets, a broker-dealer (Sociedad de Valores) and operator of a EU DLT Pilot Regime TSS registered with the Spanish National Securities Market Commission (CNMV). Securitize Markets, LLC, and Securitize Capital, an Exempt Reporting Adviser, are not involved in Real-World Asset (RWA) tokenization, a service provided by Securitize. Assets such as digital assets or tokens using blockchain, are speculative, involve a high degree of risk, are generally illiquid, may have no value, have limited regulatory certainty, are subject to potential market manipulation risks and may expose investors to loss of principal.

Securitize, Inc. (Securitize) is a Delaware corporation. Securitize is a technology provider which, together with its affiliates, maintains an end-to-end web-based platform used by issuers for issuing securities, specifically including digital asset securities. Securitize is not a registered broker-dealer.

Securitize, LLC is a transfer agent registered with the U.S. Securities and Exchange Commission.

Securitize Markets also operates Securitize Markets ATS, an alternative trading system. Securitize Capital, LLC is an exempt reporting adviser filed with the State of Florida.

Vault Registrar: bringing “smart escrow” and one-click looping to regulated RWAs was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Leveraging real-world assets for capital-efficient on-chain yield.

Disclaimer: The following example is for educational illustration only and does not constitute an investment strategy, offer, or recommendation. This content is provided by Securitize, Inc. for informational purposes only and does not constitute financial, legal, or tax advice. The strategies, yields, and rates described are illustrative and subject to change. Leveraged yield strategies involve risk, including the potential loss of principal. Always verify current parameters and assess risk tolerance before deploying similar approaches.

Real-world assets (RWAs) on-chain are not only tokenizing traditional yield sources — they’re also enabling new forms of composable leverage. In this post, we’ll walk through how to create a leveraged yield loop using VBILL (VanEck Treasury Fund) in the Aave Horizon Market, currently offering a 3.93% yield through tokenized U.S. Treasury exposure.

Context: VBILL and Horizon RWA Market

VBILL represents shares in the VanEck Treasury Fund, a tokenized vehicle that holds U.S. Treasury bills and cash equivalents. Each VBILL token targets a stable $1 price and distributes accrued yield daily.

Horizon Market is Aave’s permissioned RWA deployment on Ethereum, allowing institutional participants to access RWA liquidity and use them as collateral.

At the time of writing:

• VBILL 7-Day Yield: 3.93%
• RLUSD Borrow Rate: ~2.84% (variable)
• VBILL Available Liquidity in Aave: $15M cap, 0% utilization

(But you can check the latest values here)

This opens an interesting opportunity for leveraged fixed-income yield through recursive collateralization.

Step 1: Deposit VBILL in Aave Horizon

We start by depositing 1,000,000 VBILL into the Aave Horizon RWA Market.

🔗https://etherscan.io/tx/0x60ea3a621cec2c4032dbcf69a95c6a857451f9c43f5d4218fe426b856f55838c

Once deposited, VBILL becomes active collateral with the following parameters:

• Max LTV: 83%
• Liquidation Threshold: 88%
• Liquidation Penalty: 3%

(The market shows 5M total liquidity available as the 1M provided has not been the only deposit made)

After depositing the VBILL in Aave, the Securitize account also shows a separate balance consideration for those collateralized assets (it actually shows an additional $100 that were deposited as a previous test) labeled as “Aave Horizon Market”:

Step 2: Borrow RLUSD Against VBILL

With VBILL as collateral, we borrow RLUSD, a real-world asset-backed stablecoin designed for institutional liquidity in the Horizon environment.

With the current 83% LTV, we can borrow $830,000 RLUSD.

🔗https://etherscan.io/tx/0x13b3b6f746b1eeb8d9e3961ffa288e808eb322a76aa675113f0ce48ad5221754

The RLUSD borrow rate as we do this is 2.84%, which is significantly below the 3.93% VBILL yield — creating the core of the yield differential that drives this strategy.

Step 3: Swap RLUSD to USDC via Curve

Next, we convert the borrowed RLUSD into USDC using Curve finance for stablecoin conversion. We are doing this conversion because the current subscription on-ramp for VBILL supports USDC, but we are working with Ripple to enable atomic subscriptions with RLUSD which will make this process even more seamless.

🔗https://etherscan.io/tx/0xc11432c4a513b3b7585089751b95dba6c7c30a089e65d245fe91ad99fff30586

After the swap, we now hold $829,722 USDC, ready to reinvest into VBILL.

Step 4: Subscribe to VBILL via Web3 Atomic Subscription

This is where Securitize’s technology enables a seamless flow.

Through the DS Protocol and the Securitize subscription smart contract, we can directly invest the USDC into the VanEck Treasury Fund in a single on-chain transaction, receiving newly minted VBILL tokens immediately.

🔗https://etherscan.io/tx/0xfaca9d3f4558f520ebafa155078acb2240141fe9030b34a4f90ab7ecf3238e9d

This capability — instant atomic fund subscriptions on-chain — eliminates traditional settlement delays and allows recursive DeFi strategies to operate natively with tokenized securities.

Step 5: Deposit New VBILL into Aave Again

With the new VBILL received, we deposit them again into Horizon. This completes one full leverage loop.

At this point, the position looks like this:

We can then repeat this process once more to reach a second loop, effectively creating leveraged exposure to the underlying Treasury yield.

Estimated Effective Yield

The leveraged yield after one loop can be approximated as:

Effective Yield ≈ Base Yield × Leverage — Borrow Rate × (Leverage — 1)

With:

• Base Yield = 3.93%
• Borrow Rate = 2.84%
• Leverage ≈ 1.83x

Effective Yield ≈ 3.93% × 1.83–2.66% × 0.83 = ~4.84%

After a second loop, leverage rises further and the effective yield could approach 5.5%, depending on execution efficiency and borrow rate stability.

Tokenized value realized

This setup shows how tokenized Treasuries like VBILL can interact natively with DeFi liquidity protocols. The key components that make this possible are:

• Permissioned RWA Market in Aave → institutional-grade collateralization
• RLUSD liquidity → borrowable highly liquid stablecoin
• Securitize DS Protocol → atomic subscription and redemption of fund tokens
• On-chain transparency → real-time verification of all positions and flows

This is not a synthetic yield — it’s on-chain access to real-world fixed income, enhanced by composability.

Risks and Final Thoughts

This strategy currently works because of the spread between:

• VBILL Yield (3.93%)
• RLUSD Borrow Rate (~2.84%)

That spread can compress:

• if RLUSD borrowing costs increase,
• if VBILL’s yield declines with falling Treasury rates
• or if VBILL value were to move below $1, in which case the loan could get undercollateralized and liquidated.

Leveraged yield strategies amplify both returns and risks — especially liquidation risk if collateral ratios tighten or liquidity conditions change.

We’ll explore in the future how new RWA listings in Horizon with different profiles — credit-based, private debt, or equity-linked — can enable new structured DeFi strategies.

Leveraged Yield Loop with VBILL in Aave’s Horizon RWA Market was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Demonstrating how tokenized funds can combine yield, compliance, and instant on-chain liquidity

The launch of instant RLUSD liquidity for HLSCOPE, the Hamilton Lane SCOPE Securitize Tokenized Feeder, LP, marks another major step forward in building a connected and efficient tokenized financial ecosystem.

This new capability extends the liquidity framework developed in collaboration with VanEck and Ripple, where VBILL, VanEck’s tokenized U.S. Treasury fund, can be instantly redeemed for Ripple’s RLUSD through Securitize’s regulated infrastructure.

But unlike VBILL, which connects directly to the RLUSD facility, HLSCOPE now leverages that same facility through smart contract composability — allowing it to liquidate its VBILL holdings and deliver RLUSD to investors atomically and on demand.

Building on an Existing Liquidity Framework

The HLSCOPE fund is a tokenized feeder vehicle that provides investors with access to alternative strategies through a blockchain-based structure. Like other Securitize-managed funds, it operates under a fully regulated framework, integrating dealer, transfer agent, and fund administration services to ensure compliance and investor protection.

What’s new is how HLSCOPE manages liquidity.

Instead of holding idle reserves or relying on manual redemption processes, its liquidity pool is now composed of VBILL, VanEck’s yield-generating tokenized money market fund.

When an investor initiates a redemption on-chain, the smart contract automatically prices the HLSCOPE units using the on-chain NAV delivered by RedStone’s oracle infrastructure, leveraging the Trusted Single Source Oracle (TSSO) framework announced jointly by RedStone and Securitize.

So the atomic transaction:

1. Determines the redemption value based on the current on-chain NAV provided by RedStone via the TSSO framework.
2. Liquidates the corresponding VBILL position within the existing RLUSD liquidity facility.
3. Delivers RLUSD back to the investor’s wallet in a single, seamless operation.

The entire process runs 24×7, without intermediaries, and remains fully auditable and compliant through Securitize’s regulated dealer and blockchain infrastructure.

Composability in Action

This capability illustrates one of the most powerful promises of tokenization: composability — the ability for financial instruments to interact and build upon one another programmatically.

The HLSCOPE fund uses the existing liquidity facility. By calling the same smart contracts that enable VBILL’s redemption into RLUSD, HLSCOPE gains instant access to liquidity from a pool that already exists and operates under regulatory oversight.

In traditional finance, such cross-instrument liquidity sharing would require complex coordination among multiple intermediaries.

In tokenized finance, it’s a matter of interoperable smart contracts, operating transparently and securely on-chain.

Yield, Liquidity, and Regulatory Soundness

Through this structure, the HLSCOPE fund’s liquidity pool remains productive: the VBILL tokens it holds continue to generate yield from U.S. Treasuries managed by VanEck, while still offering investors instant redemption capability in RLUSD.

At the same time, Securitize’s regulated infrastructure ensures that all participants meet the same compliance and reporting standards that govern traditional financial markets. Every transaction remains tied to verified, KYC’d investors, maintaining the integrity of both the product and the broader ecosystem.

This combination — yield, instant liquidity, and regulatory soundness — showcases the maturity of tokenized capital markets and the power of reusing compliant, interoperable components.

Toward an Open, Composable Financial Ecosystem

This integration demonstrates how tokenization is not just a matter of digitizing financial instruments — it’s about creating open, programmable infrastructure where assets and institutions can interconnect seamlessly.

By building on an existing liquidity facility and extending it to new asset classes, HLSCOPE shows what composability truly means:

Each new product can benefit from the same foundational building blocks, without needing to rebuild the system from scratch.

As more funds and issuers adopt tokenized formats, these interoperable structures will enable a more efficient, transparent, and collaborative financial system — one where liquidity, compliance, and innovation can coexist.

The Future Is Composable

Tokenization’s greatest promise lies in its ability to connect — to make financial products interoperable, compliant, and accessible in real time.

With Hamilton Lane, VanEck, Ripple, and Securitize now operating together, we’re seeing the emergence of an open architecture for digital finance — one that doesn’t just replicate traditional models, but improves on them.

HLSCOPE’s integration with RLUSD liquidity is not a new product. It’s a proof of what tokenization enables when financial infrastructure becomes composable.

HLSCOPE Gains Instant RLUSD Liquidity by Composing with VBILL’s On-Chain Facility was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Securitize now supports our tokenized fund ACRED (Securitize Tokenized Apollo Diversified Credit Fund), on the SEI blockchain, expanding investor access to institutional-grade tokenized funds across another high-performance chain.

As with our other supported networks, Wormhole provides seamless cross-chain connectivity, allowing investors to move their fund tokens across ecosystems with ease.

But this launch brings more than just multi-chain expansion – it introduces a new level of operational automation with a brand-new use case: instant subscription with fund bridging.

Instant Subscription: The Current Model

ACRED already supports instant subscription on certain blockchains.

This process uses a smart contract that allows investors to send USDC and receive DS Tokens – the blockchain representation of their fund units – immediately in their wallet. The subscription is atomic, meaning the USDC and the newly minted DS Tokens are exchanged in a single onchain transaction.

Instant atomic subscriptions are part of the basic onchain infrastructure for RWAs that allows their interconnection with the DeFi world.

However, there’s a limitation:

For the instant subscription to work, the USDC must be directly custodied by the fund, and fund custodians in some cases may operate only on certain chains.

The New Capability: Fund Bridging at Subscription Time

With SEI (and other chains without direct fund support), we are enhancing our instant subscription smart contract to include an automatic USDC bridge step.

Here’s how it works:

1. Investor will send USDC on SEI. With Circle’s recent support for native USDC in SEI that is a natural option.
2. The contract mints the corresponding DS Tokens instantly to the investor’s wallet.
3. Simultaneously, the USDC is bridged via Wormhole to the fund’s custody wallet on a supported chain.

Wormhole support for this operation has been fundamental, as Circle’s Cross Chain Transfer Protocol – which is used for bridging USDC - in SEI only supports version 2 (CCTPv2). So to enable this new use case, Wormhole has added support for a fully onchain USDC bridge through CCTPv2 in their relayer.

Thanks to this, investors on SEI will enjoy the same instant subscription experience as on other chains – with the added benefit of behind-the-scenes operational efficiency that doesn’t require manual treasury movement.

Why This Matters

This is more than just a convenience upgrade. It’s an example of how tokenization, smart contracts, and cross-chain interoperability converge to make capital markets faster, leaner, and more global.

• Faster onboarding: Investors receive fund tokens instantly.
• Automated treasury flows: USDC is automatically routed to the custodied fund wallet, no manual steps.
• Multi-chain access: Seamless participation regardless of the blockchain an investor prefers.
• Programmable liquidity: The process is fully composable with other DeFi protocols, enabling onchain strategies around tokenized funds.

In other words, this is blockchain-native fund distribution done right – with the efficiency of DeFi mechanics and the trust of regulated securities.

What’s Next

This launch marks another step in our mission to make private markets as easy to access and as efficient to operate as public markets – without sacrificing regulatory compliance.

We will continue expanding instant subscription with fund bridging to more chains, bringing this capability wherever our investors are.

ACRED on SEI: Instant Subscription with Fund Bridging was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Securitize now enables instant RLUSD liquidity for our tokenized funds BUIDL, managed by BlackRock, and vBILL, managed by VanEck.

This new facility uses smart contracts to allow investors to swap fund tokens for RLUSD instantly – while preserving the regulated, compliant, and transparent structure that defines our platform.

How It Works

At its core, the process is simple:

An investor initiates an on-chain swap, exchanging their BUIDL or vBILL tokens for RLUSD.

But there’s a twist: we are now leveraging Securitize Markets – our registered broker-dealer – dealer capability to facilitate continuous liquidity in two-way flow that is at scale, efficient and actionable.

This means that each atomic swap is actually two back-to-back trades:

1. Investor ↔ Securitize Markets
2. Securitize Markets ↔ provider of stablecoin liquidity

On-Chain Transparency: Two Trades, One Transaction

The smart contract logic is designed so the on-chain record explicitly reflects these two steps.

From the blockchain’s perspective, there are two separate transfers: one between the investor and Securitize Markets, and another between Securitize Markets and the stablecoin provider.

This design ensures regulatory and operational clarity while still keeping the entire process fully automated and blockchain-native.

Built for Compliance, Powered by Blockchain

By structuring each swap as two distinct trades, we make it possible for:

• Our regulatory reporting systems to handle transactions cleanly.
• The process to remain compliant under broker-dealer oversight.
• Investors to enjoy instant settlement without sacrificing transparency.

And because it’s atomic, both trades succeed together – eliminating settlement risk – while RLUSD is ready to be used instantly across the DeFi ecosystem.

Moving Beyond Liquidity Barriers

Tokenized funds often face friction when connecting to stablecoin liquidity, especially in regulated environments.

This release demonstrates that it’s possible to connect institutional-grade products directly to blockchain-native liquidity without compromising compliance, auditability, or speed.

It’s another step toward making tokenized assets a first-class citizen in global capital markets, where moving between investments and liquid on-chain assets is instant, seamless, and interoperable.

Instant RLUSD Liquidity for BUIDL and vBILL was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years ago, I wrote about the idea of HyFi: connecting the regulated world of securities with the permissionless innovation of DeFi. Back then, the concepts felt ambitious — pooled asset ownership, compliance-aware transfer restrictions, and seamless interoperability between TradFi and DeFi rails (you can read the original posts here: pooled assets & ownership tracking, KYC and transfer controls).

Since then, at Securitize we’ve taken steps toward that vision. sTokens are one example: a way to bring RWAs into DeFi by wrapping them for compatibility. That allows permissionless interactions, but it still requires a layer of translation.

With the launch of Aave Horizon, we’ve crossed a threshold. For the first time, RWAs can be used natively as collateral inside a major DeFi protocol — no wrappers, no bridges, no workarounds. Just direct interoperability.

This is what HyFi was always meant to be.

Beyond Whitelisting

When people talk about integrating RWAs with DeFi, the discussion often stops at a simple idea: “RWAs are permissioned tokens, so just whitelist the pool or the vault, and you’re done.”

But anyone who has dealt with securities knows that isn’t enough. Regulatory obligations for an RWA issuer — or for their transfer agent and other intermediaries — go far beyond permissioning a wallet. Ownership must be tracked, investor rights must be enforced, lost-share processes must be possible, and compliance events must be managed.

It isn’t impossible — our integration with Aave Horizon proves that — but it requires more work and the right compliant infrastructure. What we’ve built is not just another whitelist, but an end-to-end system where regulation, ownership, and DeFi mechanics all line up.

What Horizon Brings

Horizon is a licensed, RWA-friendly deployment of the Aave protocol built by Aave Labs. It’s designed for institutional and qualified participants, forked from Aave v3.3, and tailored to meet the regulatory and compliance requirements of real-world assets.

Here are a few things that make it different from “standard” DeFi:

• Permissioned collateral: Only whitelisted participants can supply tokenized RWAs into the protocol.
• Non-transferable aTokens: When you deposit RWAs, you receive aTokens that cannot move. This ensures the collateral position stays consistent with the original supplier.
• Permissionless liquidity: Borrowing remains DeFi-native. Stablecoins like USDC or GHO can be supplied by anyone and borrowed by those who post RWA collateral.
• Built-in safeguards: The design includes issuer-managed edge cases — things like lost keys or sanctioned wallets — without breaking the collateral pool.

Put simply: Horizon brings RWA compliance into Aave while keeping DeFi liquidity open.

What Securitize Adapted

Supporting Horizon required us to make deep changes to the Securitize platform. We had to evolve our systems to treat a DeFi protocol itself as part of the compliance and ownership fabric.

Here’s what that looks like:

• Pool-as-wallet accounting

We track the Horizon pool as a special wallet/address. It doesn’t just belong to one investor — it holds positions for many, and our systems had to learn to account for that.

• Pro-rata ownership tracking

Thanks to Horizon’s non-transferable aTokens, we can reliably calculate each investor’s share of the pool. That ensures positions remain stable and consistent with reality.

• MSF (Master Securityholder File) integration

We extended our MSF to reflect on-chain Horizon positions. This means things like yield accrual or other rights associated with RWA tokens automatically account for collateral posted into Horizon.

• Portfolio inclusion

Horizon balances now appear directly in each investor’s portfolio. Not just as “positions,” but clearly marked as collateral in Horizon.

• Transfer agent processes

Regulatory obligations like handling lost shares or special recovery cases are supported without breaking pool operations. Horizon continues running smoothly, while compliance requirements are met.

Together, these changes make Horizon invisible to the investor — they just see their assets reflected in their portfolio, while the complexity of on-chain integration and regulatory handling happens behind the scenes.

Where the Magic Happens

The real innovation is at the convergence:

• Horizon adapts the protocol to be RWA-friendly.
• Securitize adapts the platform to track, service, and comply with those positions.

It’s at that intersection where we unlock something new: RWA-native DeFi that’s fully compliant, transparent, and scalable.

This isn’t just a proof-of-concept. It’s live, and it’s the first time RWAs have been able to sit inside a DeFi protocol in a way that both regulators and investors can trust.

Looking Ahead

This integration isn’t the finish line — it’s a foundation. By aligning protocol-level RWA awareness with platform-level compliance infrastructure, we’ve created a model that can scale to new assets, issuers, and protocols.

When I first wrote about HyFi, the vision was simple: bring regulated assets into permissionless systems without breaking either world. With Horizon and Securitize, that vision is no longer theoretical.

It’s here.

HyFi Meets Horizon: RWAs Go Native in DeFi was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.