Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →

Audit name:

[SCA] Nonco | Swap Contracts | Mar2025

Date:

Apr 3, 2025

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 Nonco team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Nonco swap system is a secure, owner-controlled token swap infrastructure that enforces strict address and asset-level whitelisting. It ensures that only pre-approved token pairs and wallet addresses can participate in token swap operations through a central Swap contract. The system comprises three core contracts: AddressWhitelist, AssetsWhitelist, and Swap.

Document

NameSmart Contract Code Review and Security Analysis Report for Nonco
Audited ByKaan Caglan
Approved ByIvan Bondar
Websitehttps://nonco.com→
Changelog31/03/2025 - Preliminary Report
03/04/2025 - Final Report
PlatformEVM
LanguageSolidity
TagsSwaps
Methodologyhttps://hackenio.cc/sc_methodology→
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Nonco
    Audited By
    Kaan Caglan
    Approved By
    Ivan Bondar
    Changelog
    31/03/2025 - Preliminary Report
    03/04/2025 - Final Report
    Platform
    EVM
    Language
    Solidity
    Tags
    Swaps

Audit Summary

9Total Findings
6Resolved
3Accepted
0Mitigated

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

Documentation quality

  • Functional requirements are partially missed.

  • Technical description is not provided.

  • Natspec is not sufficient.

Code quality

  • Best practices are followed.

  • The development environment is configured.

Test coverage

Code coverage of the project is 96.74% (branch coverage).

  • Deployment and basic user interactions are covered with tests.

System Overview

Nonco Swap is a secure, owner-controlled token swap infrastructure that enforces strict address and asset-level whitelisting. It ensures that only pre-approved token pairs and wallet addresses can participate in token swap operations through a central Swap contract. The system comprises three core contracts: AddressWhitelist, AssetsWhitelist, and Swap.

CONTRACTS:

1\. AddressWhitelist

  • Purpose: Manages a whitelist of addresses permitted to perform swaps with each other.

  • Core Features:

    • Add or remove addresses to/from an allowlist.

    • Lock/unlock the whitelist functionality (lockdown).

    • Authorize one external contract (the Swap contract) to access whitelisting checks.

    • Restricts calls to the isAddressAllowed function to either the contract owner or the authorized swap contract.

  • Key Variables:

    • allowList: List of approved addresses.

    • isAllowed: Mapping to check if an address is approved.

    • isLocked: When true, disables all whitelist checks.

    • swapContractId: Authorized contract allowed to perform whitelist checks.

2\. AssetsWhitelist

  • Purpose: Maintains a whitelist of token pairs allowed to be swapped.

  • Core Features:

    • Approve or remove allowed token swap pairs symmetrically.

    • Lock/unlock whitelist checking for token pairs.

    • Authorize one external contract (the Swap contract) to perform allowed token checks.

    • Uses string concatenation of token addresses to track allowed pairs.

  • Key Variables:

    • allowedTokens: Mapping from a token to its allowed swap partners.

    • isAllowedToken: Mapping of concatenated token pair strings to boolean values for fast lookup.

    • isLocked: Global switch to disable token pair checks.

    • swapContractId: Authorized contract allowed to check token pairs.

3\. Swap

  • Purpose: Facilitates token swaps between two addresses and tokens, ensuring compliance with both address and token whitelisting.

  • Core Features:

    • Calls AssetsWhitelist and AddressWhitelist before allowing a swap.

    • Verifies token balances and allowances for both parties.

    • Executes symmetric token transfer between sender and receiver using SafeTransferLib.

    • Maintains a sequential message number (msgSeqNum) for tracking or replay protection.

  • Key Variables:

    • assetsWhitelist: Interface to the AssetsWhitelist contract.

    • addressWhitelist: Interface to the AddressWhitelist contract.

    • msgSeqNum: An incremental message sequence number, potentially for anti-replay logic.

ATTRIBUTES:

There are no tokens defined with typical ERC20 attributes such as name, symbol, decimals, or totalSupply in this system. The architecture is focused on swap logic and access control via whitelisting, not token issuance.

PRIVILEGED ROLES:

Owner (via Ownable)

  • Can:

    • Add or remove addresses and tokens from the whitelist.

    • Enable/disable whitelist enforcement via lockdown mechanisms.

    • Set the authorized swap contract in both whitelist contracts.

    • Initiate swap transactions and update the sequence number.

Contracts where owner role is critical: AddressWhitelist, AssetsWhitelist, Swap.

Potential Risks

Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.

Administrative Key Control Risks: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.

Findings

F-2025-9470Insecure Handling of msgSeqNum Allows Arbitrary State Manipulation
Status
accepted
Severity

Low
F-2025-9465High Risk Centralization and Unlimited Fund Drain via safeTransfer Function
Status
accepted
Severity

Low
F-2025-9512Missing Events
Status
accepted
Severity

Observation
F-2025-9511Owner Can Renounce Ownership
Status
fixed
Severity

Observation
F-2025-9463Revert String Size Optimization
Status
fixed
Severity

Observation
F-2025-9462Floating Pragma
Status
fixed
Severity

Observation
F-2025-9461Unneeded initializations of uint256 and bool variable to 0/false
Status
fixed
Severity

Observation
F-2025-9459Cache State Variable Array Length In For Loop
Status
fixed
Severity

Observation
F-2025-9457Missing checks for address(0)
Status
fixed
Severity

Observation
Code
―
Title
Status
Severity
F-2025-9470Insecure Handling of msgSeqNum Allows Arbitrary State Manipulation
accepted

Low
F-2025-9465High Risk Centralization and Unlimited Fund Drain via safeTransfer Function
accepted

Low
F-2025-9512Missing Events
accepted

Observation
F-2025-9511Owner Can Renounce Ownership
fixed

Observation
F-2025-9463Revert String Size Optimization
fixed

Observation
F-2025-9462Floating Pragma
fixed

Observation
F-2025-9461Unneeded initializations of uint256 and bool variable to 0/false
fixed

Observation
F-2025-9459Cache State Variable Array Length In For Loop
fixed

Observation
F-2025-9457Missing checks for address(0)
fixed

Observation
1-9 of 9 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

RepositoryAssetsWhitelist→
AddressWhitelist→
Swap→
CommitN/A
RetestAddressWhitelist→
AssetWhitelist→
Swap→
WhitepaperN/A
RequirementsN/A
Technical RequirementsN/A

Assets in Scope

addressWhitelist.sol - addressWhitelist.sol
assetsWhitelist.sol - assetsWhitelist.sol
swap.sol - swap.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Nonco Swap, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Echidna →, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 7 invariants were tested over 5,000,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

echidnaassetsWhitelistmutualPassed1M+
echidnaassetsWhitelistconcatenationPassed1M+
echidnaaddressWhitelistaddedPassed1M+
echidnaaddressWhitelistconsistencyPassed1M+
echidnaswapseqnumPassed1M+
echidnaaddressWhitelistnoDuplicatesPassed1M+
echidnalockdownstatePassed1M+
  • Invariant

    echidnaassetsWhitelistmutual

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidnaassetsWhitelistconcatenation

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidnaaddressWhitelistadded

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidnaaddressWhitelistconsistency

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidnaswapseqnum

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidnaaddressWhitelistnoDuplicates

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidnalockdownstate

    Test Result

    Passed

    Run Count

    1M+

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.

Disclaimer