On-chain security analysis — is it a scam or legit?
The DGAIPeer contract implements an ERC20 token with minting and burning capabilities.
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.
0xe21a…6183No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
minter role has the exclusive authority to mint new tokens up to the maxSupply. While the setMinter function is restricted to the contract owner (a multisig, per prefill), the minter address itself represents a single point of failure for token supply control. A compromise of the minter's private key could lead to unauthorized and rapid inflation of the token supply, devaluing existing tokens.H-01The minter role has the exclusive authority to mint new tokens up to the maxSupply. While the setMinter function is restricted to the contract owner (a multisig, per prefill), the minter address itself represents a single point of failure for token supply control. A compromise of the minter's private key could lead to unauthorized and rapid inflation of the token supply, devaluing existing tokens.
Implement robust operational security for the minter address. This could involve using a multi-signature wallet for the minter role itself, or a hardware security module. Additionally, consider adding a timelock mechanism to the setMinter function, allowing for a delay before a new minter becomes active, providing a window to react to malicious changes.
Unresolved
INITIAL_AUTHORITY address (0xE3bd…ED92) is hardcoded in the contract's constructor. While this is a standard practice for Ownable contracts, it means the initial ownership is fixed at deployment. If the intention was for a different entity (e.g., a specific multisig) to immediately take ownership, a transfer of ownership would be required post-deployment. The prefill data indicates the current owner is a different multisig address (0x27b7…b5b0), suggesting this transfer likely occurred.L-01The INITIAL_AUTHORITY address () is hardcoded in the contract's constructor. While this is a standard practice for Ownable contracts, it means the initial ownership is fixed at deployment. If the intention was for a different entity (e.g., a specific multisig) to immediately take ownership, a transfer of ownership would be required post-deployment. The prefill data indicates the current owner is a different multisig address (), suggesting this transfer likely occurred.
Ensure that the hardcoded INITIAL_AUTHORITY is the intended initial owner. If the final desired owner is different, verify that the ownership transfer to the correct entity (e.g., a secure multisig) was successfully executed immediately after deployment. Document this post-deployment step clearly in operational procedures.
Unresolved
maxSupply is set to 1,000,000,000 ether (1e27 wei). While this value acts as a hard cap on the total token supply, it is a very large number. This allows for significant potential inflation if the minter role is actively used to mint tokens up to this limit. The economic implications of such a large potential supply should be clearly understood and communicated to token holders.I-01The maxSupply is set to 1,000,000,000 ether (1e27 wei). While this value acts as a hard cap on the total token supply, it is a very large number. This allows for significant potential inflation if the minter role is actively used to mint tokens up to this limit. The economic implications of such a large potential supply should be clearly understood and communicated to token holders.
Ensure that the economic model and implications of a potentially very large token supply are well-documented and transparently communicated to the community and token holders. Consider if this maxSupply aligns with the long-term vision and utility of the token, and if a smaller, more constrained supply might be more appropriate for certain economic models.
Unresolved
The DGAIPeer contract implements an ERC20 token with minting and burning capabilities. It utilizes OpenZeppelin's battle-tested libraries for core functionalities and access control. The contract features a maxSupply to cap total token issuance and a dedicated minter role. The audit identified a High-severity risk related to the centralized minter role, alongside a Low-severity and an Informational finding.
The technical architecture (7.1) is a standard ERC20 implementation, leveraging well-audited OpenZeppelin contracts, which enhances code security (7.2). The mint function includes a maxSupply check, preventing over-issuance beyond the defined limit. However, the minter role, while protected by onlyMinter (7.3), holds significant power to inflate the supply up to the maximum, posing a centralization risk if compromised.
The contract employs an Ownable pattern (7.5), with the owner (a multisig, per prefill) having control over setting the minter. This centralized control over the minter role introduces an economic risk (7.4) as a compromised minter could rapidly inflate the token supply up to the maxSupply. The maxSupply itself is a very large value (1 billion ether), allowing for substantial potential inflation if the minter is misused.
The DGAIPeer contract is not designed to be upgradeable (7.7), which eliminates risks associated with proxy patterns, upgradeability logic, and potential upgrade path vulnerabilities. This provides a fixed and immutable contract logic post-deployment, ensuring predictable behavior and reducing future operational overhead for upgrades.
Implement robust operational security measures for the minter address, such as multi-signature wallets or hardware security modules, to mitigate the risk of unauthorized token minting.
Consider adding a timelock for the setMinter function to provide a delay for critical changes, enhancing security and transparency. Clearly communicate the economic implications of the large maxSupply to token holders to manage expectations regarding potential token inflation.
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.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
