TRUST Summit | Nov 3, 2025 | NYCWhere decision-makers define the next chapter of secure blockchain adoption.
Learn more

LadyFoxx

Audit name:

[SCA] LadyFoxx | Smart Contract Audit | Aug2025

Date:

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

LadyFoxx is an ERC20 token with a fixed maximum mintable supply, burn functionality, and ERC20Permit support, enabling capped owner-controlled minting, public burning, with automatic minting disablement and ownership renouncement upon reaching the supply cap.

Document

NameSmart Contract Code Review and Security Analysis Report for LadyFoxx
Audited ByPanagiotis Konstantinidis, Franco Bregante
Approved ByAtaberk Yavuzer
Websitehttps://ladyfoxx.com/→
Changelog13/08/2025 - Preliminary Report
14/08/2025 - Final Report
PlatformPolygon
LanguageSolidity
TagsFungible Token, ERC-20
Methodologyhttps://hackenio.cc/sc_methodology→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for LadyFoxx
    Audited By
    Panagiotis Konstantinidis, Franco Bregante
    Approved By
    Ataberk Yavuzer
    Website
    https://ladyfoxx.com/→
    Changelog
    13/08/2025 - Preliminary Report
    14/08/2025 - Final Report
    Platform
    Polygon
    Language
    Solidity
    Tags
    Fungible Token, ERC-20
    Methodology
    https://hackenio.cc/sc_methodology→

Review Scope

Repositoryhttps://github.com/TeamFoxx2025/SmartContracts/blob/main/LDFX/LadyFoxx.sol→
Commitf028cdf

Audit Summary

4Total Findings
0Resolved
4Accepted
0Mitigated

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

Documentation quality

  • Functional requirements are partially outlined in the README file.

  • Technical description and detailed deployment or testing procedures are not provided.

Code quality

  • Clear NatSpec comments and in-line comments are provided throughout the code.

  • The development environment is not provided or configured.

Test coverage

Code coverage of the project is 0%.

  • Tests to verify core functionality are not included.

  • Negative cases and edge scenarios are not tested.

  • The test environment is not provided.

System Overview

LadyFoxx (LDFX) is an ERC20 token contract that introduces a fixed maximum mintable supply, public burn capabilities, and ERC20Permit support for gasless approvals. It is implemented using OpenZeppelin’s ERC20, ERC20Burnable, ERC20Permit, and Ownable modules to provide secure token management with enhanced supply control.

The contract implements the following functionalities:

  • Minting: Owner-only minting until the maximum mintable supply of 1 billion LDFX (with 18 decimals) is reached. Minting is permanently disabled, and ownership is automatically renounced when the cap is hit.

  • Burning: Any token holder can burn their tokens, reducing the circulating supply. Burned tokens do not restore minting capacity, as the cap is based on total minted tokens.

  • Supply Tracking: Maintains totalMinted and totalBurned values to provide clear visibility into lifetime supply changes.

  • Permit Functionality: Supports ERC20Permit, enabling gasless token approvals via signatures.

  • ETH Protection: Rejects all incoming ETH transfers via receive and fallback functions.

It has the following attributes:

  • Name: LadyFoxx

  • Symbol: LDFX

  • Decimals: 18

  • Maximum Mintable Supply: 1,000,000,000 LDFX (1 billion tokens with 18 decimals)

  • Minting Policy: Owner-only until the cap is reached, after which minting is permanently disabled and ownership is renounced.

Privileged roles

The owner of the LadyFoxx contract holds full administrative control over the token’s supply management. Specifically, the owner can:

  • Mint new tokens to any address until the maximum mintable supply of 1 billion LDFX is reached.

  • Permanently disable minting by reaching the cap or manually renouncing ownership.

  • Determine the distribution of newly minted tokens, concentrating supply if desired.

This level of control allows the owner to directly influence the token’s circulating supply and initial distribution. Once the cap is reached, the contract automatically disables minting and renounces ownership, removing these privileges permanently.

Potential Risks

Centralized Minting to a Single Address: All minted tokens can be allocated by the owner to any address of their choosing until the maximum supply cap of 1 billion LDFX is reached. This concentration of minting authority increases the risk of fund mismanagement or theft if the owner’s key is compromised.

Centralized Control of Minting Process: The owner has full control over the minting process until the cap is reached, allowing them to determine the timing, recipients, and amounts minted. This centralization presents a trust risk, as it can influence the token’s distribution and market dynamics.

Owner’s Unrestricted State Modification: The owner can mint tokens to any address until the maximum supply is reached, directly affecting the token’s circulating supply and distribution. Such unrestricted control may impact contract integrity and user trust if misused.

Absence of Time-lock Mechanisms for Critical Operations: The contract does not implement any delay or review mechanism for minting operations. This allows immediate execution of large minting transactions without providing stakeholders an opportunity to review or react, increasing the risk of sudden and impactful changes.

Insufficient Multi-signature Controls for Critical Functions: Minting operations rely solely on the owner’s address without requiring multiple approvals. This centralizes decision-making power and creates a single point of failure that could be exploited through key compromise or insider threats.

Single Points of Failure and Control: The contract is fully centralized under the owner’s control during the minting phase. A compromise or misuse of the owner’s key could lead to uncontrolled token issuance until the supply cap is reached.

Administrative Key Control Risks: The authority to mint tokens and decide their allocation is entirely dependent on the security of the owner’s private key. If this key is compromised, an attacker could mint and distribute tokens up to the maximum supply.

Findings

Code
―
Title
Status
Severity
F-2025-1215Inability to Completely Prevent Ether Deposits
accepted

Observation
F-2025-1215Code Duplication in Renouncement Logic
accepted

Observation
F-2025-1214Use Ownable2Step instead of Ownable
accepted

Observation
F-2025-1213Floating Pragma
accepted

Observation
1-4 of 4 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/TeamFoxx2025/SmartContracts/blob/main/LDFX/LadyFoxx.sol→
Commitf028cdf
WhitepaperN/A
Requirementsreadme.md
Technical RequirementsN/A

Assets in Scope

LadyFoxx.sol - LadyFoxx.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