| Risk factor | Finding | Evidence | Date |
|---|---|---|---|
| Sellable | Yes | Transfer simulation | 5 Sept 2026 |
| Buy tax | No data | Contract | 5 Sept 2026 |
| Sell tax | No data | Contract | 5 Sept 2026 |
| Admin mint | Enabled | Contract | 5 Sept 2026 |
| Transfers pausable | Not present | Contract | 5 Sept 2026 |
| Address blacklist | Not present | Contract | 5 Sept 2026 |
| Upgradeable proxy | No | Contract | 5 Sept 2026 |
| Source verified | Yes | Block explorer | 5 Sept 2026 |
| Top-10 holders | 100% | Holder distribution | 5 Sept 2026 |
| Liquidity locked | No | LP holders | 5 Sept 2026 |
| Holders | 59 | Token contract | 5 Sept 2026 |
| Deployed by | 0xe3bde2…c5ed92 |
| Current owner | 0x27b7b7…50b5b0 |
| Holders | 59 |
| Rank | Address | Share |
|---|---|---|
| #1 | 0x2212dd…3fad94 | 49.05% |
| #2 | 0x3be6c6…516363 | 46.50% |
| #3 | 0x26c244…af3bdf | 3.48% |
| #4 | 0x0e7643…5ae3cc | 0.52% |
| #5 | 0x278d85…6ef8d2 | 0.35% |
This automated check of DGAI on Arbitrum found several contract-level conditions worth understanding before deciding anything. The mint function being enabled means the contract owner retains the ability to create new tokens at will, which can dilute existing holders' share of supply at any time — this is a mechanical capability, not a statement that it will be used. Top-10 wallets holding 100% of supply means a very small number of addresses control the entire circulating amount, so coordinated selling or a single large wallet moving funds could affect the market significantly. Liquidity not being locked means whoever provided the trading pool can withdraw it, which would make the token difficult or impossible to sell at that point. On the other side, no honeypot behaviour was detected in the sell simulation, meaning a test transaction was able to complete, and the contract source code is verified on the block explorer, so its logic is publicly readable rather than hidden. No pausable transfer function or blacklist mechanism was detected on the date of this check, and no upgradeable proxy pattern was found, meaning the logic is not set up to be swapped out after deployment as far as this scan could determine.
It's worth being clear about what this check does not cover. This is an automated read of contract mechanics only — it looks at what the code technically permits, not at who is behind the project, how tokens are distributed among the team, what the stated use of funds is, or whether any legal entity stands behind the token. A contract can score well on these mechanical checks while still carrying full risk from concentrated ownership, an anonymous team, or business circumstances that no contract scan can detect. Nothing here speaks to intent, and nothing here should be read as a judgement on the people or organisation behind DGAI.
Before considering any action, it would be worth looking directly at the liquidity pool on-chain to confirm who holds it and whether it can be withdrawn unilaterally, checking whether the top holder wallets show any history of prior token launches or large sequential sell-offs, and looking for any public team identity, audit, or documentation tied to the project. It's also worth reviewing the contract's mint function directly on the explorer to see if there are any caps or timelocks on its use. Cross-referencing holder counts and concentration over time, rather than at a single snapshot, can also help show whether concentration is increasing or decreasing.
Contracts change after they are checked. Tell us where to reach you and we will say when this one does. Free for three contracts, no account.
We checked 18 points out of 100.
The other 82 are where money is usually lost: who the team is, where the tokens sit, what the documents actually say, and what the project chose not to put on its front page.