| Risk factor | Finding | Evidence | Date |
|---|---|---|---|
| Sellable | Yes | Transfer simulation | 19 Aug 2026 |
| Buy tax | 0% | Contract | 19 Aug 2026 |
| Sell tax | 0% | Contract | 19 Aug 2026 |
| Admin mint | Not present | Contract | 19 Aug 2026 |
| Transfers pausable | Not present | Contract | 19 Aug 2026 |
| Address blacklist | Not present | Contract | 19 Aug 2026 |
| Upgradeable proxy | No | Contract | 19 Aug 2026 |
| Source verified | Yes | Block explorer | 19 Aug 2026 |
| Top-10 holders | 51.6% | Holder distribution | 19 Aug 2026 |
| Holders | 390382 | Token contract | 19 Aug 2026 |
This automated check on UNI scored 14 out of 18, based on reading the contract's code and current on-chain state — it does not reflect any human review or judgement. In practical terms, the findings indicate that a sell simulation completed successfully, with no buy or sell tax detected, meaning the contract did not appear to block or penalise transfers at the time of the check. No admin minting function was found, which would otherwise let the contract owner create new tokens and dilute existing holders. No pause mechanism was detected, so the ability to freeze all transfers site-wide was not identified. No blacklist function was found either, which would otherwise allow specific wallets to be blocked from selling. The contract is also not upgradeable through a proxy pattern, meaning the underlying logic cannot be silently swapped out after deployment. Source code is verified on the block explorer, so the logic being checked is the same logic that is publicly readable.
One point worth flagging is that the top 10 holders control 51.6% of the total supply. This is a concentration indicator, not a mechanics flaw — it means a small number of wallets hold enough tokens that large sales or transfers by any of them could materially affect available liquidity and price, independent of anything the contract code does.
It's important to be clear about what this check does not cover. This is a purely mechanical read of the contract: what functions exist, whether they were triggered in a simulated transfer, and what the code permits the owner or deployer to do. It says nothing about who the team behind the token is, whether they have a track record, how tokens were originally distributed or vested, what legal entity if any stands behind the project, or whether liquidity pools are locked and for how long. Intent cannot be inferred from bytecode — a clean mechanical result does not mean a project is trustworthy, and flags do not mean it isn't. These are separate questions this tool is not built to answer.
Before putting money into any token, it's worth looking into who controls the deployer and admin wallets and whether those keys are held by a multisig or a single address, checking whether liquidity is locked and for what duration, reviewing the project's public documentation and any audits from independent firms, and looking at how concentrated ownership is beyond the top 10 wallets shown here. Cross-referencing holder addresses against known exchange or team wallets can also help clarify whether high concentration reflects centralised risk or simply reflects exchange custody balances.