Q1 2026 Security & Compliance Report44 incidents, $482M in losses, insights from 11 industry leaders.
Read the report
Rozo logo

Rozo

Audit name:

[SCA] Rozo | SDF Audit | mar2026

Date:

Apr 13, 2026

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Rozo team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

ROZO Intents is an intent-based stablecoin SDK that enables users to transfer USDC and other stablecoins between chains like Stellar, Base, Polygon, and Solana with zero confusion and near-zero error. It is designed for real-world payment speed and reliability, combining stablecoin abstraction, automatic route selection for the fastest route, and optimized capital flow with transparent status tracking.

Document

NameSmart Contract Code Review and Security Analysis Report for Rozo
Audited ByFelipe Donato
Approved ByKerem Solmaz
Websitehttps://rozo.ai→
Changelog30/03/2026 - Preliminary Report
PlatformStellar
LanguageRust
TagsBridge
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

Review Scope

Repositoryhttps://github.com/RozoAI/rozo-intents-contracts/tree/main→
Commit1c2f003

Audit Summary

8Total Findings
8Resolved
0Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}

Documentation quality

  • Design documentation is provided for both contracts, including state machine diagrams, interface specifications, security checklists, and pseudocode implementations.

  • Role definitions and trust model (trusted backend) are documented.

  • Inline code documentation is minimal - function signatures have brief doc comments but do not describe parameter constraints or revert conditions.

Code quality

  • The development environment is configured.

Test coverage

Code coverage of the project is 97.69% (line coverage).

  • Deployment, authorization enforcement, and state machine transitions are covered with tests.

  • Negative input testing is partially covered (zero amounts, memo limits, unauthorized callers, invalid status transitions). Negative numeric values, exact boundary conditions, and deadline edge-case timing are not tested.

  • Event data correctness is not verified despite the system being event-driven.

System Overview

Rozo Intents V2 is a set of Soroban smart contracts that enable cross-chain token forwarding and bridging on Stellar. It consists of two contracts:

  • Token Forwarder: Enables bidirectional transfers between Smart Wallets (C Accounts) and Stellar Accounts (G Accounts)

  • Intent Bridge: Escrow-based cross-chain intent system with timeout protection

Privileged roles

Intent Bridge:

  • Messenger - can call fill() to confirm cross-chain completion and release escrowed funds to the Relayer. Cannot be rotated post-deployment.

  • Relayer - passive recipient of filled intent funds. Cannot be rotated post-deployment.

  • No admin role exists. No contract parameters can be modified after deployment.

Token Forwarder:

  • Admin - can update the proxy address via set_proxy_address(), set and remove memo mappings, and flush stuck tokens to the proxy. Cannot be rotated post-deployment.

  • No pause, upgrade, or self-destruct capability exists in either contract.

Potential Risks

System Reliance on External Contracts: The Intent Bridge accepts arbitrary token contract addresses and delegates transfer execution to external token contracts not covered by this audit. Any non-standard behavior in these token contracts (e.g., fee-on-transfer, rebasing) directly affects the correctness of the bridge's escrow accounting.

Scope Limitation: This audit covers only the on-chain Soroban contracts within the defined scope. The off-chain messenger, relayer, backend infrastructure, and frontend application were not assessed. The overall security of the cross-chain settlement flow depends on components outside this audit's scope.

Absence of Time-lock Mechanisms for Critical Operations: The fill() function releases escrowed funds immediately upon messenger authorization with no delay or review window. There is no buffer to detect or revert a potentially incorrect or malicious fill before funds leave the contract.

Insufficient Multi-signature Controls for Critical Functions: The messenger role is a single key that controls all fund releases via fill(). No multi-signature or threshold scheme is required. Compromise of this single key allows unilateral release of all pending escrowed funds.

Single Points of Failure and Control: The messenger and relayer are single addresses controlled by Rozo. Cross-chain settlement depends entirely on these centralized roles. No decentralized confirmation mechanism exists in the current design.

Administrative Key Control Risks: All privileged roles (Messenger, Relayer, Admin) are immutable single keys set at deployment. There is no on-chain recovery path if any key is lost or compromised. Rotation requires full contract redeployment, leaving pending state in the old contract inaccessible from the new one.

Findings

Code
―
Title
Status
Severity
F-2026-1561Fee-on-Transfer Tokens Can Break Intent Accounting
fixed

Medium
F-2026-1560Missing Persistent TTL Extension on Memo Mappings Can Cause Silent Routing Failure
fixed

Low
F-2026-1560Missing Instance Storage TTL Extension Can Cause Temporary Contract Unavailability
fixed

Low
F-2026-1560Missing Destination Field Validation Allows Malformed Intents On-Chain
fixed

Observation
F-2026-1560Missing Existence Check in removememomapping Emits Spurious Events
fixed

Observation
F-2026-1560Unused Error Variants Reduce ABI Clarity
fixed

Observation
F-2026-1560Outdated soroban-sdk Dependency Contains Three Known CVEs
fixed

Observation
F-2026-1560Immutable Role Configuration Prevents On-Chain Key Rotation After Deployment
fixed

Observation
1-8 of 8 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/RozoAI/rozo-intents-contracts/tree/main→
Commit1c2f003
WhitepaperN/A
Requirementshttps://docs.rozo.ai; README.md
Technical Requirementshttps://docs.rozo.ai; README.md

Assets in Scope

v2
stellar
forwarder
src
lib.rs - v2 › stellar › forwarder › src › lib.rs
intent_bridge
src
lib.rs - v2 › stellar › intent_bridge › src › lib.rs

Appendix 3. Additional Valuables

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer