Audit name:
[SCA] Luckify | Token | Aug2025
Date:
Sep 18, 2025
Table of Content
Introduction
We express our gratitude to the Luckify team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Luckify is a service solution that combines the LUCK token and an on-chain randomness system, implementing a Chainlink-powered Random Number Service generator that delivers verifiable (VRF) and oracle-backed random outputs to specific requestors under a fee-based model.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Luckify |
| Audited By | Panagiotis Konstantinidis, Khrystyna Tkachuk |
| Approved By | Ivan Bondar |
| Website | N/A |
| Changelog | 05/09/2025 - Preliminary Report |
| 15/09/2025 - Final Report | |
| Platform | BASE |
| Language | Solidity |
| Tags | ERC-20, Fungible Token, Oracle |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Luckify
- Audited By
- Panagiotis Konstantinidis, Khrystyna Tkachuk
- Approved By
- Ivan Bondar
- Website
- N/A
- Changelog
- 05/09/2025 - Preliminary Report
- 15/09/2025 - Final Report
- Platform
- BASE
- Language
- Solidity
- Tags
- ERC-20, Fungible Token, Oracle
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/luckify-labs/luckify→ |
| Initial Commit | 2d068443854bc68a2dc34a58d10806b472a8a1c3 |
| Remediation Commit | 846ef851254c593dc5c8a765ad4dddaf82f33a09 |
Review Scope
- Repository
- https://github.com/luckify-labs/luckify→
- Initial Commit
- 2d068443854bc68a2dc34a58d10806b472a8a1c3
- Remediation Commit
- 846ef851254c593dc5c8a765ad4dddaf82f33a09
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are not provided.
Technical and architectural descriptions are missing.
Inline comments exist partially throughout the codebase.
Code quality
The code leverages OpenZeppelin and Chainlink contracts and follows established patterns.
No unnecessary complexity is present.
The codebase is well-structured and clearly organized.
Test coverage
Code coverage of the project is 0%.
The codebase does not implement meaningful unit or integration tests.
The current test files are incorrectly coded and cannot be executed.
Negative cases and multi-user interactions are missing.
System Overview
Luckify is a blockchain-based service solution composed of two core contracts:
LuckifyToken — an ERC20 upgradeable token contract implementing burnable functionality and capped at an initial supply of 1 billion LUCK tokens, minted at deployment to a specified wallet.
It has the following attributes:
Name: LUCK
Symbol: LUCK
Decimals: 18
Total Supply: 1,000,000,000 LUCK (minted at initialization)
RandomNumberService — a dedicated randomness provider contract that integrates with Chainlink’s Verifiable Random Function (VRF) and Chainlink Oracles to generate secure, tamper-resistant random numbers. The contract allows whitelisted consumer contracts to request randomness through two distinct methods: VRF random words, which provide cryptographically verifiable randomness directly on-chain, and oracle-based encrypted random numbers, which return randomness via Chainlink nodes under an oracle payment. Both request types require users to pay service fees in a specific token, which are transferred to a designated fee wallet.
The service includes administrative controls for whitelisting consumer contracts, authorizing oracle nodes, configuring request parameters (such as gas limits, confirmations, and fees). By combining VRF and oracle-backed randomness, the RandomNumberService provides a flexible and secure infrastructure for decentralized applications that depend on fair and transparent random outcomes.
Privileged roles
The owner account of both the LuckifyToken and RandomNumberService contracts holds full administrative authority. This account can:
Upgrade the contracts to new implementations under the UUPS upgradeability model.
Configure critical parameters in the RandomNumberService, including request confirmations, callback gas limits, subscription details, oracle address, fee amounts, and configure both the
tokenPriceandLINKaddresses used by the contract.Whitelist consumer contracts and authorize oracle nodes, thereby controlling which external parties may request or fulfill randomness.
Pause and unpause the RandomNumberService contract.
The whitelisted addresses are permitted to integrate with the service and use the
requestVRFandrequestEncryptedNumberfunctions to obtain randomness.The authorized sender addresses are permitted to call the
fulfillRandomWordfunction, enabling them to deliver oracle-provided random values back to the system.
Potential Risks
System Reliance on External Contracts: The RandomNumberService depends on Chainlink VRF and oracle infrastructure, while TokenPrice depends on Uniswap V3 pool data. Any flaw, downtime, or manipulation in these external systems may compromise randomness quality or price integrity.
Interactions with External DeFi Protocols: Since TokenPrice pulls directly from Uniswap V3 pools, it inherits the risks of Uniswap liquidity manipulation (e.g., price manipulation through flash loans).
Centralized Minting to a Single Address: At initialization, all tokens are minted to a single wallet. If this wallet is compromised, all tokens could be at risk.
Owner’s Unrestricted State Modification: In RandomNumberService, the owner can arbitrarily update VRF configurations, oracle addresses, fees, and whitelisted/authorized accounts. In TokenPrice, the owner can replace the Uniswap pool reference at any time. Such unrestricted powers introduce trust assumptions.
Absence of Time-lock Mechanisms for Critical Operations: Sensitive owner-only operations (e.g., changing oracle, pool, or VRF coordinator addresses) take effect immediately, leaving no buffer for stakeholder review.
Insufficient Multi-signature Controls for Critical Functions: Both LuckifyToken and RandomNumberService are fully controlled by a single owner key, centralizing decision- making.
Single Points of Failure and Control: All contracts are centrally controlled by their respective owners, introducing a centralization risk.
Administrative Key Control Risks: The security of the system relies entirely on the secrecy and security of the owner’s private key. If compromised, attackers could replace oracles, reconfigure randomness parameters, or redirect token supplies.
Centralized Oracles as Data Sources: RandomNumberService depends on Chainlink VRF/oracles, while TokenPrice depends on Uniswap pools. Both represent centralized points of reliance on external providers.
Single Entity Upgrade Authority: Both LuckifyToken and RandomNumberService are upgradeable under UUPS, with only the owner able to authorize upgrades.
Flexibility and Risk in Contract Upgrades: Since both LuckifyToken and RandomNumberService are upgradeable, the owner can replace implementations at will, potentially introducing malicious or faulty logic, if compromised.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1259 | Arithmetic Overflow in Price Scaling Calculation | fixed | High | |
| F-2025-1259 | Incorrect Decimal Scaling in TokenPrice | fixed | High | |
| F-2025-1255 | Fulfillment-time price read enables manipulation of final randomness | fixed | High | |
| F-2025-1257 | Unprotected External Calls in fulfillRandomWords May Revert and Permanently Drop VRF Callback Del… | fixed | Medium | |
| F-2025-1256 | Uniswap Spot Price Manipulation Risk | accepted | Medium | |
| F-2025-1256 | Missing Integration of Pause Functionality in Core Logic | fixed | Medium | |
| F-2025-1262 | TokenPrice May Return Inverse Price When the Expected Base Token Is token1 | accepted | Low | |
| F-2025-1259 | Incorrect EIP-712 Typehash Definition Breaks Compatibility | fixed | Low | |
| F-2025-1257 | Static Oracle_Payment Risks Under or Overpayment for Chainlink Oracle Requests | accepted | Low | |
| F-2025-1257 | Missing De-Authorization Logic for Whitelisted and Authorized Accounts | 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/luckify-labs/luckify→ |
| initial Commit | 2d068443854bc68a2dc34a58d10806b472a8a1c3 |
| Remediation Commit | 846ef851254c593dc5c8a765ad4dddaf82f33a09 |
| Whitepaper | N/A |
| Requirements | N/A |
| Technical Requirements | N/A |
Scope Details
- Repository
- https://github.com/luckify-labs/luckify→
- initial Commit
- 2d068443854bc68a2dc34a58d10806b472a8a1c3
- Remediation Commit
- 846ef851254c593dc5c8a765ad4dddaf82f33a09
- Whitepaper
- N/A
- Requirements
- N/A
- Technical Requirements
- N/A
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.