Early-stage security check — honeypot & rug-pull analysis
BNB ChainThe DGAI token contract is a standard ERC-20 implementation with a fixed maximum supply and an owner-controlled minting function.
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x3be6…63630x556b…d59e0x4219…3be5No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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).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).
Implement 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.
Unresolved
_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.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.
If 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.
Unresolved
^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).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).
Ensure 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.
Unresolved
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.
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.
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.
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.
The DGAI token contract is technically sound due to its reliance on OpenZeppelin standards.
The primary area for consideration is the centralized control over token minting. While the use of a multisig owner mitigates some risks, the project should clearly communicate its minting strategy and any associated governance processes to its community to ensure transparency and trust. Future enhancements could include exploring decentralized governance mechanisms for minting or introducing a public burn function if desired.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.
Get Detailed Audit Is this your token? Publish your own audit on this page
