Audit name:
[SCA] A Two Tech Limited | Staking | Nov2025
Date:
Dec 2, 2025
Table of Content
Introduction
We express our gratitude to the Arena Two team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
A Two Tech Limited is a decentralized, interactive platform transforming the nature of sports and entertainment by allowing fans to play an active, tokenized role in real-time event outcomes.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Arena Two |
| Audited By | , Khrystyna Tkachuk |
| Approved By | Ivan Bondar |
| Website | http://arenatwo.com/→ |
| Changelog | 24/11/2025 - Preliminary Report |
| 04/12/2025 - Final Report | |
| Platform | BSC |
| Language | Solidity |
| Tags | Vesting, Token Sales, Staking, Voting, Upgradable, ERC20, ERC721 |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Arena Two
- Audited By
- , Khrystyna Tkachuk
- Approved By
- Ivan Bondar
- Website
- http://arenatwo.com/→
- Changelog
- 24/11/2025 - Preliminary Report
- 04/12/2025 - Final Report
- Platform
- BSC
- Language
- Solidity
- Tags
- Vesting, Token Sales, Staking, Voting, Upgradable, ERC20, ERC721
Review Scope | |
|---|---|
| Repository | https://github.com/arenatwo/smart-contracts/tree/hacken-2025-10-31→ |
| Initial Commit | 3d8f05b |
| Remediation Commit | ca89ed1 |
Review Scope
- Initial Commit
- 3d8f05b
- Remediation Commit
- ca89ed1
Audit Summary
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 provided.
Run instructions are provided.
Technical specification is provided.
Inline comments exist partially throughout the codebase.
Code quality
The code leverages OpenZeppelin and Chainlink contracts and follows established patterns.
The codebase is well-structured and clearly organized.
The development environment is configured.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is partially provided.
Interactions by several users are not tested thoroughly.
System Overview
A Two Tech Limited is an integrated, interactive ecosystem that brings fans into the decision-making process of live sports and entertainment events. Built with a modular architecture and driven by the $ATWO token, the platform allows fans to influence outcomes in real time, stake tokens to support teams, and share in the upside of the events they help shape.
The protocol includes the following contracts:
ATWO.sol – ERC20 utility token for the protocol with burn capability and standard token operations. Implements a fixed-supply ERC20 with optional burning by holders. No minting or supply expansion is possible after deployment. It has the following attributes:
Name: ATWO
Symbol: ATWO
Decimals: 18
Total supply: 1,000,000.
ATWOMemberNFT.sol – ERC721 membership NFT used to gate staking, league participation, and membership-restricted actions. Provides role-protected minting and baseURI management. Represents membership for a specific team within a league; all tokens share a unified base URI.
ATWOPresale.sol – ATWO presale contract enforcing start/end windows, per-token pricing, and optional ATWO hard caps. Records contributions but does not distribute tokens; purchasers later claim via ATWODistributor. Supports approved payment tokens and configurable treasury forwarding.
ATWOPublicSale.sol – public sale contract enabling immediate ATWO distribution upon purchase. Supports allowed payment tokens, price configuration, start-time gating, and hard-cap enforcement. Requires the contract to be pre-seeded with ATWO; collected funds remain in the contract until recovered by admin.
ATWOStaking.sol – staking contract that requires membership NFT eligibility and league-specific staking windows. Allows staking ATWO per team within a league, blocks unstaking during active league windows, tracks per-team/user stake balances, and routes membership fees to team treasuries.
ATWOVoting.sol – ATWO-based voting contract with per-question pricing. Admins manage question lifecycle and enable/disable options. Users pay ATWO to vote; fees are forwarded to a treasury. Vote counts themselves are tracked off-chain via emitted events.
ATWODistributor.sol – distributor/claimer contract for presale participants. Holds ATWO and releases tokens after the TGE timestamp. Reads entitlement amounts directly from ATWOPresale and allows users to claim 100% of their purchased tokens once claims open.
Privileged roles
The protocol uses OpenZeppelin's AccessControl system with the following role hierarchy:
DEFAULT_ADMIN_ROLE: The root administrator role with the highest level of access. This role can grant and revoke all other roles in the protocol.
ADMIN_ROLE: Primary operational and configuration role for all upgradeable modules. Depending on the contract, ADMIN_ROLE is responsible for:
Protocol configuration: updating parameters and administrative settings.
Upgrade control: authorizing UUPS upgrades.
NFT management: modifying base URIs, metadata, supply limits, rarity thresholds, and VRF configuration.
Minting control: minting NFTs directly (including bypassing VRF for specific rarities where applicable).
Sale management: setting sale prices, start times, supply, payment tokens, and treasury destinations.
Membership system: configuring membership prices, team treasuries, and membership NFT addresses.
League/staking control: defining league windows and controlling when staking/unstaking is allowed.
Voting administration: opening/closing questions, enabling options, setting vote prices, and configuring vote-fee treasury.
Presale/public sale: setting pricing, payment tokens, hard caps, seeding tokens, and recovering funds.
Distributor: setting TGE time, seeding tokens for distribution, and recovering balances.
Vesting: creating or modifying vesting schedules and executing emergency withdrawals.
MINTER_ROLE: Role intended for controlled, permissioned minting of NFTs. Responsibilities include:
Membership NFTs: minting membership tokens required for staking participation.
OG Pass (Rarity): minting NFTs via the standard VRF process or batch-airdropping predefined rarities.
OG Pass (Simple): minting non-rarity NFTs (e.g., Champion passes).
PAUSER_ROLE: Emergency-response role with authority to halt protocol functionality. Holders of this role can:
Call
pause()on any pausable contract.Immediately stop all user-facing operations such as purchases, sales, staking, voting, vesting claims, and token distribution.
Use this capability during security incidents or critical failures.
Administrative functions remain available while paused.
UNPAUSER_ROLE: Role that can unpause contracts after they have been paused, restoring normal operations after an emergency pause.
Potential Risks
Centralized Minting to a Single Address: At initialization of ATWO contract, all tokens are minted to a single wallet. If this wallet is compromised, all tokens could be at risk.
Dynamic Array Iteration Gas Limit Risks: The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.
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.
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-1407 | Admin Can Arbitrarily Decrease User’s Vesting Amount Bypassing User Entitlement | fixed | Medium | |
| F-2025-1407 | No On-Chain Vote Tallying | accepted | Medium | |
| F-2025-1406 | Excessive Emergency Withdraw Can Steal User Funds | fixed | Medium | |
| F-2025-1406 | Excessive Admin Control Over Critical Staking Parameters | mitigated | Medium | |
| F-2025-1405 | Recover Function Can Steal User Funds | fixed | Medium | |
| F-2025-1407 | Missing Reserve Check Allows Creation of Underfunded Vesting Schedules | fixed | Low | |
| F-2025-1406 | Use of Unsafe transferFrom Instead of safeTransferFrom | fixed | Low | |
| F-2025-1405 | Initialization and Address Validation Issues | fixed | Low | |
| F-2025-1407 | Redundant Token Address Comparison in recover() Function | fixed | Observation | |
| F-2025-1407 | Lack of Event Emitting for Key State Changes | fixed | Observation |
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 | |
|---|---|
| Repository | https://github.com/arenatwo/smart-contracts/tree/hacken-2025-10-31→ |
| Initial Commit | 3d8f05bdb5a9b74440ac1fba9b719dec44d7c459 |
| Remediation Commit | ca89ed19f5cfdbb261aa66f1becb394a86d21bb3 |
| Whitepaper | N/A |
| Requirements | README.md |
| Technical Requirements | README.md |
Scope Details
- Initial Commit
- 3d8f05bdb5a9b74440ac1fba9b719dec44d7c459
- Remediation Commit
- ca89ed19f5cfdbb261aa66f1becb394a86d21bb3
- Whitepaper
- N/A
- Requirements
- README.md
- Technical Requirements
- README.md
Assets in Scope
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.