EVM Stellar zkCrossDex Audit | ZKCross

Summary

100% of all REPORTED Findings have been addressed

About this report

Assessment Type

Assurance Assessment

Date of Engagement

August 21st, 2025 - August 22nd, 2025

Source Code

EVM_Stellar_zkCrossDex

Assessed Commit ID

0264b30

Severity Breakdown

0Acknowledged
0Risk Accepted
20Solved
20All Findings

Critical0
High0
Medium2
- 2Solved
Low5
- 5Solved
Informational13
- 13Solved

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.

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.

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.

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)	1
Attack Origin (AO)	Specific (AO:S)	0.2
Attack Cost (AC)	Low (AC:L)	1
	Medium (AC:M)	0.67
	High (AC:H)	0.33
Attack Complexity (AX)	Low (AX:L)	1
	Medium (AX:M)	0.67
	High (AX:H)	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)	0
	Low (C:L)	0.25
	Medium (C:M)	0.5
	High (C:H)	0.75
	Critical (C:C)	1
Integrity (I)	None (I:N)	0
	Low (I:L)	0.25
	Medium (I:M)	0.5
	High (I:H)	0.75
	Critical (I:C)	1
Availability (A)	None (A:N)	0
	Low (A:L)	0.25
	Medium (A:M)	0.5
	High (A:H)	0.75
	Critical (A:C)	1
Deposit (D)	None (D:N)	0
	Low (D:L)	0.25
	Medium (D:M)	0.5
	High (D:H)	0.75
	Critical (D:C)	1
Yield (Y)	None (Y:N)	0
	Low (Y:L)	0.25
	Medium (Y:M)	0.5
	High (Y:H)	0.75
	Critical (Y:C)	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)	1
	Partial (R:P)	0.5
	Full (R:F)	0.25
Scope ( $s$ )	Changed (S:C)	1.25
Scope ( $s$ )	Unchanged (S:U)	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.

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

Scope#

(a) Repository:EVM_Stellar_zkCrossDex

(b) Assessed Commit ID:0264b3082a5b080d7e4b04256724255ed60b191a

1 files

contracts

1 file

Swapper.sol

solidity

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

268595f7d7e3bac0e5c4d19f0d129d3786e3509b 0815688854e9e03092a167fb232119cd2c7606bc

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

Assessment Summary & Findings Overview#

#	Title	Severity	Score	Status
HAL-01	Third-party Can Trigger swap on Behalf of a User	Medium	5.9	Solved09/09/2025
HAL-02	Funds Can Be Stuck for Smart Contract Recipients	Medium	5.0	Solved09/09/2025
HAL-03	No Slippage Control In swap	Low	3.4	Solved09/09/2025
HAL-04	Fee-on-Transfer/Deflationary Token Incompatibility	Low	2.5	Solved09/09/2025
HAL-05	Missing Two-Step Ownership Transfer Pattern	Low	2.5	Solved09/09/2025
HAL-06	User Funds Stuck Without Recourse When Cross-Chain Transfer Fails	Low	2.5	Solved09/12/2025
HAL-07	Missing Storage Gap	Low	2.0	Solved09/09/2025
HAL-08	Typographical Errors and Inconsistencies	Informational	1.3	Solved09/09/2025
HAL-09	Missing explicit allowanceHolder zero-address check in lock/release	Informational	1.0	Solved09/09/2025
HAL-10	Swap Functionality Can Be Permanently Disabled	Informational	1.0	Solved09/09/2025
HAL-11	Risk of Irrecoverable Fund Loss in withdrawTokens	Informational	1.0	Solved09/09/2025
HAL-12	Missing Events for Critical Admin Actions	Informational	0.8	Solved09/09/2025
HAL-13	Raw ERC20 Transfer In lock	Informational	0.7	Solved09/09/2025
HAL-14	Stale ERC20 Approvals Can Enable Unintended Token Pulls	Informational	0.7	Solved09/09/2025
HAL-15	Processed Lock Hash Keyed By String	Informational	0.0	Solved09/09/2025
HAL-16	Dead Code	Informational	0.0	Solved09/12/2025
HAL-17	Unlocked Pragma	Informational	0.0	Solved09/09/2025
HAL-18	Usage of Revert Strings Instead of Custom Error	Informational	0.0	Solved09/09/2025
HAL-19	Redundant Validations After `_decode` Increase Gas and Code Complexity	Informational	0.0	Solved09/09/2025
HAL-20	Test Suite Failures	Informational	0.0	Solved09/12/2025

Findings & Tech Details#

HAL-01Solved

Third-party Can Trigger swap on Behalf of a User

Medium

5.9AO:A/AC:L/AX:M/R:N/S:U/C:N/A:N/I:M/D:H/Y:NAO:A/AC:L/AX:M/R:N/S:U/C:N/A:N/I:M/D:H/Y:N

Description

Recommendation

Remediation Comment

Addressed in:

Disclaimer#

Disclaimer#