Prepared by:
HALBORN
Last Updated 09/15/2025
Date of Engagement: August 18th, 2025 - August 22nd, 2025
100% of all REPORTED Findings have been addressed
All findings
13
Critical
0
High
0
Medium
0
Low
6
Informational
7
The security assessment was commissioned by ZKCross, a cross-chain interoperability protocol focused on DeFi infrastructure, to assess the security and robustness of the Rust-based Stellar LockAndRelease smart contract. The assessment was performed by Halborn’s experienced security team, focusing on the code released at commit faa29f7. The review covered all functionality in contracts/lock_release/src/lib.rs between August 25th, 2025, and August 27th, 2025. The primary objective of this engagement’s core purpose was to identify vulnerabilities, ensure protocol reliability and strengthen overall security.
The team at Halborn assigned a full-time security engineer to verify the security of the smart contracts. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.
The purpose of this assessment is to:
Ensure that smart contract functions operate as intended
Identify potential security issues with the smart contract
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were addressed and properly solved by the ZKCross team. The main findings were the following:
Reject lock() calls if RevenueSet has not yet been established, or allow the owner to sweep residual fees once a revenue address has been configured.
Introduce a pending state with expiry for each lock; admins must release it before expiry, or users can refund.
Add a global paused flag, controlled by the owner/admin, to restrict lock/release actions.
Enforce percentage in the range 1..=2000, or handle 0 as a special case by skipping min_amount and safely setting fee = 0.
The assessment combined structured manual code review, requirements verification, and automated testing. Key steps included:
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
0
High
0
Medium
0
Low
6
Informational
7
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Protocol Revenue Permanently Lost When Revenue Address Not Set | Low | Solved - 09/08/2025 |
| User Funds Stuck Without Recourse When Cross-Chain Transfer Fails | Low | Solved - 09/15/2025 |
| Contract Cannot Be Halted During Security Incidents | Low | Solved - 09/08/2025 |
| Disabled Lock Feature When Fee Set to Zero | Low | Solved - 09/08/2025 |
| USDC Minimum Protection Ineffective on Stellar Network | Low | Solved - 09/08/2025 |
| Missing Revenue Tracking | Low | Solved - 09/08/2025 |
| Revenue Address Cannot Be Changed If Compromised | Informational | Solved - 09/08/2025 |
| Lock-hash lifecycle mis-management allows either replay attacks or rent DoS | Informational | Solved - 09/08/2025 |
| External token calls and reentrancy surfaces in lock and release | Informational | Solved - 09/08/2025 |
| Indexer Confusion from Redundant Token Parameters | Informational | Solved - 09/08/2025 |
| Event Monitoring Blind Spots from Inconsistent Naming | Informational | Solved - 09/08/2025 |
| Unnecessary Computation Overhead in Validation Path | Informational | Solved - 09/08/2025 |
| Performance Overhead from Unnecessary Memory Cloning | Informational | Solved - 09/08/2025 |
//Low
//Low
//Low
//Low
//Low
//Low
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
Soroban zkCrossDex
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
