EVM Stellar zkCrossDex - ZKCross

Prepared by:

HALBORN

Last Updated 09/15/2025

Date of Engagement: August 21st, 2025 - August 22nd, 2025

Summary

100% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Third-party can trigger swap on behalf of a user
7.2 Funds can be stuck for smart contract recipients
7.3 No slippage control in swap
7.4 Fee-on-transfer/deflationary token incompatibility
7.5 Missing two-step ownership transfer pattern
7.6 User funds stuck without recourse when cross-chain transfer fails
7.7 Missing storage gap
7.8 Typographical errors and inconsistencies
7.9 Missing explicit allowanceholder zero-address check in lock/release
7.10 Swap functionality can be permanently disabled
7.11 Risk of irrecoverable fund loss in withdrawtokens
7.12 Missing events for critical admin actions
7.13 Raw erc20 transfer in lock
7.14 Stale erc20 approvals can enable unintended token pulls
7.15 Processed lock hash keyed by string
7.16 Dead code
7.17 Unlocked pragma
7.18 Usage of revert strings instead of custom error
7.19 Redundant validations after `_decode` increase gas and code complexity
7.20 Test suite failures

1. Introduction

The security assessment was commissioned by ZKCross, a cross-chain interoperability protocol focused on DeFi infrastructure, to assess the security and robustness of the Solidity-based EVM Swapper smart contract. The assessment was performed by Halborn’s experienced security team, focusing on the code released at commit 0264b30. The review covered all functionality in Swapper.sol between August 21st, 2025, and August 22nd, 2025. The primary objective of this engagement’s core purpose was to identify vulnerabilities, ensure protocol reliability and strengthen overall security.

2. Assessment Summary

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 properly addressed by the ZKCross team. The main recommendations were the following:

Reinstate the check to ensure that the caller of the swap function is the one whose funds are being used.
Use call() pattern with success check instead of transfer() when transferring funds.
Add slippage control to the swap function.
Measure the token balance before and after transfer, then approve the allowanceHolder for the actual amount received instead of the nominal amount.

3. Test Approach and Methodology

A layered and exhaustive approach was adopted. Initial research mapped contract design objectives and expected operating scenarios. Manual code reviews targeted privilege boundaries, fund flows, and feature completeness, with particular scrutiny of administrative and edge-case logic. Automated static analysis and dynamic on-chain test suites were executed to cover functional correctness, failure conditions, and integration with external token contracts.

The methodology balanced deep manual analysis with rigorous automated tools. Multiple stages were conducted: reconnaissance, manual threat modeling, static analysis, custom test building, and scenario-driven on-chain transaction simulations. This combination ensured broad and deep coverage, surfacing both logical flaws and implementation oversights across all critical paths.

4. RISK METHODOLOGY

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.

The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.

The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.

The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.

The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

4.1 EXPLOITABILITY

Attack Origin (AO):

Captures whether the attack requires compromising a specific account.

Attack Cost (AC):

Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.

Attack Complexity (AX):

Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.

Metrics:

EXPLOITABILITY METRIC ( $m_e$ )	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

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

4.2 IMPACT

Confidentiality (C):

Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.

Integrity (I):

Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.

Availability (A):

Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.

Deposit (D):

Measures the impact to the deposits made to the contract by either users or owners.

Yield (Y):

Measures the impact to the yield generated by the contract for either users or owners.

Metrics:

IMPACT METRIC ( $m_I$ )	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

Impact

I

is calculated using the following formula:

$I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}$

4.3 SEVERITY COEFFICIENT

Reversibility (R):

Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.

Scope (S):

Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.

Metrics:

SEVERITY COEFFICIENT ( $C$ )	COEFFICIENT VALUE	NUMERICAL VALUE
Reversibility ( $r$ )	None (R:N) Partial (R:P) Full (R:F)	1 0.5 0.25
Scope ( $s$ )	Changed (S:C) Unchanged (S:U)	1.25 1

Severity Coefficient

C

is obtained by the following product:

$C = rs$

The Vulnerability Severity Score

S

is obtained by:

$S = min(10, EIC * 10)$

The score is rounded up to 1 decimal places.

Severity	Score Value Range
Critical	9 - 10
High	7 - 8.9
Medium	4.5 - 6.9
Low	2 - 4.4
Informational	0 - 1.9

5. SCOPE

REPOSITORY

(a) Repository: EVM_Stellar_zkCrossDex

(b) Assessed Commit ID: 0264b30

contracts/Swapper.sol

Out-of-Scope: Third party dependencies and economic attacks.

Remediation Commit ID:

Out-of-Scope: New features/implementations after the remediation commit IDs.

6. Assessment Summary & Findings Overview

Critical

High

Medium

Low

Informational

Security analysis	Risk level	Remediation Date
Third-party Can Trigger swap on Behalf of a User	Medium	Solved - 09/09/2025
Funds Can Be Stuck for Smart Contract Recipients	Medium	Solved - 09/09/2025
No Slippage Control In swap	Low	Solved - 09/09/2025
Fee-on-Transfer/Deflationary Token Incompatibility	Low	Solved - 09/09/2025
Missing Two-Step Ownership Transfer Pattern	Low	Solved - 09/09/2025
User Funds Stuck Without Recourse When Cross-Chain Transfer Fails	Low	Solved - 09/12/2025
Missing Storage Gap	Low	Solved - 09/09/2025
Typographical Errors and Inconsistencies	Informational	Solved - 09/09/2025
Missing explicit allowanceHolder zero-address check in lock/release	Informational	Solved - 09/09/2025
Swap Functionality Can Be Permanently Disabled	Informational	Solved - 09/09/2025
Risk of Irrecoverable Fund Loss in withdrawTokens	Informational	Solved - 09/09/2025
Missing Events for Critical Admin Actions	Informational	Solved - 09/09/2025
Raw ERC20 Transfer In lock	Informational	Solved - 09/09/2025
Stale ERC20 Approvals Can Enable Unintended Token Pulls	Informational	Solved - 09/09/2025
Processed Lock Hash Keyed By String	Informational	Solved - 09/09/2025
Dead Code	Informational	Solved - 09/12/2025
Unlocked Pragma	Informational	Solved - 09/09/2025
Usage of Revert Strings Instead of Custom Error	Informational	Solved - 09/09/2025
Redundant Validations After `_decode` Increase Gas and Code Complexity	Informational	Solved - 09/09/2025
Test Suite Failures	Informational	Solved - 09/12/2025

https://github.com/Dev-zkCross/EVM_Stellar_zkCrossDex/commit/0815688854e9e03092a167fb232119cd2c7606bc

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.

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Third-party can trigger swap on behalf of a user
7.2 Funds can be stuck for smart contract recipients
7.3 No slippage control in swap
7.4 Fee-on-transfer/deflationary token incompatibility
7.5 Missing two-step ownership transfer pattern
7.6 User funds stuck without recourse when cross-chain transfer fails
7.7 Missing storage gap
7.8 Typographical errors and inconsistencies
7.9 Missing explicit allowanceholder zero-address check in lock/release
7.10 Swap functionality can be permanently disabled
7.11 Risk of irrecoverable fund loss in withdrawtokens
7.12 Missing events for critical admin actions
7.13 Raw erc20 transfer in lock
7.14 Stale erc20 approvals can enable unintended token pulls
7.15 Processed lock hash keyed by string
7.16 Dead code
7.17 Unlocked pragma
7.18 Usage of revert strings instead of custom error
7.19 Redundant validations after `_decode` increase gas and code complexity
7.20 Test suite failures

// Download the full report

EVM Stellar zkCrossDex

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed