The Hacken 2025 Yearly Security ReportCovers major Web3 breaches, their root causes, prevention insights, and key regulatory trends for 2026.
Learn more

Audit name:

[SCA] Tokenize.it | Token | Dec2025

Date:

Jan 2, 2026

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

tokenize.it is a tokenized cap-table protocol where a compliance-gated ERC20 token (via AllowList) can be minted with configurable platform fees (via FeeSettings) and traded peer‑to‑peer on a secondary market through a reusable TokenSwap contract.

Document

NameSmart Contract Code Review and Security Analysis Report for Tokenize.it
Audited By
Approved ByIvan Bondar
Websitehttps://tokenize.it/en
Changelog18/12/2025 - Preliminary Report
24/12/2025 - Preliminary Report
PlatformEVM
LanguageSolidity
TagsERC-20, ERC-2771, Upgradable, Meta Transactions, Swaps
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts

Review Scope

Repositoryhttps://github.com/corpus-io/tokenize.it-smart-contracts
Initial Commit177652a
Remediation Commit11fbe80

Audit Summary

8Total Findings
3Resolved
5Accepted
0Mitigated

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

{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}

Documentation quality

  • Functional requirements are well explained.

  • The technical description is well provided.

  • System invariants are described.

Code quality

  • The contracts heavily rely on OZ upgradeable modules, and follow a consistent “clone/initializer + _disableInitializers() logic contract” template across files.

  • Most critical state changes emit events, but several changes aren’t fully “audit-friendly” (no old-value fields; manager add/remove has no events).

Test coverage

Code coverage of the project is 96.56%.

  • Deployment and basic user interactions are covered with tests.

  • Randomized fuzzing tests are covered with tests.

  • System invariants were tested.

System Overview

tokenize.it is a tokenized cap-table trading module with the following contracts:

  • AllowList — owner-managed registry mapping addresses to a 256-bit attribute bitmask (incl. a reserved TRUSTED_CURRENCY bit). Other contracts read this to decide whether an address/currency is permitted.

  • FeeSettings — owner-managed fee configuration contract implementing IFeeSettingsV2 (and IFeeSettingsV1 for compatibility). Stores default fees + optional per-token discounts and per-token fee-collector overrides. Enforces max fee caps and a 12-week delay for fee increases.

  • Token — upgradeable ERC20 (ERC20Permit, ERC20Snapshot) with pause + role-based controls and allowlist-gated transfers. Minting is restricted via mintingAllowance or MINTALLOWER_ROLE; a token fee is minted to the token fee collector per FeeSettings.

  • TokenSwap — reusable standing order contract for peer-to-peer secondary swaps of already-issued Token against a fixed ERC20 currency at a fixed price, charging the crowdinvesting fee from FeeSettings. Supports both “sell order” (holder provides tokens) and “buy order” (holder provides currency).

Privileged roles

  • AllowList owner

    • Can arbitrarily add/remove/modify any address’s attributes, including marking currencies as trusted.

    • Effectively controls who can transact (subject to how Token consumes allowList).

  • FeeSettings owner

    • Can change default fee rates and default fee collectors.

    • Can appoint/remove managers.

    • Can propose fee increases only with ≥12-week delay; decreases can be immediate.

  • FeeSettings managers

    • Can set/remove per-token fee discounts and per-token fee collectors (high leverage over fee routing).

  • Token DEFAULT_ADMIN_ROLE

    • Can grant/revoke all roles and authorize upgrades (UUPS).

    • Can change AllowList reference.

    • Can accept a suggested FeeSettings contract.

  • Token REQUIREMENT_ROLE / PAUSER_ROLE / BURNER_ROLE / TRANSFERERADMIN_ROLE

    • REQUIREMENT_ROLE: can set the requirements bitmask for gating transfers.

    • PAUSER_ROLE: can pause/unpause transfers/mints/burns.

    • BURNER_ROLE: can burn tokens from any address.

    • TRANSFERERADMIN_ROLE: can grant TRANSFERER_ROLE (bypasses allowlist requirements).

  • TokenSwap owner

    • Can pause/unpause trading.

    • Can change holder, receiver, and tokenPrice (per current implementation), which is a high trust/centralization risk for live orders.

Potential Risks

Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.

System Reliance on External Contracts: The functioning of the system significantly relies on specific external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds. (Examples here include the immutable EIP-2771 trusted forwarder and OpenZeppelin implementations.)

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. (AllowList owner, FeeSettings owner/managers, Token admin roles, TokenSwap owner.)

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.

Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes. (E.g., TokenSwap parameters can be updated by owner; Token is upgradeable.)

Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.

Findings

Code
Title
Status
Severity
F-2025-1435MINTALLOWER_ROLE has unlimited minting power with no on-chain restrictions
accepted

Low
F-2025-1434TokenSwap configuration can be changed during token sale
accepted

Low
F-2025-1435TokenSwap uses unsafe transferFrom() for token transfers instead of safeTransferFrom()
accepted

Observation
F-2025-1435AllowList batch set/remove emits per-item Set events
fixed

Observation
F-2025-1435Custom errors in Solidity for gas efficiency
fixed

Observation
F-2025-1435TokenSwap sell() can execute with zero currency payout due to rounding-down
accepted

Observation
F-2025-1434TokenSwap buy() / sell() allow zero token amount
accepted

Observation
F-2025-1434Missing event emitting
fixed

Observation
1-8 of 8 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/corpus-io/tokenize.it-smart-contracts
Initial Commit177652a3fa26f1251d573a4cd10c199bf8598ae5
Remediation Commit11fbe80afe0b57e3d9fa411986fb224a1f0df865
WhitepaperN/A
RequirementsREADME.md
Technical Requirementsdeployment.md

Assets in Scope

AllowList.sol - AllowList.sol
FeeSettings.sol - FeeSettings.sol
Token.sol - Token.sol
TokenSwap.sol - TokenSwap.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.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment , and the Penetration Testing Execution Standard (PTES) , These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer

Tokenize.it audit by Hacken