Is Fren Pet Safe? Smart Contract Security Analysis

Security Findings

2 High2 Med2 Low1 Info

High

Extensive Owner Privileges and Centralization Risk

H-01The `FrenPetToken` contract grants the `owner` (via `Ownable`) extensive control over critical parameters and functionalities. This includes the ability to: update buy and sell fees up to 25% each, set maximum transaction amounts and maximum wallet holdings (potentially to zero, halting transfers), enable/disable trading, blacklist any address, and control the pre-migration phase. This high degree of centralization introduces significant trust assumptions and a single point of failure. A compromised or malicious owner could severely impact token holders. (7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.8 Operations)

IssueThe `FrenPetToken` contract grants the `owner` (via `Ownable`) extensive control over critical parameters and functionalities. This includes the ability to: update buy and sell fees up to 25% each, set maximum transaction amounts and maximum wallet holdings (potentially to zero, halting transfers), enable/disable trading, blacklist any address, and control the pre-migration phase. This high degree of centralization introduces significant trust assumptions and a single point of failure. A compromised or malicious owner could severely impact token holders. (7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.8 Operations)

FixConsider implementing a multi-signature wallet for critical owner functions or a time-locked contract for sensitive parameter changes to reduce the risk associated with a single point of control. Clearly communicate the extent of owner privileges to the community.

StatusUnresolved

High

Potential for Excessive Transaction Fees

H-02The owner has the capability to set `buyTotalFees` and `sellTotalFees` up to 25% (2500 basis points) each. While the current default fees are 5% and 5% respectively, the `updateBuyFees` and `updateSellFees` functions allow the owner to increase these significantly. Such high transaction fees could render the token illiquid, discourage trading, and effectively drain value from token holders with each transaction. (7.4 Economic)

IssueThe owner has the capability to set `buyTotalFees` and `sellTotalFees` up to 25% (2500 basis points) each. While the current default fees are 5% and 5% respectively, the `updateBuyFees` and `updateSellFees` functions allow the owner to increase these significantly. Such high transaction fees could render the token illiquid, discourage trading, and effectively drain value from token holders with each transaction. (7.4 Economic)

FixImplement a maximum cap for fees that is lower than 25%, or introduce a community governance mechanism to approve fee changes. Clearly document the fee structure and potential for changes.

StatusUnresolved

Medium

Anti-whale Mechanism Limitations

M-01The `maxTransactionAmount` and `maxWallet` limits are designed to prevent large transactions and concentrated holdings. However, these mechanisms can be bypassed by sophisticated users through splitting transactions across multiple wallets or by using multiple addresses to accumulate tokens beyond the `maxWallet` limit. While common in token contracts, this limits the effectiveness of the anti-whale measures. (7.4 Economic)

IssueThe `maxTransactionAmount` and `maxWallet` limits are designed to prevent large transactions and concentrated holdings. However, these mechanisms can be bypassed by sophisticated users through splitting transactions across multiple wallets or by using multiple addresses to accumulate tokens beyond the `maxWallet` limit. While common in token contracts, this limits the effectiveness of the anti-whale measures. (7.4 Economic)

FixAcknowledge that anti-whale mechanisms have inherent limitations. For more robust control, consider alternative strategies or clearly communicate these limitations to users.

StatusUnresolved

Medium

Pre-migration Phase Operational Risk

M-02The contract includes a `preMigrationPhase` and a `preMigrationTransferrable` mapping, allowing the owner to control token transfers during a specific phase. This adds significant complexity to the transfer logic and grants the owner granular control over who can transfer tokens during this period. Mismanagement or errors in setting these parameters could lead to unintended restrictions on token movement or operational issues during a migration event. (7.8 Operations, 7.1 Architecture)

IssueThe contract includes a `preMigrationPhase` and a `preMigrationTransferrable` mapping, allowing the owner to control token transfers during a specific phase. This adds significant complexity to the transfer logic and grants the owner granular control over who can transfer tokens during this period. Mismanagement or errors in setting these parameters could lead to unintended restrictions on token movement or operational issues during a migration event. (7.8 Operations, 7.1 Architecture)

FixEnsure thorough testing of the pre-migration phase logic. Clearly define and communicate the conditions and duration of this phase to users. Consider if such a complex mechanism is strictly necessary or if simpler, more transparent migration strategies could be employed.

StatusUnresolved

Low

Redundant SafeMath Usage

L-01The contract imports and uses `SafeMath` for `uint256` operations. However, the contract is compiled with Solidity 0.8.19, which includes built-in overflow and underflow checks for all arithmetic operations by default. The explicit use of `SafeMath` is therefore redundant and adds unnecessary code complexity without providing additional security benefits in this Solidity version. (7.2 Code Security)

IssueThe contract imports and uses `SafeMath` for `uint256` operations. However, the contract is compiled with Solidity 0.8.19, which includes built-in overflow and underflow checks for all arithmetic operations by default. The explicit use of `SafeMath` is therefore redundant and adds unnecessary code complexity without providing additional security benefits in this Solidity version. (7.2 Code Security)

FixRemove the `using SafeMath for uint256;` statement and all explicit `SafeMath` calls. This will simplify the code without compromising security.

StatusUnresolved

Low

Hardcoded Uniswap Router Address

L-02The Uniswap V2 Router address (0x327D…5d86) is hardcoded in the constructor. While this is a common practice, it means that if the Uniswap router contract were to be upgraded, deprecated, or compromised, the `FrenPetToken` contract's `swapAndLiquify` functionality would cease to work correctly, requiring a new deployment of the token contract to update the address. (7.6 External)

IssueThe Uniswap V2 Router address () is hardcoded in the constructor. While this is a common practice, it means that if the Uniswap router contract were to be upgraded, deprecated, or compromised, the `FrenPetToken` contract's `swapAndLiquify` functionality would cease to work correctly, requiring a new deployment of the token contract to update the address. (7.6 External)

FixFor future contracts, consider making critical external contract addresses configurable by the owner (e.g., via an `onlyOwner` function) to allow for updates without redeploying the entire token.

StatusUnresolved

Info

Complex Transfer Logic

I-01The `_transfer` function in `FrenPetToken` is highly complex due to the numerous conditional checks for fees, anti-whale limits, blacklist status, trading activity, and the pre-migration phase. This intricate logic, while designed to implement specific tokenomics, increases the cognitive load for auditors and developers, making it more challenging to reason about correctness and potentially increasing the risk of subtle bugs or unexpected interactions. (7.2 Code Security, 7.1 Architecture)

IssueThe `_transfer` function in `FrenPetToken` is highly complex due to the numerous conditional checks for fees, anti-whale limits, blacklist status, trading activity, and the pre-migration phase. This intricate logic, while designed to implement specific tokenomics, increases the cognitive load for auditors and developers, making it more challenging to reason about correctness and potentially increasing the risk of subtle bugs or unexpected interactions. (7.2 Code Security, 7.1 Architecture)

FixWhile the current implementation appears functionally correct, consider refactoring complex logic into smaller, more focused internal functions in future contracts to improve readability, testability, and maintainability. Ensure comprehensive unit and integration tests cover all possible execution paths within the `_transfer` function.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract's architecture (7.1) is a standard ERC20 token with added DeFi features, utilizing well-audited OpenZeppelin and Solmate libraries for core functionalities. Code security (7.2) is generally robust, with `SafeTransferLib` used for external transfers and a reentrancy guard implemented for `swapAndLiquify`. However, the `_transfer` function is notably complex, increasing the potential for subtle bugs. Access control (7.3) is managed via `Ownable`, granting the deployer extensive privileges over critical contract parameters and operations.

GovernanceHigh2/10

The economic model (7.4) is highly dependent on owner actions, as fees can be set up to 25% for both buy and sell transactions, potentially leading to excessive taxation. The anti-whale mechanisms, while present, can be bypassed. Governance (7.5) is entirely centralized, with the owner having unilateral control over all critical parameters, including the ability to blacklist users and pause trading. This introduces significant trust assumptions and a single point of failure. External dependencies (7.6) on Uniswap V2 are standard, but the hardcoded router address limits flexibility.

UpgradesMedium6/10

The contract is not designed to be upgradeable, meaning its logic is immutable once deployed. This eliminates upgrade-related risks but requires any future changes to be implemented via a new contract deployment.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

71.6% in top 10

14.1% in wallets57.6% in contracts

Effective Concentration37.1%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$809.8K across 5 pairs

Uniswap v2WETHanalysed$806.3K BaseswapWETH$3.5K AerodromeWETH$15 Uniswap v4USDC$7 SushiswapWETH$1

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder98.0%

Top-3 Unlocked100.0%

Key Addresses

11 addresses

Deployer

0x047f…54b7

Unlocked LP Held By

0x038d…25340xe764…90950xb6d4…4d0a0xf493…eb1e0x9bd2…168c0x8099…43b70x2934…eff80x3ec2…39870x8392…3a6d0x89b9…1276

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

8 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Top-10 concentration > 30% (71.6% total → 37.1% effective; 14.1% in EOAs, 57.6% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 98.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
2 High finding(s) from audit
2 Medium finding(s) from audit
2 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Is Fren Pet Safe?

Security Findings

Extensive Owner Privileges and Centralization Risk

Potential for Excessive Transaction Fees

Anti-whale Mechanism Limitations

Pre-migration Phase Operational Risk

Redundant SafeMath Usage

Hardcoded Uniswap Router Address

Complex Transfer Logic

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Fren Pet?