Quantum Audit Logo
Launch App

Is MEGA YACHT CULT a Scam?

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

MEGA YACHT CULT MYC
0xccb6…ea4d
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 today 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The MegaYachtCult contract is an ERC-20 token with advanced features including taxation, fee distribution, and reentrancy protection. The contract exhibits a high degree of centralized control, with the owner having extensive power over critical parameters such as swap routers, liquidity ownership, and fee configurations. Key findings include the owner's ability to replace critical external contracts, control transfer switches, and modify transfer fees, alongside a reentrancy vulnerability in the `_transfer` function and potential rounding issues.

2 High3 Medium2 Low5 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
$30.8K
Liquidity
$83.6K
Price
$0.001659
Token Age
1d
Top 10 Holders
56.4%

Security Findings

2 High3 Med2 Low5 Info
High

Owner can change critical external contracts, affecting how tokens are swapped or managed.

CP-03The owner of the MegaYachtCult token has the power to change the addresses of external contracts that are crucial for token operations. Specifically, the `setSwapRouter` function allows the owner to replace the contract used for swapping tokens, and `setLiquidityOwner` allows changing the address responsible for liquidity. If these addresses are changed to malicious contracts, it could lead to funds being misdirected or token transfers failing.
IssueThe owner of the MegaYachtCult token has the power to change the addresses of external contracts that are crucial for token operations. Specifically, the `setSwapRouter` function allows the owner to replace the contract used for swapping tokens, and `setLiquidityOwner` allows changing the address responsible for liquidity. If these addresses are changed to malicious contracts, it could lead to funds being misdirected or token transfers failing.
FixToken holders should be aware that the owner can unilaterally change these critical external contracts. Consider advocating for these functions to be controlled by a multi-signature wallet or a time-locked mechanism to prevent immediate, unauthorized changes.
StatusUnresolved
High

Who holds the supply

QA-HOLDERSThe ten largest holders own 56.4% of supply. Of that, 6.8% in DEX pools — not holders that can sell, so excluded from the concentration score. What remains: 38.3% in wallets, 11.3% in other contracts. The deployer/owner wallet itself holds 26.2%. A holder that also controls the contract can sell into its own liquidity. 1,860 holders in total.
IssueThe ten largest holders own 56.4% of supply. Of that, 6.8% in DEX pools — not holders that can sell, so excluded from the concentration score. What remains: 38.3% in wallets, 11.3% in other contracts. The deployer/owner wallet itself holds 26.2%. A holder that also controls the contract can sell into its own liquidity. 1,860 holders in total.
FixWatch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
StatusAcknowledged
Medium

Risk of reentrancy during token transfers involving ETH.

CD-02The `_transfer` function, which handles token movements, might update its internal state *after* making an external call that sends ETH. This creates a reentrancy vulnerability. If a malicious contract receives ETH from this function, it could call back into the `_transfer` function before the initial transaction's state is fully updated, potentially leading to repeated withdrawals or other unintended behavior.
IssueThe `_transfer` function, which handles token movements, might update its internal state *after* making an external call that sends ETH. This creates a reentrancy vulnerability. If a malicious contract receives ETH from this function, it could call back into the `_transfer` function before the initial transaction's state is fully updated, potentially leading to repeated withdrawals or other unintended behavior.
FixThis is a critical security vulnerability. The project team should ensure that all state changes in the `_transfer` function are completed *before* any external calls are made, following the Checks-Effects-Interactions pattern. The `nonReentrant` guard should be applied to all functions that perform external calls and modify state.
StatusUnresolved
Medium

Owner can stop or start fee processing, impacting token transfers.

CP-05The owner can use the `processFees` function to control whether fees are processed during token transfers. This acts as a switch that can enable or disable a core part of the token's economic mechanism. If fee processing is stopped, it could disrupt the intended fee collection and distribution, potentially affecting the token's value or functionality.
IssueThe owner can use the `processFees` function to control whether fees are processed during token transfers. This acts as a switch that can enable or disable a core part of the token's economic mechanism. If fee processing is stopped, it could disrupt the intended fee collection and distribution, potentially affecting the token's value or functionality.
FixToken holders should understand that the owner has direct control over this fee processing switch. Transparency regarding the use of this function is important. Consider if this control should be subject to a community vote or a time-lock.
StatusUnresolved
Medium

Owner can change token transfer fees and how they are distributed.

CP-07The owner has the ability to modify the fees applied to token transfers and how these fees are collected. Functions like `addFeeCollector`, `removeFeeCollector`, and `updateFeeCollectorShare` allow the owner to add new addresses to collect fees, remove existing ones, or change the percentage of fees each collector receives. This means the owner can unilaterally alter the token's fee structure, potentially increasing fees or redirecting them to different addresses.
IssueThe owner has the ability to modify the fees applied to token transfers and how these fees are collected. Functions like `addFeeCollector`, `removeFeeCollector`, and `updateFeeCollectorShare` allow the owner to add new addresses to collect fees, remove existing ones, or change the percentage of fees each collector receives. This means the owner can unilaterally alter the token's fee structure, potentially increasing fees or redirecting them to different addresses.
FixToken holders should be aware that the owner can change the fee structure at any time. It is important for the project to clearly communicate any changes to fees or fee collectors. Consider proposing a governance mechanism for fee changes.
StatusUnresolved
Low

Potential for small rounding losses in fee calculations.

CD-01In functions like `_processFees` and `_transfer`, calculations involving fees might perform division before multiplication. This order of operations can lead to minor rounding errors, where a very small amount of tokens might be lost or gained due to integer arithmetic. While typically small, these losses can accumulate over many transactions.
IssueIn functions like `_processFees` and `_transfer`, calculations involving fees might perform division before multiplication. This order of operations can lead to minor rounding errors, where a very small amount of tokens might be lost or gained due to integer arithmetic. While typically small, these losses can accumulate over many transactions.
FixWhile the impact is usually minimal, it's best practice to perform multiplication before division in Solidity to minimize rounding errors. This ensures more precise calculations for token amounts and fees.
StatusUnresolved
Low

Owner can change the amount of tokens swapped at once.

CP-08The owner can use the `setNumTokensToSwap` function to change the maximum number of tokens that can be swapped in a single transaction. This limit directly affects the token's trading mechanics and liquidity management. While this control can be used for operational efficiency, it also means the owner can unilaterally impose restrictions on trading volume.
IssueThe owner can use the `setNumTokensToSwap` function to change the maximum number of tokens that can be swapped in a single transaction. This limit directly affects the token's trading mechanics and liquidity management. While this control can be used for operational efficiency, it also means the owner can unilaterally impose restrictions on trading volume.
FixToken holders should be aware that the owner can adjust this trading limit. Transparency about the rationale for any changes to this limit is beneficial.
StatusUnresolved
Info

Not listed by any independent source

QA-IDENTITY1,860 holders. Not listed by CoinGecko or any exchange GoPlus tracks. Nothing independent confirms who is behind this token, so every power its contract grants is scored at face value.
Issue1,860 holders. Not listed by CoinGecko or any exchange GoPlus tracks. Nothing independent confirms who is behind this token, so every power its contract grants is scored at face value.
FixMatch the contract address against the project's official channels before trading.
StatusAcknowledged
Info

Liquidity locked, lock term not visible

QA-LIQUIDITY98.1% of the pool's LP is burned or time-locked. 98.1% is held by UNCX, but the lock's end date is not published in the data we can read — its duration is unverified. 0.8% is held, unlocked, by the token's owner/deployer (0xa79d…760f) — they can pull that liquidity at any moment. This is the rug-pull path. 1.1% is held, unlocked, by 1 address(es) other than the owner/deployer. No single one holds a majority: their exits thin the market rather than hand anyone the pool.
Issue98.1% of the pool's LP is burned or time-locked. 98.1% is held by UNCX, but the lock's end date is not published in the data we can read — its duration is unverified. 0.8% is held, unlocked, by the token's owner/deployer (0xa79d…760f) — they can pull that liquidity at any moment. This is the rug-pull path. 1.1% is held, unlocked, by 1 address(es) other than the owner/deployer. No single one holds a majority: their exits thin the market rather than hand anyone the pool.
FixCheck the lock's end date and beneficiary on the locker's own page before relying on it.
StatusAcknowledged
Info

The market for this token

QA-MARKETLiquidity $84K (DexScreener, all pools). 24h trading volume $31K (DexScreener, all pools).
IssueLiquidity $84K (DexScreener, all pools). 24h trading volume $31K (DexScreener, all pools).
FixSize any position to the liquidity and daily volume shown — they set how much you can sell and at what price.
StatusAcknowledged
Info

Asset class: Project token

QA-PROFILEA token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: fixed — the contract has no mint function. Control: a single wallet (EOA). Code: not upgradeable (no proxy). Fees: 0% on buy, 5% on sell. Market: $84K of DEX liquidity across 1 pools. Launch: 1 days of market history.
IssueA token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: fixed — the contract has no mint function. Control: a single wallet (EOA). Code: not upgradeable (no proxy). Fees: 0% on buy, 5% on sell. Market: $84K of DEX liquidity across 1 pools. Launch: 1 days of market history.
FixCheck the project's own documentation for what the token is used for; this report covers what the contract allows.
StatusAcknowledged
Info

Recently launched — 1 day of market history

QA-RECENTThe token's oldest DEX pool is 1 day old. Age is not part of the risk score — a new token is not a risky one by default — but a short history means fewer trades and holder changes behind the facts in this report.
IssueThe token's oldest DEX pool is 1 day old. Age is not part of the risk score — a new token is not a risky one by default — but a short history means fewer trades and holder changes behind the facts in this report.
FixRe-check ownership, liquidity and holder distribution as the token matures; those are the facts that move early.
StatusAcknowledged

Category Ratings

TechnicalMedium6/10

The MegaYachtCult token incorporates robust features like ERC20Votes, ERC20Permit, and a ReentrancyGuard, enhancing its functionality and basic security posture (7.2 Code Security). However, the contract's architecture grants the owner significant control over critical operational parameters (7.1 Architecture, 7.3 Access Control). For instance, the owner can change the `swapRouter` and `liquidityOwner` via `setSwapRouter` and `setLiquidityOwner`, which could redirect token logic or funds. A notable technical vulnerability is the reentrancy risk identified in the `_transfer` function, where state updates occur after an external call, potentially allowing re-entry (7.2 Code Security).

GovernanceHigh3/10

The economic model of the MegaYachtCult token is highly centralized, with the owner retaining extensive control over key financial mechanisms (7.4 Economic, 7.5 Governance). The owner can dynamically adjust transfer fees by calling `addFeeCollector`, `removeFeeCollector`, or `updateFeeCollectorShare`, and can also enable or disable fee processing through `processFees`. This centralized control, while offering flexibility, introduces a significant governance risk as the owner can unilaterally alter the token's economic behavior, potentially impacting token holders' expectations and value (7.5 Governance).

UpgradesMedium6/10

The MegaYachtCult contract is not designed as an upgradeable proxy, meaning its core logic cannot be changed after deployment (7.7 Upgrades). This provides immutability for the contract's fundamental code. However, the owner retains the ability to modify numerous critical operational and economic parameters, such as `setSwapRouter` or `setTaxRates`, which can significantly alter the contract's behavior and economic impact without a full contract upgrade (7.8 Operations).

Security Checklist

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

Holder Composition

56.4% in top 10
38.3% in wallets11.3% in contracts
Effective Concentration42.8%

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

$83.6K

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 Locked98.1% · Null Address, UNCX
Top-1 Unlocked Holder1.0%

Key Addresses

4 addresses
Deployer
0xa79d…760f
Unlocked LP Held By
0xd45d…dc1c0xa79d…760f0x9bd2…168c

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

7 factors
  • A privileged address can replace a contract every transfer depends on
  • A privileged address controls a switch that decides whether transfers go through
  • Owner can change the buy/sell tax
  • A privileged address can change transfer or wallet limits
  • Top-10 concentration > 30% (56.4% total → 42.8% effective; 38.3% in EOAs, 11.3% in contracts; 6.8% burned, locked or in pools excluded; deployer/owner holds 26.2%)
  • Code: Potential for small rounding losses in fee calculations. (Low, static analysis)
  • Code: Risk of reentrancy during token transfers involving ETH. (Medium, static analysis)

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
ChipHigh Riskdefi-nativeHigh RiskXRP (Universal) (UXRP)High RiskVCATHigh RiskWrapped PROS (PROS)High RiskCortex (CX)High Risk

Would You Like a More Detailed Audit of MEGA YACHT CULT?

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

Get Detailed Audit