Quantum Audit Logo

Is OFC Safe?

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

OFC OFC
0x752c…c858
Base
Not verifiedThis 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.
Last checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The ERC20FixedSupply token contract implements a standard fixed-supply ERC-20 token with features like batch transfers, permit, meta-transactions, and owner-based token recovery. The contract utilizes a modular architecture with Solidity 0.8.28, benefiting from modern security features. The `TokenRecovery` module is assumed to allow recovery of non-native ERC20 tokens, not its own fixed-supply token, which would otherwise be a critical vulnerability.

1 Medium1 Low1 Informational
Volume 24h
$389.5K
Liquidity
$203.0K
Price
$0.009783
Token Age
1y
Top 10 Holders
94.4%

Security Findings

1 Med1 Low1 Info
Medium

Deployment DoS via Large `batchMint` Arrays

M-01The `ERC20FixedSupply` constructor calls `ERC20Storage.layout().batchMint(holders, allocations)`. If the `holders` and `allocations` arrays are excessively large, the gas cost of this operation could exceed the block gas limit, preventing the contract from being deployed. This constitutes a denial-of-service at deployment time (7.2).
IssueThe `ERC20FixedSupply` constructor calls `ERC20Storage.layout().batchMint(holders, allocations)`. If the `holders` and `allocations` arrays are excessively large, the gas cost of this operation could exceed the block gas limit, preventing the contract from being deployed. This constitutes a denial-of-service at deployment time (7.2).
FixPrior to deployment, carefully calculate the gas cost of the `batchMint` operation with the intended array sizes. If the arrays are too large, consider reducing the initial number of recipients to ensure the constructor call fits within a single transaction's gas limit. For a fixed-supply token, the entire initial allocation must be processed in the constructor.
StatusUnresolved
Low

Single-step Ownership Transfer

L-01The `transferOwnership` function in `ContractOwnershipBase` allows the current owner to transfer ownership to a new address in a single transaction (7.3). While functional, this pattern carries a risk: if the `newOwner` address is incorrect (e.g., a typo or an unowned address), the contract's ownership could be permanently lost or transferred to an inaccessible address (7.8).
IssueThe `transferOwnership` function in `ContractOwnershipBase` allows the current owner to transfer ownership to a new address in a single transaction (7.3). While functional, this pattern carries a risk: if the `newOwner` address is incorrect (e.g., a typo or an unowned address), the contract's ownership could be permanently lost or transferred to an inaccessible address (7.8).
FixImplement a two-step ownership transfer mechanism. This typically involves a `proposeOwner` function where the current owner nominates a new owner, and an `acceptOwnership` function that the nominated new owner must call to finalize the transfer. This mitigates the risk of accidental ownership loss.
StatusUnresolved
Info

Reliance on External Forwarder Registry

I-01The `ERC20FixedSupply` contract integrates `ForwarderRegistryContext` and relies on an external `IForwarderRegistry` contract for meta-transaction support. The security and availability of this external registry are critical for the proper functioning of meta-transactions within the token (7.6).
IssueThe `ERC20FixedSupply` contract integrates `ForwarderRegistryContext` and relies on an external `IForwarderRegistry` contract for meta-transaction support. The security and availability of this external registry are critical for the proper functioning of meta-transactions within the token (7.6).
FixEnsure that the `IForwarderRegistry` contract used is thoroughly audited, well-maintained, and deployed by a trusted entity. Understand its operational risks and potential points of failure, as any issues with the registry could impact the user experience for meta-transactions.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract exhibits a robust technical architecture (7.1), leveraging modern Solidity features (0.8.28) and a modular design with extensive library usage for ERC-20 functionalities, batch transfers, and meta-transactions. Code quality (7.2) is high, with clear separation of concerns and error handling. A minor technical concern is the potential for a deployment-time denial of service (M-01) if the initial `batchMint` arrays are excessively large, potentially exceeding block gas limits.

GovernanceHigh1/10

The token has a fixed supply (7.4), established during construction, which provides predictable tokenomics. Ownership (7.3) is managed via a standard ERC-173 pattern, allowing the deployer to transfer control. The `TokenRecovery` feature, assuming it's for arbitrary ERC20 tokens, enhances operational safety (7.8) by allowing recovery of misdirected assets. A minor governance consideration (7.5) is the single-step ownership transfer (L-01), which could be improved with a two-step process for enhanced security.

UpgradesMedium6/10

The `ERC20FixedSupply` contract is implemented as a standard, non-upgradeable contract. There are no proxy patterns or upgrade mechanisms (7.7) integrated, which simplifies its architecture and eliminates upgrade-related risks. This design choice ensures immutability post-deployment.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

94.4% in top 10
24.3% in wallets70.1% in contracts
Effective Concentration52.3%

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

$227.2K across 5 pairs
AerodromeUSDCanalysed$203.0K89.3%AerodromeUSDC$24.2K10.7%Uniswap v4USDC$130.0%Uniswap v4ETH$60.0%Uniswap v4ETH$00.0%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x80b1…7dc8
Unlocked LP Held By
0x8815…288b

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 50% (94.4% total → 52.3% effective; 24.3% in EOAs, 70.1% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 89% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 89% of DEX liquidity)
  • 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

Related Audits

6 more on the record
AUTONOMOPOLY (AUTONO)High RiskSolana (SOL)High RiskTAOTHigh RiskCheckmate (CHECK)High RiskSoSoValue (SOSO)High RiskSally (A1C)High Risk

Would You Like a More Detailed Audit of OFC?

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

Get Detailed Audit