Is DGrid AI (DGAI) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Low1 Info

High

Centralized Minter Role Poses Inflation Risk

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.

IssueThe `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.

FixImplement 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.

StatusUnresolved

Low

Hardcoded Initial Authority Address

L-01The `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.

IssueThe `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.

FixEnsure 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.

StatusUnresolved

Info

High Maximum Token Supply

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.

IssueThe `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.

FixEnsure 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.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh1/10

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.

UpgradesMedium4/10

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.

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

100.0% in top 10

50.4% in wallets49.6% in contracts

Effective Concentration70.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

$242.0K

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

2 addresses

Deployer

0xe3bd…ed92

Unlocked LP Held By

0xe21a…6183

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

What Raised This Score

9 factors

Ownership NOT renounced — Multisig (2-of-3)
Mintable supply, nominal cap 542545%/year — effectively unbounded
Top-10 concentration > 70% (100.0% total → 70.3% effective; 50.4% in EOAs, 49.6% in contracts — extreme)
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 < 30 days (still settling)
1 High 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

Is DGrid AI Safe?

Security Findings

Centralized Minter Role Poses Inflation Risk

Hardcoded Initial Authority Address

High Maximum Token Supply

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of DGrid AI?