YuzuUSD

Smart Contract Security Assessment

February 09, 2026

SUMMARY​

ABSTRACT​

Dedaub was commissioned to perform a security audit of the latest version of the Yuzu protocol, by Ouroboros and TelosC. No major issues were identified, although we do report low severity issues and advisories.

BACKGROUND​

The YuzuUSD protocol under audit is a USDC-backed stablecoin ecosystem. It issues YuzuUSD, a stablecoin backed 1:1 by USDC. Users can stake YuzuUSD in the ERC4626-compliant StakedYuzuUSD vault to earn yield. To further enhance liquidity, USDC liquidity providers may participate in YuzuILP, an Insurance Liquidity Pool, and receive yield via the corresponding YuzuILP token. The protocol also includes orderbook functionality, enabling redemptions to be fulfilled by third parties through a three-step process. The protocol is centralized, with an admin responsible for several critical system functions.

The audit covers the V2 of the protocol, which adds important functionality with respect to the first version (although the core operations remain the same). The most prominent is a PSM module that allows instant staking and unstaking operations; users can send USDT, minting yzUSD and staking it to syzUSD, and vice versa. The PSM holds its own liquidity for instant operations, but also allows asynchronous orders filled by an admin. Cross-chain operations via LayerZero are added, as well as an emergency pause covering all user actions.

A previous audit by Dedaub of the first protocol version is available here: https://dedaub.com/audits/yuzu-money/yuzuusd-october-6-2025

SETTING & CAVEATS​

This audit report mainly covers the contracts of the public https://github.com/Telos-Consilium/ouroboros-contracts/ repository of the Yuzu Protocol at commit 4614a5a997c7640c62619d71cdd1d05dd4d449a5 on branch v2. The target of the audit is evaluating the changes introduced in the following pull request of the repository: https://github.com/Telos-Consilium/ouroboros-contracts/pull/23

Audit Start Date: February 02, 2026

Audit End Date: February 05, 2026

Report Submission Date: February 09, 2026

2 auditors worked on the following contracts:

The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than the regular use of the protocol. Functional correctness (i.e. issues in "regular use") is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.

The auditing team also spent considerable time reviewing third party dependencies, which mainly covers:

• The LayerZero oVault integration introduced in the changes within the scope
• Any use of libraries

While those are assumed to be secure within the context of the engagement, a functional correctness issue regarding a specific OpenZeppelin library has been disclosed to the developers. In accordance with the principles of responsible disclosure, we have omitted the details from this report, having communicated directly with both OpenZeppelin and the protocol team. The severity is low, and we anticipate negligible adverse effects once the team implements the necessary precautions.

VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:

CRITICAL SEVERITY​

[No critical severity issues]

HIGH SEVERITY​

[No high severity issues]

MEDIUM SEVERITY​

[No medium severity issues]

LOW SEVERITY​

function burn(uint256 tokens) public virtual {
    address _owner = _msgSender();
    uint256 maxTokens = maxBurn(_owner);
    if (tokens > maxTokens) {
        revert ExceededMaxBurn(_owner, tokens, maxTokens);
    }
    _burn(_owner, tokens);
}

function _redeem(address caller, address receiver, address _owner, uint256 shares) internal returns (uint256) {
    uint256 assets1 = _vault1.redeem(shares, address(this), _owner);
    uint256 assets0 = _vault0.convertToAssets(assets1);
    IERC20Burnable(address(_vault0)).burn(assets1);
    SafeERC20.safeTransfer(IERC20(asset()), receiver, assets0);
...
}

function fillRedeemOrders(uint256 assets, uint256[] calldata orderIds)
...
    for (uint256 idx = 0; idx < orderIds.length; idx++) {
        uint256 orderId = orderIds[idx];
        _fillRedeemOrder(caller, orderId);
    }
}

function _fillRedeemOrder(address caller, uint256 orderId) internal {
...

    uint256 assets = _redeem(caller, order.receiver, address(this), order.shares);
...
}

uint256[50] private __gap;

uint256[41] private __gap;

contract StakedYuzuUSDV2 is StakedYuzuUSD, IStakedYuzuUSDV2Definitions {
    mapping(address => IntegrationConfig) internal integrations;
...

CENTRALIZATION CONSIDERATIONS​

It is often desirable for DeFi protocols to assume no trust in a central authority, including the protocol’s owner. Even if the owner is reputable, users are more likely to engage with a protocol that guarantees no catastrophic failure even in the case the owner gets hacked/compromised. We list issues of this kind below. (These issues should be considered in the context of usage/deployment, as they are not uncommon. Several high-profile, high-value protocols have significant centralization threats.)

OTHER / ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.

// slither-disable-next-line unused-state
uint256[45] private __gap0;
uint256[5] private __gap1;

DISCLAIMER​

The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.

ABOUT DEDAUB​

Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.