Quantum Audit Logo

Is DGrid AI a Scam?

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

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

DGrid AI DGAI
0x10d4…bd5e
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 6d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DGAI token contract is a standard ERC-20 implementation with a fixed maximum supply and an owner-controlled minting function. The contract leverages battle-tested OpenZeppelin libraries, contributing to its technical robustness. The primary risk identified is the centralized control over token minting, although this is mitigated by the owner being a 2/3 multisig wallet. No critical vulnerabilities were found.

1 Medium2 Informational
! Early-stage analysis. This token has limited on-chain history (6d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$9.86M
Liquidity
$2.80M
Price
$0.7791
Token Age
6d
Top 10 Holders
98.1%

Security Findings

1 Med2 Info
Medium

Centralized Control Over Token Minting

M-01The `mint` function in the DGAI contract is restricted to the contract owner via the `onlyOwner` modifier. This grants the owner exclusive control over the issuance of new tokens up to the `maxSupply`. While the `maxSupply` provides a hard cap, the timing and recipient of new tokens are entirely at the owner's discretion. This centralization, even with a multisig owner, could lead to concerns regarding potential market manipulation or unfair distribution if not managed transparently (7.3 Access Control, 7.4 Economic, 7.5 Governance).
IssueThe `mint` function in the DGAI contract is restricted to the contract owner via the `onlyOwner` modifier. This grants the owner exclusive control over the issuance of new tokens up to the `maxSupply`. While the `maxSupply` provides a hard cap, the timing and recipient of new tokens are entirely at the owner's discretion. This centralization, even with a multisig owner, could lead to concerns regarding potential market manipulation or unfair distribution if not managed transparently (7.3 Access Control, 7.4 Economic, 7.5 Governance).
FixImplement robust off-chain governance and transparency mechanisms for all minting operations. Clearly communicate the minting schedule, purpose, and recipients to the community. Consider exploring future decentralization of the minting process, perhaps through a time-locked contract or a community-governed mechanism, if the project's roadmap allows. Ensure the multisig owner remains secure and its signers are trustworthy.
StatusUnresolved
Info

No Public Burn Function

I-01The DGAI contract, while inheriting the internal `_burn` function from OpenZeppelin's ERC20, does not expose a public function for users to burn their tokens. This means individual token holders cannot directly reduce the total supply or their own balance through a burning mechanism (7.4 Economic). This is a design choice and not a vulnerability, but it limits a common utility found in some ERC-20 tokens.
IssueThe DGAI contract, while inheriting the internal `_burn` function from OpenZeppelin's ERC20, does not expose a public function for users to burn their tokens. This means individual token holders cannot directly reduce the total supply or their own balance through a burning mechanism (7.4 Economic). This is a design choice and not a vulnerability, but it limits a common utility found in some ERC-20 tokens.
FixIf a burning mechanism is desired for future utility or supply management, consider adding a public `burn` function that allows token holders to destroy their own tokens. This could be implemented with a simple wrapper around the inherited `_burn` function.
StatusUnresolved
Info

High Solidity Compiler Version

I-02The contract uses Solidity compiler version `^0.8.28`, which is a very recent release. While newer versions often include security enhancements and optimizations, extremely new versions might have limited tooling support, or unexpected interactions with older libraries or development environments (7.2 Code Security).
IssueThe contract uses Solidity compiler version `^0.8.28`, which is a very recent release. While newer versions often include security enhancements and optimizations, extremely new versions might have limited tooling support, or unexpected interactions with older libraries or development environments (7.2 Code Security).
FixEnsure all development tools, testing frameworks, and deployment environments are fully compatible with Solidity 0.8.28. Monitor for any known issues or breaking changes that might emerge with this compiler version in the broader ecosystem.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The DGAI contract is a straightforward ERC-20 token (7.1 Architecture) built upon OpenZeppelin's secure and audited libraries, including ERC20 and Ownable. The code (7.2 Code Security) is minimal, well-structured, and adheres to common Solidity best practices, with no apparent reentrancy, integer overflow/underflow, or other common technical vulnerabilities. The `mint` function correctly checks against `maxSupply` to prevent over-issuance. The use of a very recent Solidity compiler version (`^0.8.28`) ensures access to the latest security features and optimizations.

GovernanceHigh3/10

The contract implements a fixed `maxSupply` for the token, providing a clear cap on total issuance (7.4 Economic). However, the `mint` function is controlled solely by the contract owner (7.3 Access Control), allowing the owner to mint tokens up to the `maxSupply` at their discretion. While the owner is a 2/3 multisig, which mitigates single-point-of-failure risk, this centralized minting capability represents a significant economic control point (7.5 Governance). There is no public burn mechanism for users, which is a design choice that may limit certain token functionalities.

UpgradesMedium6/10

The DGAI contract is not designed as an upgradeable proxy (7.7 Upgrades). This eliminates the risks associated with proxy patterns, such as upgradeability pauses, storage collisions, or logic bugs introduced during upgrades. The contract's logic is immutable once deployed, providing certainty regarding its long-term behavior.

Security Checklist

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

Holder Composition

98.1% in top 10
2.8% in wallets95.4% in contracts
Effective Concentration40.9%

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

$2.80M

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

4 addresses
Deployer
0xe3bd…ed92
Unlocked LP Held By
0x3be6…63630x556b…d59e0x4219…3be5

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

What Raised This Score

8 factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30% (98.1% total → 40.9% effective; 2.8% in EOAs, 95.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)
  • Token age < 7 days (early, volatile)
  • 1 Medium 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
Baby Ansem (BABYANSEM)High RiskEVAAHigh RiskBubblemaps (BMT)High RiskPIZZAHigh RiskStupid Kid (傻孩子)High RiskChainOpera AI (COAI)High Risk

Would You Like a More Detailed Audit of DGrid AI?

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

Get Detailed Audit