Quantum Audit Logo

Is Yooldo Games Safe?

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

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

Yooldo Games ESPORTS
0xf39e…8e48
BNB Chain Not verifiedLast checked 3d ago 2 audits on record
Executive SummaryAI Copilot

The YooldoToken contract is an ERC20 token built on OpenZeppelin standards, incorporating burnable, pausable, permit, and voting functionalities. It introduces custom logic for freezing/unfreezing accounts. The contract exhibits strong technical security due to its reliance on audited libraries, but presents medium economic and governance risks due to the high degree of centralized control held by the owner, despite the use of a multisig.

1 High1 Medium1 Low1 Informational
Volume 24h
$200.5K
Liquidity
$76.0K
Price
$0.01445
Token Age
1y
Top 10 Holders
75.3%

Security Findings

High

Centralized Control by Owner

H-01The `Ownable` contract grants significant power to a single address (or multisig) to control critical token functionalities. The owner can `pause` all token transfers, `freezeAccount` or `unfreezeAccount` any address, and `burn` tokens. While the use of a multisig mitigates some risk, a compromise or malicious act by the owner could severely impact token functionality, user funds, and the overall ecosystem (7.3 Access Control, 7.4 Economic, 7.8 Operations).
IssueThe `Ownable` contract grants significant power to a single address (or multisig) to control critical token functionalities. The owner can `pause` all token transfers, `freezeAccount` or `unfreezeAccount` any address, and `burn` tokens. While the use of a multisig mitigates some risk, a compromise or malicious act by the owner could severely impact token functionality, user funds, and the overall ecosystem (7.3 Access Control, 7.4 Economic, 7.8 Operations).
FixWhile centralization is a design choice for this token, consider implementing a multi-signature wallet with a high threshold for the owner address. Additionally, explore community governance mechanisms for critical decisions in the future. Ensure robust security practices for the owner's private keys or multisig setup.
StatusUnresolved
Medium

Lack of Timelock for Critical Operations

M-01Critical owner-controlled functions such as `pause`, `unpause`, `freezeAccount`, `unfreezeAccount`, and `transferOwnership` can be executed immediately by the owner. The absence of a timelock means there is no delay for sensitive operations, preventing users from reacting to potentially malicious or erroneous actions and reducing transparency (7.3 Access Control, 7.5 Governance, 7.8 Operations).
IssueCritical owner-controlled functions such as `pause`, `unpause`, `freezeAccount`, `unfreezeAccount`, and `transferOwnership` can be executed immediately by the owner. The absence of a timelock means there is no delay for sensitive operations, preventing users from reacting to potentially malicious or erroneous actions and reducing transparency (7.3 Access Control, 7.5 Governance, 7.8 Operations).
FixImplement a timelock mechanism for all critical owner-controlled functions. This would introduce a mandatory delay between the owner initiating an action and its actual execution, providing a window for review and reaction by the community or other stakeholders.
StatusUnresolved
Low

Unused Modifier `notFrozen`

L-01The `notFrozen` modifier is defined in the `YooldoToken` contract but is not utilized in any function. The logic for checking frozen accounts is directly implemented within the `_update` function. While this does not introduce a vulnerability, the presence of an unused modifier can lead to confusion and suggests potential for code cleanup or refactoring (7.2 Code Security).
IssueThe `notFrozen` modifier is defined in the `YooldoToken` contract but is not utilized in any function. The logic for checking frozen accounts is directly implemented within the `_update` function. While this does not introduce a vulnerability, the presence of an unused modifier can lead to confusion and suggests potential for code cleanup or refactoring (7.2 Code Security).
FixRemove the unused `notFrozen` modifier to improve code clarity and maintainability, or integrate it into relevant functions if its intended use was overlooked. The current implementation in `_update` is correct and sufficient.
StatusUnresolved
Info

Non-Upgradeable Contract

I-01The `YooldoToken` contract is deployed directly and does not implement an upgrade mechanism (e.g., proxy pattern). This means the contract's logic is immutable once deployed to the blockchain. While this avoids upgrade-related complexities and risks, it implies that any future bug fixes, feature enhancements, or changes to the token's core logic would necessitate deploying a new contract and migrating the token supply, which can be a complex and disruptive process (7.7 Upgrades).
IssueThe `YooldoToken` contract is deployed directly and does not implement an upgrade mechanism (e.g., proxy pattern). This means the contract's logic is immutable once deployed to the blockchain. While this avoids upgrade-related complexities and risks, it implies that any future bug fixes, feature enhancements, or changes to the token's core logic would necessitate deploying a new contract and migrating the token supply, which can be a complex and disruptive process (7.7 Upgrades).
FixAcknowledge the immutability of the contract. For future projects requiring flexibility, consider using an upgradeable proxy pattern (e.g., UUPS) to allow for future logic updates without requiring a token migration. For this contract, ensure thorough testing before deployment given its immutability.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract `YooldoToken` is built upon battle-tested OpenZeppelin ERC20 standards, including `ERC20Burnable`, `ERC20Pausable`, `ERC20Permit`, and `ERC20Votes`. The implementation correctly overrides the `_update` function to enforce custom pausing and account freezing logic (7.2 Code Security). No reentrancy or integer overflow vulnerabilities were identified due to the use of modern Solidity and OpenZeppelin libraries. A minor issue is the presence of an unused `notFrozen` modifier (7.2 Code Security).

GovernanceHigh2/10

The token design grants significant centralized control to the `Ownable` address, which is configured as a multisig (7.3 Access Control). The owner can pause all token transfers, freeze individual accounts, and burn tokens, which introduces a high economic risk if the owner's key is compromised or acts maliciously (7.4 Economic). While a multisig mitigates some of this risk, the absence of a timelock for critical operations means these actions can be executed immediately (7.5 Governance, 7.8 Operations).

UpgradesLow7/10

The `YooldoToken` contract is not designed to be upgradeable (7.7 Upgrades), meaning its logic is immutable once deployed. This eliminates risks associated with proxy patterns, such as storage collisions or incorrect upgrade paths. However, it implies that any future bug fixes or feature enhancements would necessitate a new contract deployment and a potentially complex token migration process.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

35.4% in wallets39.9% 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

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 Holder68.9%
Top-3 Unlocked80.1%

Key Addresses

Deployer
0x30bc…2370
Unlocked LP Held By
0xc7d0…82ad0x5b8e…be530x3bbf…b54a0x8e0a…76c10x31ec…4b5a0xff93…18500xd906…472c0x5c83…35c20xffc6…58010x8fda…2bf3

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

What Raised This Score

  • Ownership NOT renounced — Multisig (3-of-3)
  • Top-10 concentration > 50% (75.3% total → 51.3% effective; 35.4% in EOAs, 39.9% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 68.9% (independent LP — depth risk, pool = 56% of DEX liquidity)
  • LP top3 unlocked holders = 80.1% (independent LP — depth risk, pool = 56% of DEX liquidity)
  • 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

Frequently Asked Questions

Is Yooldo Games a scam?

Based on automated analysis, Yooldo Games scores 67/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Yooldo Games safe to buy?

Our scanner flagged a risk score of 67/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Yooldo Games been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

ChainOpera AI (COAI)High RiskAKEHigh RiskSIXSEVEN (67)High RiskOPENHigh RiskBaby Ansem (BABYANSEM)High RiskEVAAHigh Risk

Would You Like a More Detailed Audit of Yooldo Games?

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

Get Detailed Audit