How Securitize Uses Olympix in Its Smart Contract Pipeline

At Securitize, the smart contracts we write don’t just move tokens. They custody tokenized exposure to funds operated by BlackRock, Apollo, KKR, Hamilton Lane, BNY, and VanEck — more than $5 billion in tokenized assets under management. When the code is the capital, “we had it audited” is not a security posture. It’s one layer of one.

That’s why, since early 2026, every smart contract we work on goes through two mandatory review layers before it ships: an automated, continuous security review by Olympix, followed by a manual audit from reputable, top-tier firms. This post explains what Olympix does, why we chose it over the wave of “AI auditor” tools, and how it actually runs inside our development pipeline.

Audits are essential. They are also point-in-time.

Let’s be clear about what this is not: a replacement for human audits. We work with top-tier audit firms on every protocol release, and that isn’t changing. Experienced auditors find issues no tool can — protocol-specific logic flaws, economic design problems, incorrect assumptions about how contracts will be used.

But an audit is a snapshot. It reviews a commit hash, at a moment in time, over a bounded engagement. The codebase keeps evolving after the report is delivered. Industry data makes the limitation concrete: roughly 90 percent of exploited smart contracts had been audited at least once before the exploit.

The Balancer exploit in November 2025 is the canonical recent example. Over $116 million was drained through a precision rounding flaw in invariant calculations — in a protocol that had been reviewed by multiple elite audit firms and had on-chain monitoring in place. The vulnerability wasn’t a missing check that a reviewer skimmed past. It was an arithmetic interaction across the full codebase that only became visible when execution paths were exhaustively explored.

That class of bug is exactly what deterministic, machine-scale analysis is built to catch. So we added it as a permanent layer.

Why not just use an “AI auditor”?

Olympix is often described as an AI tool, and it does use AI — but that description undersells what made it the right fit for us, and it’s worth being precise, because we evaluated the broader “AI auditor” category and decided it wasn’t enough on its own.

Most AI audit tools are LLMs trained on public vulnerability data, pattern-matching against new code. They’re genuinely useful for catching known issues quickly. But they have two structural limitations for a platform like ours:

They can’t reliably find novel vulnerabilities. Pattern matching looks for what is already known. The most expensive exploits in this industry — Balancer’s rounding flaw, Cork Protocol’s hook-interaction bug — were new patterns with no training data behind them.

They’re probabilistic by design. A model that mostly catches vulnerabilities is the wrong shape of answer for capital that must always stay where it’s supposed to be. Probabilistic output also can’t anchor a CI/CD gate: you can’t block a merge on a finding that may not reproduce tomorrow.

Olympix takes a different approach. Underneath the AI-assisted tooling is a deterministic engine — proprietary static analysis, symbolic execution, fuzzing, mutation testing, and formal verification techniques — that runs across the entire codebase, not just diffs, and produces reproducible, measurable results. Same code in, same findings out. That’s what lets us turn security from an aspiration into an enforceable gate.

How it runs inside our pipeline

Four Olympix components are active in the Securitize development workflow today. Each one enforces a specific, measurable security metric.

1. Static analysis — blocking merges

Olympix’s static analyzer runs as code is written and on every pull request, flagging vulnerability patterns mapped to real-world exploit classes. The findings are deterministic and reproducible, with near-zero noise — which is what makes the next part possible: we can block merges on static analysis findings. A vulnerability introduced during development is surfaced and resolved before it ever enters the main branch, not months later in an audit report.

2. Automated unit test generation — enforced coverage

Olympix generates unit tests aligned to our internal standards, producing measurable line and branch coverage. We enforce a minimum branch coverage threshold across the codebase. Coverage stopped being a vague aspiration in a style guide; it’s a number the pipeline requires and verifies on every change.

3. Mutation testing — proving the tests actually work

High coverage can be a false comfort: tests can execute every branch and still assert nothing meaningful. Mutation testing solves this by deliberately injecting controlled faults into the code — flipped operators, altered constants, removed conditions — and checking whether the test suite catches them. Mutants that survive reveal tests that run but don’t protect. We enforce a minimum mutation score, which gives us evidence that our test suite is effective, not just present.

4. BugPOCer — the internal audit before the external audit

BugPOCer is the final internal validation layer before code goes to external auditors. It orchestrates the Olympix engine to traverse execution paths across the codebase, surface vulnerabilities, and — critically — automatically generate proof-of-concept exploits for what it finds. Findings arrive with provable exploitability, not theoretical risk. For us, BugPOCer has surfaced audit-level findings, and findings that prior audits had missed, each backed by a working PoC.

Then, and only then, the humans

When a release candidate reaches an external audit firm, it has already survived merge-blocking static analysis, enforced coverage and mutation thresholds, and a BugPOCer pass with exploit-level validation. That changes the economics of the audit itself.

Auditors don’t burn their engagement hours rediscovering issues automation could have caught. They spend their time where human expertise is irreplaceable: protocol logic, economic assumptions, compliance-specific flows — the areas where our DS Protocol contracts, with their registry, compliance, and trust-service architecture, genuinely need expert eyes. The result is a deeper audit of a cleaner codebase, with an evidence trail behind every metric we claim.

This is now the standing process for any smart contract we work on: Olympix review first, continuously, throughout development — then a manual audit by a reputable firm before deployment. Not one or the other. Both, in that order, every time.

Code becomes capital; correctness becomes non-negotiable

Traditional finance spent decades building deterministic, mathematically grounded methods for verifying financial systems — formal methods, exhaustive testing, provable invariants. Blockchain historically lacked access to those methods at production scale, because they required specialist consultants and couldn’t run continuously inside a development workflow.

That excuse is gone. The methods now run in CI/CD, on every commit, with enforceable thresholds and reproducible results. For a platform custodying institutional capital at our scale, adopting them wasn’t an innovation experiment. It was table stakes — the same standard our institutional partners already expect in every other part of their stack, finally applied to the contracts themselves.

Vulnerabilities are introduced, detected, fixed, and re-verified inside the pipeline, with an evidence trail at every step — before a human auditor ever opens the repo. That’s what security looks like when the code is the custodian.

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.

Finding Vulnerabilities Before the Auditors Do was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post was written jointly by Kasper Pawlowski (CTO Euler Labs), Adan Carreno (Blockchain PM Securitize) & Jorge Serna (C3PO Securitize)

A Deep Dive into Euler’s DS Protocol–Native Vault Architecture

DeFi lending protocols assume a simple model: ERC-20 tokens can move freely between addresses. But regulated digital securities cannot.

Securities tokens must enforce regulatory constraints including KYC/AML eligibility, accreditation requirements, jurisdiction restrictions, and issuer-controlled regulatory actions (freeze, seize, etc.).

In the DS Protocol, these constraints are enforced through the Compliance Service, which validates transfers before they occur.

The challenge for DeFi protocols is therefore architectural: how can lending systems preserve DeFi’s composable borrowing and collateral mechanics while ensuring every token movement remains compliant?

Euler’s integration with the DS Protocol provides one concrete answer. Instead of weakening DeFi primitives or bypassing compliance rules, Euler implemented a DS-aware vault architecture that validates token transfers against the DS Compliance Service before executing lending operations.

This article explores the technical design behind that integration.

The DS Protocol Compliance Model

Digital securities issued through the DS Protocol rely on an on-chain compliance validation mechanism. Before a token transfer occurs, the protocol evaluates the operation using:

function preTransferCheck(
    address token,
    address from,
    address to,
    uint256 amount
) external view returns (bool allowed);

The Compliance Service determines whether the transfer is permitted based on investor eligibility, issuer-defined restrictions, regulatory obligations, and token state (frozen accounts, regulatory holds, etc.).

If the check fails, the transfer must not occur.

Unlike traditional transfer restriction systems embedded directly inside token contracts, the DS Protocol separates token mechanics from compliance evaluation, enabling other smart contracts to validate transfers before executing them.

This design is critical for DeFi integrations. A lending protocol cannot blindly move DS tokens. Instead, it must validate token movements before every operation that results in a transfer.

Euler’s Modular Lending Architecture

Euler V2 is built around the Euler Vault Kit (EVK). Vaults follow an extended ERC-4626 architecture, where deposits produce vault shares, shares represent claims on pooled assets, and vaults support borrowing and collateralization.

A simplified vault deposit flow looks like:

function deposit(uint256 assets, address receiver)
    public
    returns (uint256 shares)
{
    shares = previewDeposit(assets);
    asset.transferFrom(msg.sender, address(this), assets);
    _mint(receiver, shares);
}

This flow assumes that transferFrom is always valid. For DS tokens, that assumption does not hold. A deposit must first confirm that the transfer is compliant. Therefore, Euler introduced a DS-specific vault implementation.

The DS-Aware Vault

Euler implemented a specialized vault for DS tokens within the Euler Vault Kit ecosystem. The vault integrates compliance validation directly into token movement paths.

Conceptually:

function _validateTransfer(
    address from,
    address to,
    uint256 amount
) internal view {
    bool allowed = complianceService.preTransferCheck(
        address(asset),
        from,
        to,
        amount
    );
    require(allowed, "DS: transfer not compliant");
}

Every vault operation that moves DS tokens calls this validation step.

In practice, the DSToken itself will revert non-compliant transfers — but the vault’s explicit preTransferCheck call becomes critical in scenarios where compliance must be evaluated before token custody changes hands outside of a direct transfer, such as collateral seizure and liquidation.

Deposit Flow with Compliance Enforcement

The deposit operation becomes:

function deposit(uint256 assets, address receiver)
    public
    returns (uint256 shares)
{
    _validateTransfer(msg.sender, address(this), assets);
    shares = previewDeposit(assets);
    asset.transferFrom(msg.sender, address(this), assets);
    _mint(receiver, shares);
}

The vault ensures that the sender is eligible, the vault is a valid recipient, and the transfer respects compliance rules. Only then is the transfer executed.

Borrowing and Collateral Mechanics

Borrowing itself does not move DS tokens. However, withdrawals and liquidations do. Therefore, the vault must validate transfers during withdrawals, liquidation settlement, and collateral movement.

Example withdrawal logic:

function withdraw(
    uint256 assets,
    address receiver,
    address owner
) public returns (uint256 shares) {
    shares = previewWithdraw(assets);
    _validateTransfer(address(this), receiver, assets);
    _burn(owner, shares);
    asset.transfer(receiver, assets);
}

Again, compliance validation precedes the transfer.

Liquidation Path

Liquidations present the most critical compliance scenario. Unlike standard deposits and withdrawals — where the DSToken’s own transfer restrictions would catch non-compliant movements — liquidation involves custody changes that require proactive compliance validation before the operation is initiated.

During liquidation, a borrower’s collateral is seized and transferred to the liquidator, and the borrower’s debt record is transferred to the liquidator in exchange. The liquidator assumes the debt position rather than settling it. If the collateral asset is a DS token, the transfer of that collateral must pass compliance checks before the operation proceeds.

function liquidate(
    address borrower,
    uint256 collateralAmount
) external {
    address liquidator = msg.sender;
    _validateTransfer(
        borrower,
        liquidator,
        collateralAmount
    );
    // Seize collateral and transfer debt record to liquidator
    _seizeCollateral(borrower, liquidator, collateralAmount);
    _transferDebt(borrower, liquidator);
}

This guarantees that a liquidator receiving DS collateral is an eligible holder under the compliance rules, and that the corresponding debt obligation moves atomically alongside the collateral.

Freeze and Seizure Compatibility

The DS Protocol allows issuers to perform regulatory actions such as freezing addresses and seizing tokens. These actions must propagate safely through the vault.

The vault maintains its own internal freeze flag, separate from the DS Protocol’s freeze state. In a sanctions scenario, the Transfer Agent will trigger both — freezing the address at the DSToken level and setting the freeze flag within the vault. This dual-layer approach ensures that regulatory actions are enforced across both the token and the lending infrastructure independently.

When an account is frozen at the vault level, deposits and withdrawals are disallowed regardless of the preTransferCheck result, and frozen collateral cannot be seized in a liquidation.

For seizure operations involving collateral that is actively supporting debt, the debt associated with that collateral must be moved to the destination account alongside the collateral itself. This is enforced at the EVC level, ensuring that collateral and its associated debt obligations travel together and that the protocol’s solvency invariants are preserved.

For standard operations, the DSToken itself enforces compliance — non-compliant transfers simply revert. The vault’s explicit preTransferCheck and internal freeze logic serve as the primary safeguards in liquidation and seizure paths, where the token's own transfer logic alone is insufficient.

Share Transfer Restrictions

Vault shares issued by the DS vault carry transfer restrictions that go beyond standard ERC-4626 behaviour.

Share transfers between accounts with different Ultimate Beneficial Owners (UBOs) are disallowed. Transfers are only permitted between Euler sub-accounts belonging to the same owner — that is, accounts derived from the same owner address under the EVC’s sub-account model. This ensures that economic exposure to DS token positions cannot be transferred to a party that has not been validated under the applicable compliance rules.

The one exception is liquidation flows, where share or collateral movements to a liquidator are permitted subject to the preTransferCheck passing for the liquidator as recipient.

Additionally, share transfers respect the vault’s internal freeze status. A frozen account cannot send or receive vault shares, regardless of whether the underlying DS token transfer would pass the Compliance Service check.

Integrators should not assume that vault shares behave as freely transferable ERC-20 tokens.

Sequence Diagrams

Deposit

User
 │
 │ deposit(assets)
 ▼
Euler DS Vault
 │
 │ check internal freeze flag
 │ preTransferCheck(from=user, to=vault)
 ▼
Compliance Service
 │
 │ return allowed
 ▼
Euler DS Vault
 │
 │ transferFrom(user → vault)
 │ mint shares
 ▼
User receives vault shares

Withdrawal

User
 │
 │ withdraw(assets)
 ▼
Euler DS Vault
 │
 │ check internal freeze flag
 │ preTransferCheck(from=vault, to=user)
 ▼
Compliance Service
 │
 │ return allowed
 ▼
Euler DS Vault
 │
 │ burn shares
 │ transfer(vault → user)
 ▼
User receives assets

Liquidation

Liquidator
 │
 │ liquidate(borrower)
 ▼
Euler DS Vault
 │
 │ check borrower freeze flag
 │ preTransferCheck(borrower → liquidator)
 ▼
Compliance Service
 │
 │ return allowed
 ▼
Euler DS Vault / EVC
 │
 │ seize collateral → transfer to liquidator
 │ transfer debt record → liquidator
 ▼
Liquidator receives collateral and assumes debt position

Architectural Separation

The resulting architecture separates responsibilities across layers:

Layer Responsibility DS Token asset representation Compliance Service transfer eligibility DS Vault lending mechanics, internal freeze enforcement Euler EVK vault framework EVC cross-vault collateralization, debt-collateral seizure atomicity

The vault does not attempt to implement compliance logic itself. Instead, it delegates transfer validation to the DS Protocol, while maintaining its own freeze state for lending-layer enforcement.

Why This Approach Preserves DeFi Composability

The integration avoids modifying the DS token itself. Instead, vaults perform compliance checks, transfers remain standard ERC-20 calls, and core lending mechanics remain decentralized.

This means DS tokens can participate in DeFi lending without breaking standard DeFi assumptions at the protocol level. Other protocols interacting with the vault still see ERC-4626 shares, ERC-20 tokens, and standard vault mechanics.

However, integrators should be aware that vault shares carry transfer restrictions beyond standard ERC-4626 behaviour — share transferability is limited to sub-accounts of the same owner and is subject to freeze status. These constraints are a necessary consequence of the compliance model.

Compliance enforcement happens at the transfer boundary — reinforced by the DSToken itself for standard transfers, and by the vault’s explicit validation and freeze logic for liquidation and seizure paths where built-in token protection alone is insufficient.

A Pattern for Regulated Assets in DeFi

This integration establishes a reusable architecture. Any protocol that integrates DS tokens should:

• Identify every token transfer path
• Perform preTransferCheck before executing transfers
• Revert if the transfer is not compliant
• Maintain a lending-layer freeze mechanism independent of the token-level freeze

Because the DS Protocol is open-source under Apache 2, issuers can implement tokenized securities using the same compliance primitives. Those assets can then integrate with DeFi systems using similar patterns.

Toward Institutional DeFi Lending

As tokenized securities become more common, they will increasingly interact with decentralized credit markets. But institutional assets cannot ignore regulatory constraints.

The Euler DS vault architecture demonstrates that compliance can remain enforceable, lending mechanics can remain decentralized, and tokenized securities can function as DeFi collateral — without introducing centralized gatekeepers into the protocol itself.

The result is a system where regulated assets and decentralized credit markets can coexist within the same on-chain infrastructure.

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.

Integrating Regulated Digital Securities into Euler Lending Infrastructure was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bringing Securitize’s DSTokens into DeFi requires more than a smart contract. It requires a developer environment where partners can learn, test, and validate the full integration before writing a single line of production code. Today we’re launching our Vault Registrar Sandbox to help our partners move faster.

A Quick Recap

In our previous post, we covered the key refinements to the VaultRegistrar: explicit EIP-712 signed authorizations, the Ethereum Magicians standardization proposal, and multichain expansion. If you haven’t read it, the short version is this: DeFi protocols that want to hold DS Token — Securitize’s permissioned ERC-20 for tokenized real-world assets — need to register each investor’s vault with the VaultRegistrar before any token transfer can occur. The registration is gated by a cryptographic signature from the investor, ensuring that custody always maps back to a verified identity and it is done following investors instructions.

That mechanism works. What was missing was a frictionless path for a new partner to understand it, try it, and feel confident enough to build on it. That’s what we built.

What Is the Vault Registrar Sandbox?

The Vault Registrar Sandbox is an open-access developer environment on Ethereum Sepolia. No sign-up, no API keys, no Securitize account required. Any developer can visit the site, connect a wallet, and run the full DS Token integration lifecycle in minutes.

It ships four tools:

The Faucet distributes testnet DS Tokens to any wallet. The first time you request tokens, your wallet is automatically registered as an investor in the DS Protocol — a prerequisite for any investor to hold DS Tokens. This removes the biggest onboarding blocker for new partners: you no longer need Securitize to pre-whitelist a wallet to start testing.

Register as Operator lets you add any protocol contract address to the VaultRegistrar’s operator registry directly from your browser. On testnet, this is permissionless — one transaction, no admin approval. In production, Securitize controls who can be an operator; on the sandbox, you can be one in seconds. This matters because the operator is the entity that calls registerVault() on behalf of investors, and it must hold OPERATOR_ROLE before any vault can be onboarded.

Mock Protocol Example simulates the investor-side experience of a real DeFi integration. It walks through the complete three-step flow: sign the EIP-712 permission, approve the DS Token contract to allow the transfer, and deposit into the vault. Behind the scenes, this is calling a deployed MockDeFiProtocol contract that calls VaultRegistrar.registerVault() internally — the same pattern your production protocol will use. Investors can also revoke their permission at any time from the same page, invalidating any future vault registrations under that authorization.

Protocol Tester is where it gets interesting for protocol developers. Upload any contract ABI, select a function, fill in the parameters, optionally sign the EIP-712 RegisterVault typed data, and execute — all directly against a deployed contract on Sepolia. No scripts, no local environment, no private key management. It’s a live Web3 testbed. Amount fields are automatically converted to the correct decimal representation, the signature is auto-filled once you sign, and a DS Token approve step is injected when the method moves tokens. A developer with a freshly deployed protocol contract can validate the end-to-end flow without writing a single line of off-chain code.

Why This Design

The VaultRegistrar is a compliance bridge, not a DeFi primitive. Its job is to link a vault address to an investor identity so that DS Token transfers into that vault are permitted by the token’s compliance layer. Everything else — how the vault is structured, what strategy it runs, how the protocol manages positions — is the integrator’s business.

This means the learning curve for a new partner is primarily conceptual, not technical. The hard questions are: What does it mean for a vault to be “registered”? Who is the operator and what is its address in the EIP-712 message? What order do the steps need to happen in?

The sandbox answers all of these questions experientially. You see the VaultRegistered event fire on Etherscan. You see the token transfer fail if you try to skip the registration step. You see the “Already registered” state update on the page. It’s a lot more effective than a diagram.

The Operator: Your Protocol Contract

The EIP-712 message that investors sign contains an operator field. That operator must be the exact msg.sender of the registerVault() call on-chain — if they don’t match, the signature is invalid.

In practice this means: your protocol contract — the factory or entrypoint that calls registerVault() — is the operator. Not the deployer EOA. Not a backend wallet. The contract itself sends the transaction, so the contract is the address that needs OPERATOR_ROLE.

The Register as Operator page makes this concrete. You enter your protocol contract address, click submit, and the transaction writes OPERATOR_ROLE to that address on-chain. The page then confirms isOperator(yourAddress) == true. From that point on, investor signatures that name that contract as operator will be accepted by the VaultRegistrar.

The Documentation

We built a full documentation site alongside the sandbox. It covers:

- A 5-minute sandbox walkthrough using just a browser and a wallet — no code required

- A 7-step integration guide for protocol teams going from testnet tokens to a registered vault with funds in custody

- A complete API reference for the VaultRegistrar contract: every function, event, and error, with selectors, causes, and recovery steps

- A full EIP-712 reference with worked examples in viem, ethers, and wagmi, including a step-by-step digest computation

- Reference implementations: a MinimalVaultFactory in Solidity with a Hardhat deploy task, a TypeScript deposit flow script, and documentation of the MockDeFiProtocol contract as a production-shaped example

The documentation deliberately separates two audiences. Partners who want to validate the flow before committing to an implementation can follow the sandbox-first path — no Hardhat, no scripts, just the UI. Partners who are ready to build get Solidity contracts, TypeScript examples, and Hardhat tasks they can drop directly into their project.

What Comes Next

The sandbox is live on Ethereum Sepolia. Additional chains — Arbitrum Sepolia, Optimism Sepolia, Avalanche Fuji — are in the pipeline.

The IVaultRegistrar interface at the heart of this system remains an active proposal on Ethereum Magicians. We believe a standardized vault authorization interface, designed from the start for compliance-aware DeFi, is worth pursuing as an ERC. The more protocols that implement against it — and the feedback we collect from those integrations — the stronger that proposal becomes.

If you’re building a DeFi protocol and want to support tokenized real-world assets, the sandbox is where to start. Connect a wallet, get tokens, register your contract, and run the flow. It takes five minutes to go from nothing to a vault registration on-chain.

The Vault Registrar Sandbox is part of Securitize’s DS Protocol testnet infrastructure. The `IVaultRegistrar` interface is under active standardization — see the discussion at Ethereum Magicians

— —

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.

Building for DeFi Integration: The Vault Registrar Sandbox was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Extending the next generation of RWA-DeFi integration with EIP-712 permissions, standardized vault interfaces, and Solana support

Earlier this year we introduced Vault Registrar, a mechanism designed to allow DeFi protocols to interact with regulated RWA tokens without breaking the compliance guarantees that those assets require.

The original post described two key capabilities:

• Smart escrow vaults controlled by protocols but operating under an investor’s compliance identity.
• One-click looping flows, where a vault can interact with lending or collateral protocols without requiring investors to manually whitelist each intermediate address.

Since that announcement, we have been working with protocol partners on real integrations. That work has led to several important refinements to the model.

In this post we cover three major updates:

• An improved authorization model based on EIP-712 signed permissions
• Updates to the standardization proposal being discussed on Ethereum Magicians
• A new Vault Registrar implementation for Solana

The core philosophy remains unchanged: regulated RWA tokens should be able to interact with DeFi protocols while preserving compliance guarantees tied to investor identity. What has evolved is how those permissions are expressed and managed.

1. Explicit Vault Authorization via EIP-712

In the original Vault Registrar model, the registrar contract performed vault whitelisting under an investor’s identity when a protocol created a vault on behalf of the user.

While this model worked, early integrations highlighted an important improvement: authorization should be explicitly granted by the investor and remain revocable.

To achieve this, the Vault Registrar now relies on EIP-712 signed authorization messages. Instead of implicitly allowing protocols to register vaults, the investor signs a structured message authorizing a specific protocol to register vaults under their identity.

The authorization message typically includes:

• Investor address
• Protocol / operator address
• Token or asset scope
• Vault registrar address
• Optional limits or metadata (e.g., expiration)

This approach provides several important advantages.

Clear user consent. The authorization message makes the permission explicit and user-visible. Investors are no longer implicitly trusting protocol flows — they are cryptographically authorizing vault creation.

Revocable permissions. Because the authorization is represented as a signed permission, investors can revoke it at any time by invalidating the message. This aligns the model with familiar wallet-based permission patterns.

Protocol lifecycle flexibility. Many real integrations involve collateral management strategies where new vaults may need to be created over time — for example, collateral rebalancing, leverage loops, liquidation protection, or strategy upgrades. The signed authorization allows those vaults to be created without requiring the investor to manually re-authorize every step.

The Vault Registrar therefore becomes a policy-enforcing registry, verifying that the operator is authorized, that a valid investor permission exists, and that compliance rules are satisfied — before registering the vault under the investor’s identity.

2. Standardizing Vault Permissions (Ethereum Magicians Proposal)

As adoption grows, it becomes important that this pattern is not implemented in an ad-hoc way by every protocol.

For this reason, we proposed a standard interface on Ethereum Magicians: https://ethereum-magicians.org/t/erc-proposal-vault-registrar-interface-for-permissioned-erc-20-vaults/27627

The proposal is evolving to reflect the improvements described above. The new version introduces:

Authorization-based vault registration. Vault authorization is now based on signed permissions rather than implicit protocol trust. This standardizes how protocols request authorization and how token contracts verify it.

A generalized vault authorization interface. Instead of focusing only on whitelisting vaults, the proposal now describes a more general interface for permissioned vault registration — making the model compatible with regulated ERC-20 tokens, permissioned vault protocols, collateral and lending systems, and looping strategies.

Protocol interoperability. Standardizing this interface allows DeFi protocols to support regulated tokens without bespoke integrations. If multiple token issuers adopt the same interface, protocols can build once and support many regulated assets.

If you are building regulated token infrastructure or DeFi protocols that interact with RWAs, we encourage you to participate in the discussion. Standardization is essential if RWAs are going to become first-class citizens in DeFi.

3. Introducing Vault Registrar for Solana

While the original Vault Registrar was designed around Ethereum smart contracts, the underlying idea is chain-agnostic: a protocol vault can operate under an investor’s compliance identity.

To enable this for Solana-based RWAs, we implemented a Vault Registrar Solana program. The philosophy remains the same, but the implementation differs due to Solana’s architecture.

Program Overview

The Vault Registrar is a Solana program that enables compliant vault registration under an investor’s identity, using the DS Token identity registry as the source of truth. The program is intentionally minimal — non-custodial, deterministic (PDA-based), and compliance-gated. It performs no token transfers or custody. It simply registers vault wallets under the investor identity when certain conditions are satisfied.

High-Level Flow

1. A user initiates a deposit into a protocol.
2. The protocol deploys or references a vault wallet for that user.
3. The protocol (acting as an Operator) calls register_vault.
4. The Vault Registrar performs a CPI chain to validate compliance and verify user intent, leveraging Solana’s transaction model to confirm that the investor is the original transaction initiator.
5. If all checks pass, the vault wallet is attached to the investor’s identity, enabling it to receive or interact with regulated tokens that require identity verification.

The CPI chain is: VaultRegistrar → rwa-rbac → Identity Registry → System Program

Role Model

Operators are protocol contracts or services allowed to register vaults — for example, vault deployment systems, leverage protocols, or collateral management engines. Operators must be explicitly permissioned in the Vault Registrar.

The Vault Registrar program must also be granted the Exchange role in the DS Token, which allows it to perform identity compliance checks and register vault wallets under investor identities. Importantly, the program does not replicate token compliance logic — it relies on the DS Token’s registry as the source of truth.

TypeScript SDK

To simplify integrations, we provide an SDK:

npm install @vault-registrar/sdk

Initialize the registrar with:

import { VaultRegistrarClient } from "@vault-registrar/sdk";

const client = await VaultRegistrarClient.from(
  vaultRegistrarState,
  provider
);

The high-level vault registration call:

const txSig = await client.registerVault({
  vaultWallet: vaultPublicKey,
  vaultKp: callerKeypair,
  existingInvestorWallet: investorPubkey,
  existingInvestorWalletIdentity: investorIdentity,
  investorKp: investorKeypair,
});

The SDK resolves all required PDAs and dependencies automatically. For teams that prefer full control, instructions can also be built manually using the lower-level helpers exposed by the SDK.

A Multichain Future for Regulated RWAs

With these updates, Vault Registrar now supports two complementary models:

Network Authorization Model Ethereum / EVM EIP-712 signed vault authorization Solana Transaction signer verification + CPI identity attachment

Despite the implementation differences, the goal is the same: allow protocols to create vaults that act on behalf of an investor while preserving compliance guarantees.

As RWAs continue to expand across ecosystems, multichain support becomes essential. Vault Registrar provides a composable primitive that protocols can use to safely integrate regulated tokens into DeFi workflows.

What’s Next

Our current focus is on three areas:

• Advancing the vault authorization standard on Ethereum Magicians
• Expanding protocol integrations
• Extending Vault Registrar support to additional chains

If you are building lending protocols, leverage systems, collateral management frameworks, or structured products and want to integrate regulated RWAs — we would love to collaborate.

Vault Registrar is designed to make compliance-aware DeFi integrations possible, without sacrificing composability.

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, Revisited: Explicit Authorizations, Standardization, and Multichain Support was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

As real-world assets (RWAs) move onchain, one challenge consistently surfaces: how do users move capital in and out of tokenized securities in a frictionless, compliant, and transparent way?

On and off ramps are not peripheral infrastructure — they are foundational primitives for adoption. Issuers need efficient subscription and redemption flows, while investors expect predictable pricing, instant settlement, and strong protections.

At Securitize, these flows are implemented as DSApps within the DS Protocol. Rather than changing the DSToken itself, DSApps extend its capabilities through composable smart contracts that are explicitly permissioned to perform specific actions. This article explains how our On and Off Ramp DSApps work today, and how they connect to already-launched initiatives such as BlackRock’s BUIDL & VanEck’s VBILL RLUSD liquidity and HLSCOPE’s -RLUSD flows, as well as cross-chain USDC bridging from SEI.

Why DSApps?

DSTokens are designed to be minimal, secure, and regulation-aware. Instead of continuously expanding the token’s surface area, the DS Protocol introduces DSApps: purpose-built contracts that receive narrowly scoped permissions from the token.

This model allows us to:

• Add new functionality without redeploying or upgrading the DSToken
• Isolate risk by limiting permissions to specific operations
• Evolve market infrastructure (subscriptions, redemptions, lending, bridging) independently

On and Off Ramps are prime examples of this philosophy in action.

On-Ramp DSApp: Subscribing to DSTokens

The On-Ramp DSApp provides a standardized way for investors to acquire DSTokens using stablecoins, with protections and controls that go beyond simple swap contracts.

Why a Dedicated On-Ramp?

Earlier subscription flows relied on fragmented swap logic that was harder to secure, extend, and regulate. The new On-Ramp consolidates these flows into a single, auditable contract that issuers and dealers can configure per offering.

Operating Modes

The On-Ramp supports multiple subscription models:

• Primary Offering Mode
  Tokens are minted on demand by the issuer when an investor subscribes. This is commonly used during primary issuance.
• Secondary Mode
  Pre-minted DSTokens are swapped from a dealer’s inventory in exchange for stablecoins, enabling secondary market liquidity.

Core Capabilities

Key features include:

• NAV-based pricing using RedStone oracles
• Stablecoin subscriptions with explicit slippage controls
• Dynamic fee handling via a dedicated FeeManager contract
• Allowance-based swaps for secondary market flows
• Automatic USDC bridging when liquidity originates on another chain. When USDC is used as the subscription asset, the On-Ramp DSApp can automatically bridge the received USDC across chains via integrations with Wormhole and Circle’s CCTPv2, abstracting cross-chain complexity away from the investor.
• Onchain minimums for buy operations
• Configurable controls to enable or disable headless swap modes

Developers interact with the On-Ramp through a simplified interface that replaces older buy/swap patterns. Both methods take a stablecoin (liquidity) amount as input and allow specifying the slippage by supplying the minimum amount of assets / stablecoins that is acceptable to receive.

// Subscribe using a stablecoin amount (Web3 subscription flow)
function subscribe(...investorData, uint256 liquidityAmount, uint256 minOutputAmount);

// Swap using a stablecoin amount (headless flow)
function swap(uint256 liquidityAmount, uint256 minOut);

While both functions ultimately acquire DSTokens, they serve distinct regulatory and UX purposes:

subscribe — Web3 subscription mode
This method is designed for first-time investors. It integrates with Securitize’s investor platform, which generates a pre-approved transaction containing the required investor data. The On-Ramp smart contract verifies this payload onchain and performs:

• Investor registration
• Wallet whitelisting
• Compliant subscription execution, which includes minting the requested amount of tokens.

This enables a fully onchain subscription flow while preserving the necessary compliance checks.

swap — Headless execution mode
This method can operate without platform interaction, but requires the destination wallet to already be whitelisted. It is optimized for repeat purchases, secondary market flows, and programmatic integrations where compliance has already been established. It is directly available to interact and compose onchain without an associated web3 session.

Together, these modes allow the same DSApp to support both regulated onboarding flows and low-friction, composable DeFi-style execution paths, without compromising security or compliance.

Off-Ramp DSApp: Redeeming DSTokens

Access to liquidity does not end at subscription. Investors also need a compliant, predictable way to exit positions.

The Off-Ramp DSApp addresses this by unifying redemption logic that was previously scattered across different contracts and operational flows.

Why a New Off-Ramp Model?

Earlier redemption mechanisms often required manual processing, separate redemption wallets, or lacked consistent pricing and fee logic. The new Off-Ramp consolidates these into a single composable contract model

Core Capabilities

The Off-Ramp supports:

• Direct redemption with optional burn
  DSTokens can be redeemed directly, with the option to automatically burn tokens — no separate redemption wallet required in that case
• Composable liquidation flows
  Liquidable DSTokens can be converted to cash equivalents via external redemption contracts, configurable per use case.
• Dynamic fee models
  Fees can be fixed, tiered, or dynamic (e.g., spreads over NAV depending on liquidity conditions).
• Country-based restrictions
  Stablecoin-specific jurisdictional rules are enforced at the redemption layer, even when they differ from the DSToken’s own restrictions.
• Slippage controls
  Every redemption enforces explicit execution bounds.
• Peer-to-peer or dealer redemptions
  Investors can sell units back to a dealer or to other approved investors, enabling secondary redemption markets.

Connecting the Dots: RLUSD, HLSCOPE, and SEI Bridging

These DSApps are already powering live production initiatives across the ecosystem — reinforcing that this architecture is not theoretical, but actively in use.

• RLUSD liquidity for BUIDL & VBILL
  With the launch of RLUSD as a liquidity option for BlackRock’s BUIDL and VanEck’s VBILL tokenized funds, the On and Off-Ramp DSApps became a critical execution layer. RLUSD acts as the liquidity asset, while the DSApps enforce NAV-based pricing, permissions, and redemption rules — all without modifying the underlying DSToken contracts.

→ Read more: https://securitize.io/learn/press/Ripple-and-Securitize-Enable-RLUSD-Smart-Contract-Functionality-for-BlackRocks-BUIDL-and-VanEcks-VBILL-Tokenized-Funds

• HLSCOPE and RLUSD via VBILL’s onchain facility
  HLSCOPE’s integration goes a step further. Instead of sourcing RLUSD directly, HLSCOPE uses VBILL’s onchain off-ramp facility as the path to liquidity. This demonstrates how an external liquidity provider can be composed into the DS Protocol: a DSApp is permissioned to interact with another product’s liquidity infrastructure, enabling compliant access to RLUSD through an already-approved route.

This pattern is especially powerful because it shows how DSApps can reuse onchain existing facilities, rather than requiring each product to bootstrap isolated liquidity pools.

→ Read more: https://securitize.io/learn/press/SCOPE-Gains-Instant-RLUSD-Liquidity-by-integrating-with-VBILLs-Onchain-Facility

• SEI as an entry chain, Ethereum as a settlement chain
  Some deployments allow investors to subscribe on SEI, where local distribution or liquidity exists, and have the resulting USDC automatically bridged to Ethereum as part of the On-Ramp execution flow.
• This is a USDC-specific path, enabled through integrations with Wormhole and Circle’s CCTPv2, and invoked only when USDC is the selected liquidity asset. The DSApp orchestrates this process end-to-end, ensuring that cross-chain movement is compliant, atomic from the investor’s perspective, and fully onchain.
• This capability allows issuers to accept capital on one chain while consolidating settlement and liquidity on another — without requiring operators to manually bridge funds which makes the whole process more scalable

→ Read more: https://securitize.io/learn/press/Securitize-Expands-Tokenized-Funds-to-the-Sei-Network-with-ACRED-as-First-Tokenized-Offering

None of these flows required changes to the DSToken standard itself. Instead, each capability was unlocked by granting narrowly scoped permissions to new DSApps — exactly as intended by the DS Protocol.

Conclusion

On and Off Ramps are not just user experience features; they are protocol-level extensions that demonstrate the power of the DSApp model.

By decoupling token logic from market infrastructure, the DS Protocol allows digital securities to evolve safely over time — adding new subscription methods, redemption paths, and cross-chain capabilities without sacrificing security or compliance.

As more DSApps are deployed, DSTokens become more capable — not by changing what they are, but by expanding what they can do and giving more utility to investors.

This article is for informational purposes only and does not constitute an offer to sell or a solicitation of an offer to buy any security.

On and Off Ramps as DSApps: Expanding DSToken Capabilities was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Since the release of the DS Protocol reference implementation, our goal has been to simplify the lifecycle of regulated securities on-chain as well as adding utility and flexibility to token holders. With adoption growing and real-world assets increasingly tokenized, we’ve continued to evolve the protocol to meet new requirements.

This evolution has led to the launch of DSToken v4, the next major version of the DS Protocol. V4 incorporates significant enhancements that strengthen compliance, improve operational efficiency, and expand the protocol’s utility across new use cases.

In this article, we introduce the latest important updates in DSToken v4:

• New protocol roles for more granular governance.
• Rebasing capability for yield distribution and balance adjustments.
• Self-service whitelisting of wallets.

These features enhance automation, improve investor experience, and reduce operational overhead — while maintaining strict compliance and regulatory alignment.

Protocol Roles Update

The DS Protocol was designed with a strong role-based permission model from the start. Roles such as Master, Issuer, and Exchange ensured that only authorized actors could perform sensitive actions like minting, burning, or registering investors.

As adoption grew, however, we identified the need for more granular separation of duties. In regulated environments, the same entity that issues tokens should not necessarily be responsible for setting compliance rules. This is where our new Transfer Agent role comes in.

The Transfer Agent Role

The Transfer Agent is a newly introduced role dedicated to compliance management and asset-level configuration.

• Core responsibility: Define, set, and update the compliance rules that govern token transfers and investor eligibility.
• Special functions: Manage other compliance-related parameters and operational controls — including the ability to freeze or unfreeze the token when required by regulatory or operational circumstances.

This clearly separates the authority to issue or burn securities (held by the Issuer) from the authority to configure and enforce compliance at the token level (held by the Transfer Agent).

This separation of duties mirrors traditional securities operations, where transfer agents maintain investor records and ensure compliance, while issuers focus on the creation and distribution of securities.

Operational Safeguards with MPC Wallets

The DS Protocol does not enforce any specific security solution — any EOA or contract wallet can hold protocol roles. However, given the sensitivity of certain operations, it is strongly advisable to use secure wallet infrastructures such as MultiSig or MPC-based solutions.

At Securitize, we implement this through Fireblocks MPC (multi-party computation) wallets to manage protocol roles. By combining the DS Protocol’s role framework with Fireblocks’ MPC structure:

• Segregation of duties is enforced at the wallet level — different teams can be assigned distinct roles (e.g., Issuer, Transfer Agent, Master).
• Operational security improves, as no single party can unilaterally execute sensitive functions.
• Regulatory alignment is reinforced, ensuring that the right teams hold the right responsibilities.

Rebasing in DS Tokens

Why Rebasing?

Traditionally, securities that generate yield or dividends have relied on manual issuance of new tokens, often following a process known as Dividend Reinvestment Plans (DRIPs). In this model, accrued interest or dividends are periodically calculated and then distributed by minting new tokens into investor wallets. While functional, this approach is operationally heavy, expensive in gas (since every wallet must receive a transfer), and limited to discrete intervals. Even with bulk operations, it remains a significant hurdle for issuers and operations teams.

Rebasing offers a more elegant and efficient alternative. Instead of distributing new tokens, balances adjust dynamically based on a multiplier, without requiring explicit transfers. This means investor balances update in real time, automatically reflecting growth or adjustments.

Beyond dividends, rebasing is also valuable for corporate actions such as stock splits or reverse splits. In these cases, the multiplier can instantly scale all balances up or down, ensuring consistency across the system without the need for costly, large-scale token reissuances.

The effective balance of an investor becomes:

balance = shares * multiplier

Where:

• shares = the base number of tokens held.
• multiplier = an external value reflecting yield, interest, or other growth logic.

All investors’ balances update simultaneously, reducing complexity and ensuring real-time accuracy.

How It Works

We introduced a new RebasingProvider contract, which exposes the current multiplier. The provider can be updated by an operator with ISSUER or MASTER roles, or implemented with custom formulas which would provide a block-by-block rebasing. The DSToken simply queries this provider whenever balances are read or transactions occur.

Initially, we support two strategies:

• Fixed Multiplier — manually updated to reflect stepwise changes.
• Calculated Multiplier — derived dynamically from formulas (e.g., AUM growth over time).

Affected Components

Rebasing integrates deeply with the protocol. Core methods such as balanceOf, transfer, issueTokens, burn, totalSupply, and compliance-related checks now incorporate the multiplier logic to act on the corresponding number of underlying shares.

We also emit a new event when multiplier changes for transparency:

event RebasingRateUpdated(uint256 oldValue, uint256 newValue);

This allows off-chain systems (like our Securitize platform, but potentially also custodians, exchanges, auditors) to reconstruct effective balances and transaction flows with precision.

Self-Service Whitelisting of Wallets

The Challenge

In the DS Protocol, registering (or “whitelisting”) investor wallets has always been a crucial step. Traditionally, this was an operator-driven process, requiring an entity with “Issuer” permissions in the protocol to execute the transaction that added a wallet to the registry. While secure, this model introduced operational bottlenecks — every new wallet required issuer intervention and on-chain gas costs paid by the issuer.

The Solution: Pre-approved transactions

To streamline this, we introduced a new capability in our smart contracts that verifies user actions based on an attestation issued by our backend systems. This attestation is generated from a pre-existing web2 verified session, allowing our backend to ensure the action originates from the correct, authenticated user profile with validated KYC and compliance status. Through this mechanism, users can trigger operations that would otherwise be restricted to platform operators — effectively decentralizing execution without compromising compliance.

How it works:

1. Pre-approval: Our system generates an EIP-712–compliant message containing all necessary data for the operation (e.g., wallet registration).
2. User signing: The investor signs the message through our UI, which validates their identity off-chain (KYC/AML already done).
3. Executing: The signed message is submitted by the investor to the DSToken contract, which verifies the signature and executes the corresponding operation on-chain.

Benefits

This approach transforms wallet whitelisting into a self-service experience:

• Investor-driven: Investors can add wallets when they need, without waiting for manual operator action.
• Instant and composable user experience: Whitelisting happens the moment the user signs the transaction, without waiting for operator execution. This approach also enables new DSApps to chain the whitelisting step atomically with other actions — such as subscribing to a token or executing a swap — creating seamless, self-contained user flows.
• Secure and compliant: Only pre-approved, EIP-712–signed operations are relayed, ensuring that compliance checks remain intact.

In practice, this means smoother onboarding, faster registry updates, composability, and a more scalable compliance workflow — all while preserving the DS Protocol’s regulatory guarantees.

An Example: Integrating Securitize ID Connect

One powerful use case unlocked by self-service whitelisting is third-party integrations. Through the Securitize ID Connect API, partners such as wallet providers can authenticate a user directly within their own UI.

• If the user is not yet registered or KYC’d, the API prompts them to complete the required steps through the Securitize platform.
• Once verified, the user can seamlessly self-whitelist their wallet, with the authorization of the Securitize API, without ever leaving the partner application.

This integration greatly simplifies how investors access tokenized securities, enabling smooth onboarding flows across partner ecosystems while keeping compliance checks intact.

Recap of the Updates

With these updates, the DS Protocol now supports:

• Granular role segregation with the new Transfer Agent role, ensuring compliance management is distinct from issuance and operational duties.
• Automated yield reflection through rebasing.
• Investor-driven onboarding via self-service wallet whitelisting, reducing issuer overhead while preserving compliance.
• Greater flexibility for issuers, exchanges, and investors.

These capabilities position the DS Protocol as a complete infrastructure for regulated securities on-chain, reducing friction while meeting compliance requirements.

Next Steps

Looking ahead, we are focused on expanding the DS Protocol’s capabilities to meet the evolving needs of issuers, investors, and regulators. Our priorities include:

• Expanding compliance models to support a broader range of asset classes and adapt to diverse regulatory frameworks worldwide.
• Developing additional rebasing strategies, including formula-based accruals and performance-linked multipliers.
• Deploying fully managed factories for DSApps, enabling issuers to spin up complete environments with minimal effort.
• Enhancing reporting and analytics for rebased balances, capital flows, and compliance events.

And this is only the beginning.

In upcoming articles, we’ll showcase some of the DSApps already built on top of the DS Protocol — including the On / Off Ramp DSApps for instant subscriptions and redemptions, and the Bridge DSApp, which enables seamless cross-chain transfers of regulated assets.

The DSToken v4 reference implementation is open source and can be found here, along with the security audits performed on this latest version.

As always, we welcome contributions and feedback from the community.

DS Protocol v4 — Evolving Real World Assets was originally published in securitize on Medium, where people are continuing the conversation by highlighting and responding to this story.