Quantum Audit Logo

Is Meta Financial AI a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

Meta Financial AI MEFAI
0x1390…2c99
BNB Chain
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.Own this token? Put it under verification →
Last checked today 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The MEFAI contract implements a standard ERC20 token. The contract utilizes a custom ERC20 implementation rather than a battle-tested library. While the custom implementation appears to be robust and correctly handles core ERC20 functionalities, it introduces a higher inherent risk compared to audited, widely-used libraries. The initial supply is minted entirely to the deployer, creating a centralized point of control for token distribution. No critical vulnerabilities were identified.

1 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$38.7K
Liquidity
$274.7K
Price
$0.001318
Token Age
1d
Top 10 Holders
62.4%

Security Findings

1 Low2 Info
Low

Centralized Initial Supply Distribution

L-01The entire `INITIAL_SUPPLY` of 564,249,705 MEFAI tokens is minted to `msg.sender` (the contract deployer) in the constructor. This design centralizes the control of the entire token supply at inception to a single address. Depending on the project's decentralization goals, this could pose a significant centralization risk, as the deployer holds all tokens and dictates their initial distribution.
IssueThe entire `INITIAL_SUPPLY` of 564,249,705 MEFAI tokens is minted to `msg.sender` (the contract deployer) in the constructor. This design centralizes the control of the entire token supply at inception to a single address. Depending on the project's decentralization goals, this could pose a significant centralization risk, as the deployer holds all tokens and dictates their initial distribution.
FixConsider implementing a more distributed initial token allocation strategy. This could involve vesting contracts, multi-signature wallets for holding the initial supply, or a pre-sale/IDO mechanism to distribute tokens among a wider base of participants from the outset. Clearly communicate the distribution plan to the community.
StatusUnresolved
Info

Custom ERC20 Implementation Instead of Battle-Tested Libraries

I-01The contract implements its own ERC20 standard rather than inheriting from widely audited and battle-tested libraries like OpenZeppelin Contracts. While the custom implementation appears to correctly adhere to the ERC20 standard and incorporates modern Solidity features like custom errors and `unchecked` blocks, custom code inherently carries a higher risk of undiscovered vulnerabilities compared to code that has undergone extensive community review and formal verification over time.
IssueThe contract implements its own ERC20 standard rather than inheriting from widely audited and battle-tested libraries like OpenZeppelin Contracts. While the custom implementation appears to correctly adhere to the ERC20 standard and incorporates modern Solidity features like custom errors and `unchecked` blocks, custom code inherently carries a higher risk of undiscovered vulnerabilities compared to code that has undergone extensive community review and formal verification over time.
FixFor future projects or significant updates, consider using established and audited libraries such as OpenZeppelin Contracts for core functionalities like ERC20. If a custom implementation is necessary, ensure it undergoes rigorous testing, including unit tests, integration tests, and potentially formal verification, to achieve a similar level of security assurance.
StatusUnresolved
Info

Fixed Decimals Value

I-02The `decimals()` function is hardcoded to return `18`. While 18 decimals is a common standard for ERC20 tokens, this value is fixed and cannot be changed after deployment. This is standard behavior for most ERC20 tokens but is noted for completeness.
IssueThe `decimals()` function is hardcoded to return `18`. While 18 decimals is a common standard for ERC20 tokens, this value is fixed and cannot be changed after deployment. This is standard behavior for most ERC20 tokens but is noted for completeness.
FixEnsure that the choice of 18 decimals aligns with all project requirements and integrations, as it cannot be altered post-deployment. No direct action is required if 18 decimals is the intended and acceptable standard.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The MEFAI contract is a custom implementation of the ERC20 standard (7.1 Architecture). The code demonstrates good adherence to the ERC20 interface and includes explicit custom error handling, which is a modern Solidity best practice (7.2 Code Security). The use of `unchecked` blocks for arithmetic operations is appropriately placed after necessary checks, preventing integer overflows/underflows while optimizing gas (7.2 Code Security). No reentrancy or other critical technical vulnerabilities were found (7.2 Code Security).

GovernanceHigh3/10

The contract's economic model is straightforward: a fixed `INITIAL_SUPPLY` is minted once during deployment (7.4 Economic). This entire supply is transferred to the contract deployer, establishing a centralized point of control for initial token distribution (7.5 Governance). There are no further minting or burning functions exposed, ensuring a predictable total supply (7.4 Economic).

UpgradesLow7/10

The MEFAI contract is deployed as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates the complexities and potential risks associated with upgrade mechanisms, such as proxy pattern vulnerabilities or administrative key compromises. However, it also means that the contract's logic cannot be modified or patched post-deployment, requiring a new deployment for any future changes.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

62.4% in top 10
44.0% in wallets18.4% in contracts
Effective Concentration51.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

$274.7K

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

LP Locked100.0% · Null Address, PinkLock02

Key Addresses

1 addresses
Deployer
0x503f…6e59

What Raised This Score

4 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 50% (62.4% total → 51.3% effective; 44.0% in EOAs, 18.4% in contracts — heavy)
  • Token age < 7 days (early, volatile)
  • 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
ARKMedium Risk牛来Medium RiskSaturnMedium RiskMax Sister (LILY)Medium RiskTrusta.AI (TA)Medium RiskXPIN Token (XPIN)Medium Risk

Would You Like a More Detailed Audit of Meta Financial AI?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit