Prepared by:
HALBORN
Last Updated 11/26/2025
Date of Engagement: November 25th, 2025 - November 25th, 2025
100% of all REPORTED Findings have been addressed
All findings
7
Critical
0
High
0
Medium
0
Low
0
Informational
7
ZKPass engaged Halborn to conduct a security assessment on their smart contracts beginning and ending on November 25th, 2025. The security assessment was scoped to the smart contracts provided in the zkPass-Token-Contract GitHub repository, provided to the Halborn team. Commit hash and further details can be found in the Scope section of this report.
The reviewed contracts implement a fixed-supply omnichain ERC20 token that uses LayerZero OFT to burn on the source chain and mint on the destination chain during transfers. It also supports ERC20Permit for gasless approvals and ERC20Votes for governance.
Halborn was provided with 1 day for this engagement and assigned a full-time security engineer to assess the security of the smart contracts in scope. The assigned engineer possesses deep expertise in blockchain and smart contract security, including hands-on experience with multiple blockchain protocols.
The objective of this assessment is to:
Identify potential security issues within the ZKPToken protocol smart contracts.
Ensure that smart contract of ````ZKPToken protocol functions operate as intended.
In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of risks, which were mostly addressed by the ZKPass team. The main ones were:
Implementing a mechanism to invalidate outstanding permit signatures prior to their expiry.
Configuring the SUPPLY_CAP on non-mint chains to reflect the global supply and avoid ambiguity.
Preventing bridging to address(0), as such transfers will reduce the actual circulating supply.
Enforcing the global supply cap via the ERC20Votes supply guard.
Preventing renouncement of ownership to avoid locking essential OFT configuration.
Halborn performed a combination of manual review of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the smart contract assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation, automated testing techniques help enhance coverage of smart contracts and can quickly identify items that do not follow security best practices.
The following phases and associated tools were used throughout the term of the assessment:
Research into the architecture and purpose of the ZKPToken protocol.
Manual code review and walkthrough of the ZKPToken in-scope contracts.
Manual assessment of critical Solidity variables and functions to identify potential vulnerability classes.
Manual testing using custom scripts.
Static Analysis of security for scoped contracts and imported functions. (Slither).
Local deployment and testing with (Foundry, Remix IDE).
| 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
0
Informational
7
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| No mechanism to invalidate outstanding permit signatures before expiry | Informational | Solved - 11/25/2025 |
| SUPPLY_CAP not reflecting global supply on non-mint chains may lead to incorrect assumptions | Informational | Solved - 11/25/2025 |
| Bridging to address(0) mints tokens to an irrecoverable sink, reducing actual circulating supply | Informational | Solved - 11/25/2025 |
| Global supply cap is not enforced by ERC20Votes supply guard | Informational | Solved - 11/25/2025 |
| Checkpoint clock mode unclear and may not match intended governance design | Informational | Acknowledged - 11/26/2025 |
| Renouncing ownership can permanently lock essential OFT configuration | Informational | Solved - 11/25/2025 |
| Single-step ownership transfer increases risk of misconfigured or lost ownership | Informational | Acknowledged - 11/26/2025 |
//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
zkPass Token Contract
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
