- Hacken
- Audits
- up10-launchpad
- [SCA] UP10 Launchpad | AdminManager | Mar2026
Audit name:
[SCA] UP10 Launchpad | AdminManager | Mar2026
Date:
May 11, 2026
Table of Content
Introduction
We express our gratitude to the UP10 Launchpad team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
UP10 is an IDO (Initial DEX Offering) launchpad platform that enables the creation and management of token sale campaigns on behalf of projects.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for UP10 Launchpad |
| Audited By | Ivan Bondar; Olesia Bilenka |
| Approved By | Khrystyna Tkachuk |
| Website | - |
| Changelog | 15/04/2026 - Preliminary Report |
| 11/05/2026 - Final Report | |
| Platform | Base |
| Language | Solidity |
| Tags | Launchpad; Claims; Vesting; Signatures; Centralization; Token Standard used: ERC20 |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for UP10 Launchpad
- Audited By
- Ivan Bondar; Olesia Bilenka
- Approved By
- Khrystyna Tkachuk
- Website
- -
- Changelog
- 15/04/2026 - Preliminary Report
- 11/05/2026 - Final Report
- Platform
- Base
- Language
- Solidity
- Tags
- Launchpad; Claims; Vesting; Signatures; Centralization; Token Standard used: ERC20
Review Scope | |
|---|---|
| Repository | https://github.com/dextrade-solutions/UP10-Smart-Contracts→ |
| Commit | def3820 |
| Remediation commit | 1b1e227 |
Review Scope
- Commit
- def3820
- Remediation commit
- 1b1e227
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Clear system overview: The documentation provides a useful high-level description of the system architecture, main contracts, IDO lifecycle, investment flow, vesting, refunds, KYC verification, and emergency procedures.
Accurate role description: The documentation describes the administrative model, including Owner, Super Admin, and Admin responsibilities, and now correctly states that
kycSigneris controlled by theKYCVerifierowner.Incomplete functional specification: The documentation does not fully define exact expected behaviors, system invariants, or all boundary conditions.
Underspecified refund behavior: Edge-case interactions between refund policy flags are not fully documented, leaving ambiguity around some refund and vesting scenarios.
Incomplete accounting description: Unit normalization, stablecoin/project-token conversion, decimal precision handling, refund accounting, and penalty reserve tracking are not fully described.
Code quality
The codebase demonstrates a reasonable overall structure with modular separation of concerns across administration, KYC verification, reserves management, and core IDO logic. Standard libraries (OpenZeppelin) are used for token interactions, access control, and cryptographic operations. The development environment is properly configured with Foundry, IR-based compilation, and optimizer settings.
However, several code quality concerns were identified:
Remaining centralized trust assumptions: Emergency withdrawal remains unrestricted beyond Super Admin authorization, and KYC approval remains contract-wide rather than IDO-specific.
Residual interface inconsistencies: Some interface or event documentation remains inconsistent with implementation behavior, particularly around refund reason codes and refund event parameters.
Test coverage
Code coverage of the project is 43.62%(branch coverage).
Deployment, basic user interactions, and core happy-path flows are covered with tests. This includes IDO creation, investment with and without KYC, token claiming at TGE, TWAP-based refund scenarios, refund reason code verification, allocation phase transitions, and multi-IDO concurrency.
Negative cases coverage is partial. Some revert conditions are tested (invalid token, below-minimum investment, invalid KYC signature, double investment), but edge cases around arithmetic boundaries, misconfigured parameters, and conflicting policy flag combinations remain untested.
Multi-user interaction testing is limited. Concurrent investments are covered, but adversarial scenarios involving competing claims and refunds by different users, accounting consistency after mixed operation sequences, and cross-IDO shared balance interactions are not exercised.
Critical accounting paths in the refund flow (bonus calculation during partial refunds, token-taken aggregation logic, precision loss during decimal conversion) have no dedicated test coverage. One integration test for complex end-to-end accounting is present in the codebase but commented out.
System Overview
UP10 is an IDO (Initial DEX Offering) launchpad platform that enables the creation and management of token sale campaigns on behalf of projects. Whitelisted stablecoins are accepted as investment, and project tokens are distributed in return. The entire lifecycle from investment through vesting to refund is managed on-chain by a single core contract.
Each IDO is configured with three allocation-based phases, where each phase carries a distinct bonus percentage that decreases as more of the total allocation is filled. Investments are denominated in USD using admin-set static prices for whitelisted stablecoins. KYC verification via EIP-712 signatures from a trusted off-chain signer is enforced for investments that meet or exceed a configurable USD threshold.
After the investment window closes, the TGE (Token Generation Event) time and claim start time are set by admins. Token distribution follows a TGE unlock, cliff, and linear vesting schedule, with tokens unlocking at discrete intervals. The refund engine is highly configurable per IDO: it supports both full and partial refunds with independent penalty rates, stage-gated policy flags (before TGE, during cliff, during vesting, after a post-vesting timeout), and a TWAP-based no-penalty full refund window. Any claim or refund action performed between the TWAP calculation window start and the full refund window end results in automatic disqualification from no-penalty full refunds.
Access control is centralized through a standalone AdminManager contract implementing a three-tier hierarchy (owner > super admin > admin), while emergency withdrawal and stablecoin management are abstracted into dedicated inherited contracts.
The files in the scope
IDOManager.sol - Core contract orchestrating the full IDO lifecycle. It manages IDO creation with phase-based bonus configuration, stablecoin investment with static-price USD conversion, token claiming governed by a TGE unlock, cliff, and interval-based linear vesting schedule, and a full/partial refund engine with configurable penalties, TWAP-based no-penalty full refund windows, per-stage policy flags, and disqualification tracking. Inherits
ReentrancyGuard,WithKYCVerifier, andReservesManager. Each address is limited to a single investment per IDO.ReservesManager.sol - Abstract contract managing the whitelist of accepted stablecoins and their static USD prices. The supported token list is immutably configured at deployment; admins can update prices post-deployment. Tracks penalty fees collected per IDO per stablecoin. Inherits
EmergencyWithdrawAdmin.EmergencyWithdrawAdmin.sol - Abstract contract providing a super-admin-gated
emergencyWithdrawfunction capable of transferring any ERC-20 token or native ETH held by the contract to the super admin address.AdminManager.sol - Standalone
Ownablecontract implementing a three-tier access control hierarchy: owner, super admin, and admin. The owner can add/remove admins and set the super admin. Admins gate IDO management operations. The super admin gates emergency withdrawals and critical infrastructure swaps (KYCVerifier and AdminManager address changes).WithAdminManager.sol - Abstract mixin that stores a reference to the
AdminManagercontract and exposesonlyAdminandonlySuperAdminmodifiers for use by inheriting contracts.KYCVerifier.sol - Standalone
Ownable+ EIP-712 contract that verifies KYC signatures from a trusted off-chain signer. Per-(user, caller) nonces are maintained to prevent signature replay. The owner can rotate the KYC signer address.WithKYCVerifier.sol - Abstract mixin that stores a reference to the
KYCVerifiercontract and exposes an internal setter for inheriting contracts.Errors.sol - Centralized custom error definitions used across all contracts.
Interfaces: IIDOManager.sol, IReservesManager.sol, IAdminManager.sol, IKYCVerifier.sol, IKYCRegistry.sol - Interface definitions containing struct declarations, event definitions, and function signatures for the corresponding contracts.
Privileged roles
AdminManager.sol:
owner (from
Ownable): Can add and remove admins viaaddAdminandremoveAdmin. Can set and replace the super admin viasetSuperAdmin. Can transfer ownership viatransferOwnershipand renounce ownership viarenounceOwnership. This is the top-level authority over all access control.superAdmin: A single address stored in state. Checked by other contracts via
isSuperAdminAddressto gate emergency and critical operations. No direct privileges exist withinAdminManageritself; it is a role consumed externally.
IDOManager.sol:
admin (via
onlyAdmin): Can create new IDOs viacreateIDO. Can set IDO timing parameters viasetClaimStartTime,setTgeTime, andsetIdoTime. Can set the project token address for an IDO viasetTokenAddress. Can set the TWAP price viasetTwapPriceUsdt. Can set the KYC investment threshold viasetKYCThresholdUSD. Can update stablecoin static prices viasetStaticPrice.superAdmin (via
onlySuperAdmin): Can replace theKYCVerifiercontract reference viasetKYCVerifier. Can replace theAdminManagercontract reference viasetAdminManager. Can withdraw any ERC-20 token or native ETH from the contract viaemergencyWithdraw.
KYCVerifier.sol:
owner (from
Ownable): Can rotate the trusted KYC signer address viasetKYCSigner. Can transfer ownership viatransferOwnershipand renounce ownership viarenounceOwnership.kycSigner (off-chain role): A trusted externally-owned account whose EIP-712 signatures are accepted as KYC proofs. Not enforced on-chain beyond signature verification; this is an off-chain authority.
Potential Risks
Permissions, Authorization & Access
Arbitrary TWAP Price Setting by Admin: Allowing the admin to set the TWAP price via setTwapPriceUsdt without on-chain verification mechanisms introduces the risk of incorrect or malicious price submission, directly affecting no-penalty full refund eligibility and potentially leading to financial losses for investors.
Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations such as replacing the AdminManager or KYCVerifier contract references, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes.
TWAP No-Penalty Refund Disqualification Applies Disproportionately To Routine User Actions: Routine actions such as claiming tokens at TGE permanently disqualify users from the no-penalty TWAP-based full refund path. Since claiming at TGE is standard expected behavior, a significant portion of investors lose access to the investor protection mechanism without awareness or intent. In configurations where full refund during vesting is disabled, disqualified users may also be entirely blocked from full refunds.
Off-Chain TWAP Price Submission Lacks Verification And Allows Admin Manipulation: The TWAP price used to determine full refund eligibility is submitted manually by an admin without any on-chain verification or oracle integration. This creates a single point of trust where the submitted value cannot be independently validated by users or verified against actual market data, allowing the admin to arbitrarily enable or block no-penalty refund eligibility.
Ignored Schedule Initialization In createIDO Can Leave Claims Permanently Blocked: The claimStartTime and tgeTime fields are hardcoded to zero during IDO creation regardless of input values. If the admin does not subsequently call the corresponding setter functions, claims and vesting remain permanently disabled for all investors in that IDO, with no on-chain mechanism to detect or prevent the misconfiguration.
Use Of Static Pricing In invest And processRefund Enables Incorrect Token Valuation: Stablecoin prices are set manually by the admin and can diverge from actual market rates. Since the same static price is used for both investment valuation and refund calculation, a stale or manipulated price allows users to receive disproportionate allocations or refund amounts relative to the real value of their deposited assets.
Absence Of Per-IDO Reserve Isolation Allows Cross-IDO Solvency Failures: All IDOs share a single contract balance for both stablecoins and project tokens, with no per-IDO reserve segregation. Refunds and claims for one IDO draw from the same pool as deposits from other IDOs. If one IDO experiences high refund volume or if the admin withdraws funds via the emergency function, other IDOs may become unable to fulfill their obligations to investors.
Fee-On-Transfer Token Handling In invest Causes Reserve Mismatch And Accounting Errors: The contract records the nominal transfer amount rather than the actual amount received after fees. If a fee-on-transfer token is used as a supported payment token, the internal accounting overestimates the contract's stablecoin reserves, leading to a progressive deficit that can cause refund or withdrawal transactions to fail due to insufficient actual balance.
Centralization
Single Points of Failure and Control: The project is centralized through the AdminManager contract, 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 contract architecture relies on administrative keys for critical operations including IDO creation, schedule configuration, TWAP price submission, and emergency fund withdrawal. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.
Centralized KYC Signer as Trust Anchor: The protocol relies on a single off-chain KYC signer address for investment verification. Dependence on a singular signing key introduces key compromise and availability risks, potentially blocking all KYC-gated investments or allowing unauthorized participation if the key is leaked.
Super Admin Emergency Withdrawal Authority: The super admin is granted unrestricted authority to withdraw any ERC-20 token or native ETH from the contract via emergencyWithdraw. This grants a single entity the ability to drain all contract-held funds, including investor stablecoin deposits and project tokens awaiting distribution, without on-chain governance or time-lock constraints.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1588 | Incorrect tokensTaken Calculation In getTokensAvailableToRefund Causes Reduced Refund Amounts | fixed | High | |
| F-2026-1589 | Incorrect Bonus Forfeiture In processRefund Causes Total Loss Of Remaining Bonus On Partial Refund | mitigated | High | |
| F-2026-1592 | Refunds Do Not Reduce totalAllocated, Permanently Blocking New Investments and Distorting Phase Bonuses | fixed | Medium | |
| F-2026-1601 | Unrestricted setTokenAddress Allows Admin To Substitute Project Token After Investment | fixed | Medium | |
| F-2026-1591 | Stale Static Price Reference in Refund Path Causes Underpayment or Permanent Revert | fixed | Medium | |
| F-2026-1698 | Removal of IDO End Time Check in _validateInvestmentState Allows Investment After IDO Closes | fixed | Medium | |
| F-2026-1698 | Refund Event Argument Count Mismatch Causes Compilation Failure | fixed | Medium | |
| F-2026-1591 | Use of .transfer() for Native ETH in emergencyWithdraw Fails for Smart Contract Wallets | fixed | Low | |
| F-2026-1591 | Emergency Withdrawal In emergencyWithdraw Enables Full Rug Pull | accepted | Low | |
| F-2026-1591 | Lack Of Post-Investment Configuration Freeze In IDOManager Allows Admin To Change Critical IDO Parameters | fixed | Low |
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/dextrade-solutions/UP10-Smart-Contracts→ |
| Commit | def382048e4739ae306f1aaa603f0db08af024b8 |
| Remediation commit | 1b1e227f76df6e6fec6fc2d267940f4331c87124 |
| Whitepaper | N/A |
| Requirements | README.md→ |
| Technical Requirements | doc.md→ |
Scope Details
- Commit
- def382048e4739ae306f1aaa603f0db08af024b8
- Remediation commit
- 1b1e227f76df6e6fec6fc2d267940f4331c87124
- Whitepaper
- N/A
- Requirements
- README.md→
- Technical Requirements
- doc.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.