Integrating Regulated Digital Securities into Euler Lending Infrastructure

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.