Quantum Audit Logo

Is MEET48 Token Safe?

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

Is this your token? Publish your own audit on this page →

MEET48 Token IDOL
0x3b4d…ab07
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The `Meet` contract is a standard ERC-20 token implementation, inheriting directly from OpenZeppelin's battle-tested `ERC20` library. Its primary function is to define a fixed total supply and distribute all tokens to a set of predefined addresses during deployment. The contract is immutable and lacks any administrative functions, ensuring a high degree of decentralization post-deployment. No critical or high-severity vulnerabilities were identified.

3 Informational
Volume 24h
$718.6K
Liquidity
$977.7K
Price
$0.01347
Token Age
1y
Top 10 Holders
80.5%

Security Findings

Info

Centralized Initial Token Distribution

I-01The `Meet` contract's constructor mints the entire `maxSupply` and distributes it to nine predefined addresses. This design choice results in a highly centralized initial token distribution, where a significant portion of the total supply is held by a small number of entities. While not a direct code vulnerability, it introduces a potential economic risk (7.4 Economic) if these addresses are compromised or act maliciously.
IssueThe `Meet` contract's constructor mints the entire `maxSupply` and distributes it to nine predefined addresses. This design choice results in a highly centralized initial token distribution, where a significant portion of the total supply is held by a small number of entities. While not a direct code vulnerability, it introduces a potential economic risk (7.4 Economic) if these addresses are compromised or act maliciously.
FixProject stakeholders should be aware of the implications of this centralized distribution. Implement robust security measures for the private keys controlling these initial recipient addresses. Consider multi-signature wallets or cold storage for significant holdings.
StatusUnresolved
Info

Immutability and Lack of Upgradeability

I-02The `Meet` contract is deployed as an immutable contract and does not incorporate any upgradeability patterns (7.7 Upgrades). This means that once deployed, its logic cannot be modified or patched. While this provides certainty and eliminates upgrade-related risks, any discovered vulnerabilities or desired feature enhancements would necessitate deploying a new contract and migrating assets, which can be a complex and costly process.
IssueThe `Meet` contract is deployed as an immutable contract and does not incorporate any upgradeability patterns (7.7 Upgrades). This means that once deployed, its logic cannot be modified or patched. While this provides certainty and eliminates upgrade-related risks, any discovered vulnerabilities or desired feature enhancements would necessitate deploying a new contract and migrating assets, which can be a complex and costly process.
FixAcknowledge that the contract's immutability means no future code changes are possible. Ensure thorough testing and auditing are completed pre-deployment to minimize the risk of undiscovered vulnerabilities. Plan for potential migration strategies in case a critical issue arises.
StatusUnresolved
Info

No Administrative Control or Pause Mechanism

I-03The `Meet` contract is a pure ERC-20 token without any additional administrative roles (e.g., `owner`, `pauser`, `minter`) or functions (7.3 Access Control, 7.8 Operations). This means there is no central entity capable of pausing transfers, blacklisting addresses, or performing further minting/burning beyond standard ERC-20 operations. While this decentralizes control and prevents malicious administrative actions, it also means there is no mechanism to respond to emergencies (e.g., a major exploit or hack) by pausing the contract or freezing funds.
IssueThe `Meet` contract is a pure ERC-20 token without any additional administrative roles (e.g., `owner`, `pauser`, `minter`) or functions (7.3 Access Control, 7.8 Operations). This means there is no central entity capable of pausing transfers, blacklisting addresses, or performing further minting/burning beyond standard ERC-20 operations. While this decentralizes control and prevents malicious administrative actions, it also means there is no mechanism to respond to emergencies (e.g., a major exploit or hack) by pausing the contract or freezing funds.
FixUnderstand that the lack of administrative control means the token's operations are entirely permissionless after deployment. This design choice prioritizes decentralization over emergency response capabilities. Ensure the project's risk management strategy accounts for this immutability of control.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The `Meet` contract is a straightforward ERC-20 implementation, leveraging the highly secure and audited OpenZeppelin `ERC20` library (7.2 Code Security). This significantly reduces the risk of common vulnerabilities like reentrancy or integer overflows. The contract's architecture (7.1 Architecture) is simple, with all token minting occurring solely within the constructor, ensuring a fixed total supply and preventing unauthorized inflation. There are no complex external interactions or administrative functions (7.3 Access Control), further simplifying the attack surface.

GovernanceHigh2/10

The token's economic model (7.4 Economic) is simple: a fixed total supply of 4.8 billion tokens, with all tokens minted and distributed to nine specific addresses during deployment. This ensures no further inflation or deflation mechanisms are possible. While this initial distribution centralizes a significant portion of the supply among these addresses, the contract itself lacks any governance mechanisms (7.5 Governance) or administrative controls that could be exploited. The immutability of the contract also prevents any future changes to its economic rules.

UpgradesMedium6/10

The `Meet` contract is not designed to be upgradeable (7.7 Upgrades). It is deployed as a standard, immutable contract, meaning its logic cannot be altered post-deployment. This eliminates all risks associated with upgrade mechanisms, such as proxy implementation bugs or malicious upgrade paths. While this provides certainty, it also means any discovered vulnerabilities would require a new contract deployment and migration, which can be a complex process.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

12.1% in wallets68.4% in contracts
Effective Concentration39.5%

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

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

Deployer
0x07af…9d9d
Unlocked LP Held By
0xd782…d5dc0x6458…2df5

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (80.5% total → 39.5% effective; 12.1% in EOAs, 68.4% in contracts — moderate)
  • 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)

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

binanceus doodles (BOODLES)Medium RiskMarsCoinMedium RiskChainGPT (CGPT)Medium RiskZygoSwap (ZSWAP)Medium RiskThe Final Form Bull (CZ)Medium RiskSIRENMedium Risk

Would You Like a More Detailed Audit of MEET48 Token?

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

Get Detailed Audit