H1 2025 Web3 Security Report$3.1B in losses, DeFi hit hardest, AI threats on the rise
Read the full report
  • Hacken
  • Audits
  • allunity
  • [SCA] AllUnity | AllUnity-Contracts | May2025

AllUnity

Audit name:

[SCA] AllUnity | AllUnity-Contracts | May2025

Date:

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

AllUnity is an ERC20 solution with a blacklisting feature.

Document

NameSmart Contract Code Review and Security Analysis Report for AllUnity
Audited ByTurgay Arda Usman
Approved ByAtaberk Yavuzer
Websitehttps://allunity.com/→
Changelog06/05/2025 - Preliminary Report
09/06/2025 - Final Report
PlatformEthereum
LanguageSolidity
TagsERC20
Methodologyhttps://hackenio.cc/sc_methodology→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for AllUnity
    Audited By
    Turgay Arda Usman
    Approved By
    Ataberk Yavuzer
    Website
    https://allunity.com/→
    Changelog
    06/05/2025 - Preliminary Report
    09/06/2025 - Final Report
    Platform
    Ethereum
    Language
    Solidity
    Tags
    ERC20
    Methodology
    https://hackenio.cc/sc_methodology→

Review Scope

Repositoryhttps://github.com/All-Unity/smart-contracts→
Initial Commitf5c7927
Final Commitprovided as a file

Audit Summary

6Total Findings
3Resolved
3Accepted
0Mitigated

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

Documentation quality

  • Functional requirements are not provided missed.

    • The project's purpose and its use cases are not provided.

    • System features and expected behaviours are not provided.

    • Business logic is not provided.

  • Technical description is not provided.

    • Key function descriptions are not provided.

    • Information related to used technologies is not provided.

    • Roles and authorization are not described.

Code quality

  • The code mostly follows best practices and style guides.

    • See informational findings for more details.

  • The development environment is configured.

Test coverage

Code coverage of the project is 66.67% (branch coverage),

  • Deployment and basic user interactions are covered with tests.

  • Negative cases coverage partially missed.

  • Interactions by several users are not tested thoroughly.

System Overview

AllUnity is an ERC20 solution with blacklisting feature:

AllUnity  — simple ERC-20 token with pause and blacklisting functionality.

BlacklistManagement  — blacklisting logic.

AllUnity-V2  — second version of the AllUnity token.

BlacklistManagement-V2  — second version of the BlacklistManagement logic.

AU_PROXY— simple proxy implementation.

Privileged roles

  • The MINTER_ROLE of the AllUnity can mint tokens to the users

  • The PAUSER_ROLE  of the AllUnity can pause or unpause a contract.

  • The BURNER_ROLE of the AllUnity can  burn tokens from an account.

  • The DEFAULT_ADMIN of the AllUnity can upgrade the contract.

  • The DEFAULT_ADMIN of the BlacklistManagement can upgrade the contract.

  • The BLACKLISTER_ROLE can blacklist any address.

  • The BLACKLISTED_ROLE can revoke any role it has other than blacklist.

Potential Risks

The project operates under a centralized governance framework in which a designated group holds administrative keys and broad authorization privileges, enabling them to control token minting, adjust state variables, implement upgrades, and modify configurations. While this structure delivers streamlined operational flexibility and rapid decision-making, it also concentrates authority in a small cohort—an aspect that related parties may wish to note.

Findings

Code
―
Title
Status
Severity
F-2025-1016Blacklisted Accounts Retain Other Roles Within BlacklistManagement
accepted

Low
F-2025-1016Contract And File Name Mismatch
fixed

Observation
F-2025-1018Missing Duplicate Entry Check in Array
accepted

Observation
F-2025-1019Lack of Storage Gaps may Lead to Storage Collision
fixed

Observation
F-2025-1019Missing Zero Address Validation
fixed

Observation
F-2025-1016Floating Pragma
accepted

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

Repositoryhttps://github.com/All-Unity/smart-contracts→
Initial Commitf5c7927
Final Commitprovided as a file
WhitepaperN/A
RequirementsN/A
Technical RequirementsN/A

Assets in Scope

AllUnity.sol - AllUnity.sol
AllUnity-v2.sol - AllUnity-v2.sol
BlacklistManagement.sol - BlacklistManagement.sol
BlacklistManagement-v2.sol - BlacklistManagement-v2.sol
Proxy.sol - Proxy.sol

Appendix 3. Additional Valuables

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