Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Frippy Safe?

FRIPPYBNB Chain
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance5/10Upgrades10/10Checks passed5 of 5Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The Frippy contract is an ERC-20 token implementation that inherits from OpenZeppelin's ERC20 and Ownable contracts.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity < $10k
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (54.7% total → 32.1% effective; 17.0% in EOAs, 37.7% in contracts — moderate)
  • Liquidity < $10k ($6,116 across 1 pairs — easily drained)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
37.7%Contracts17.0%Wallets45.3%Everyone else
37.7%Contracts17.0%Wallets45.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
54.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking37.7%
  • Walletsanonymous holders, free to sell17.0%
  • Everyone elsethe rest of the supply45.3%
Effective concentrationwhat the score reads32.1%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$6.1K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$6.1KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0x28e2…e9df0x32cb…3968

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

Security Findings

1 High1 Medium1 Low2 Info
High

Renounced Ownership and Immutability

The FRIPPY contract's constructor calls renounceOwnership(), setting the contract owner to the zero address. This design choice makes the contract completely immutable and unmanageable after deployment. While it removes central points of control and potential for malicious owner actions, it also eliminates any possibility for administrative intervention, bug fixes, or upgrades. This impacts 7.5 Governance, 7.8 Operations, and 7.7 Upgrades.H-01

Issue

The FRIPPY contract's constructor calls renounceOwnership(), setting the contract owner to the zero address. This design choice makes the contract completely immutable and unmanageable after deployment. While it removes central points of control and potential for malicious owner actions, it also eliminates any possibility for administrative intervention, bug fixes, or upgrades. This impacts 7.5 Governance, 7.8 Operations, and 7.7 Upgrades.

Fix

This is a deliberate design decision. If immutability is the explicit goal, no change is needed. However, if any future flexibility, emergency control, or upgradeability is desired, ownership should not be renounced, or a robust governance mechanism (e.g., a DAO or multi-signature wallet) should be implemented to manage the contract.

Status

Unresolved

Medium

Lack of Emergency Controls

Due to the renounced ownership (H-01), the contract lacks any emergency control mechanisms such as pausing transfers, blacklisting malicious addresses, or recovering tokens sent to the contract address. In the event of a critical vulnerability, market manipulation, or a significant exploit, there would be no way to halt operations or mitigate damage. This impacts 7.8 Operations and 7.4 Economic.M-01

Issue

Due to the renounced ownership (H-01), the contract lacks any emergency control mechanisms such as pausing transfers, blacklisting malicious addresses, or recovering tokens sent to the contract address. In the event of a critical vulnerability, market manipulation, or a significant exploit, there would be no way to halt operations or mitigate damage. This impacts 7.8 Operations and 7.4 Economic.

Fix

If emergency controls are deemed necessary for future projects, consider implementing functions like pause()/unpause() or blacklist() that are controlled by a trusted entity (e.g., a multi-signature wallet) or a decentralized governance system, and ensure these are in place before renouncing ownership.

Status

Unresolved

Low

Tokens Sent Directly to Contract Address May Be Locked

As a standard ERC-20 token, if users mistakenly send tokens directly to the FRIPPY contract address via a standard transfer call (instead of approve then transferFrom), those tokens will become permanently locked within the contract. The contract has no mechanism to retrieve or forward these tokens. This impacts 7.8 Operations.L-01

Issue

As a standard ERC-20 token, if users mistakenly send tokens directly to the FRIPPY contract address via a standard transfer call (instead of approve then transferFrom), those tokens will become permanently locked within the contract. The contract has no mechanism to retrieve or forward these tokens. This impacts 7.8 Operations.

Fix

Educate users to only interact with the token contract via its defined ERC-20 functions and to avoid sending tokens directly to the contract address. For future contracts, consider implementing a recoverERC20() function, callable by a trusted entity (if ownership is not renounced), to retrieve accidentally sent tokens.

Status

Unresolved

Info

Broad Solidity Pragma

The contract uses a broad Solidity pragma ^0.8.0. While the provided metadata indicates compilation with 0.8.26, a broad pragma allows compilation with any future 0.8.x version, which might introduce breaking changes or unexpected behavior if not explicitly tested against. This impacts 7.2 Code Security.I-01

Issue

The contract uses a broad Solidity pragma ^0.8.0. While the provided metadata indicates compilation with 0.8.26, a broad pragma allows compilation with any future 0.8.x version, which might introduce breaking changes or unexpected behavior if not explicitly tested against. This impacts 7.2 Code Security.

Fix

Consider pinning the Solidity pragma to a specific compiler version (e.g., pragma solidity 0.8.26;) to ensure consistent compilation behavior across different environments and to prevent accidental compilation with incompatible future versions.

Status

Unresolved

Info

Empty _beforeTokenTransfer and _afterTokenTransfer Hooks

The _beforeTokenTransfer and _afterTokenTransfer internal virtual functions are present but empty. While this is not a vulnerability, it represents a missed opportunity to implement custom logic, such as fee mechanisms, blacklisting, or snapshotting, before or after token transfers. This impacts 7.1 Architecture.I-02

Issue

The _beforeTokenTransfer and _afterTokenTransfer internal virtual functions are present but empty. While this is not a vulnerability, it represents a missed opportunity to implement custom logic, such as fee mechanisms, blacklisting, or snapshotting, before or after token transfers. This impacts 7.1 Architecture.

Fix

If any custom logic or additional features are desired for token transfers in future iterations, these hooks provide a clean and secure way to integrate them without modifying the core ERC-20 logic.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The Frippy contract is an ERC-20 token implementation that inherits from OpenZeppelin's ERC20 and Ownable contracts. A key design decision is the immediate renunciation of ownership in the constructor, making the contract immutable and unmanageable after deployment. While this removes central points of control, it also eliminates the possibility of future upgrades, bug fixes, or emergency interventions. The core ERC-20 logic is standard and appears robust.

Technical9/10Low risk

The contract implements a standard ERC-20 token following OpenZeppelin patterns (7.1 Architecture). It utilizes Solidity 0.8.x, which includes default overflow/underflow checks for arithmetic operations, enhancing code security (7.2 Code Security). Explicit unchecked blocks are correctly used after require statements, preventing unintended underflows in transferFrom, decreaseAllowance, _transfer, and _burn. The contract lacks complex external interactions, reducing reentrancy risks.

Governance5/10Medium risk

The contract's ownership is immediately renounced in the constructor (7.5 Governance). This design choice means no single entity can control or modify the contract post-deployment, eliminating centralized governance risks. However, it also implies a complete lack of administrative functions, such as pausing transfers, blacklisting malicious addresses, or adjusting economic parameters (7.4 Economic). This immutability prevents any emergency response or future protocol evolution, posing a high risk to adaptability and operational flexibility (7.8 Operations).

Upgrades10/10Low risk

The Frippy contract is not designed with upgradeability in mind (7.7 Upgrades). The immediate renunciation of ownership further solidifies its immutable nature. While this ensures the contract's logic cannot be altered, it also means that any discovered vulnerabilities or desired feature enhancements cannot be implemented without deploying an entirely new contract, which carries significant migration challenges.

Final RecommendationWhat to do about this score

Given the renounced ownership, users should be fully aware that the contract is immutable and unmanageable.

There will be no ability to pause, upgrade, or fix any potential issues post-deployment. For future projects, consider whether complete immutability aligns with long-term project goals. If any form of administrative control or upgradeability is desired, a proxy pattern or a multi-signature governance mechanism should be implemented before renouncing ownership.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age10mo
Contract0xf3f7…8e46
Deployer0x2b71…768f
Badge for your website
Frippy security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202613Low
  2. Jul 29, 20262Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
Giggle MascotMAX · BNB Chain13LowOKZOOAIOT · BNB Chain13LowBinance CatBNBCAT · BNB Chain13LowNianNianBNB Chain13LowARIA.AIARIA · BNB Chain12LowBreak And ReclaimBAN · BNB Chain14Low

Would You Like a More Detailed Audit of Frippy?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page