| Risk factor | Finding | Evidence | Date |
|---|---|---|---|
| Sellable | No data | Transfer simulation | 26 Oct 2026 |
| Buy tax | 0% | Contract | 26 Oct 2026 |
| Sell tax | No data | Contract | 26 Oct 2026 |
| Admin mint | No data | Contract | 26 Oct 2026 |
| Transfers pausable | No data | Contract | 26 Oct 2026 |
| Address blacklist | No data | Contract | 26 Oct 2026 |
| Upgradeable proxy | No data | Contract | 26 Oct 2026 |
| Source verified | No | Block explorer | 26 Oct 2026 |
| Top-10 holders | 33.3% | Holder distribution | 26 Oct 2026 |
| Liquidity locked | 100% burned | LP holders | 26 Oct 2026 |
| Holders | 1064 | Token contract | 26 Oct 2026 |
| Deployed by | 0xb2f749…a092f9 |
| Holders | 1,064 |
| Rank | Address | Share |
|---|---|---|
| #1 · locked | 0x000000…00001d | 3.33% |
| #2 · locked | 0x000000…00001c | 3.33% |
| #3 · locked | 0x000000…00001b | 3.33% |
| #4 · locked | 0x000000…00001a | 3.33% |
| #5 · locked | 0x000000…000019 | 3.33% |
This automated check scored Broccoli 5 out of 10 on BNB Chain, and the standout issue is that the contract's source code is not verified on the block explorer — the checker can only see compiled bytecode, not human-readable logic. In practice, this means most of the specific mechanics that usually get checked (whether the owner can mint new tokens, pause transfers, blacklist addresses, or change sell tax) could not be read from the data source and are reported as "no data" rather than confirmed absent. An unverified contract can still contain any of these functions; the check simply could not confirm their presence or absence on the date it ran. Separately, whether the token can actually be sold ("sellable") also came back as no data, meaning no honeypot behaviour was confirmed, but none was ruled out either. Top-10 wallets hold 33.3% of supply, which is a concentration level that means a small number of holders could move a large share of the token at once if they chose to sell. On the positive side, liquidity is reported as 100% burned, which on its face reduces (though does not eliminate) one route by which a project could pull liquidity out from under holders.
It's important to be clear about what this check does not do. It reads contract mechanics and on-chain data only — it does not assess who is behind the project, how tokens are allocated or vested, whether marketing claims match reality, or whether any legal or regulatory structure exists around the token. A technically unremarkable contract can still sit behind a team with no track record, misleading promotion, or tokenomics that concentrate future supply in ways not visible from holder counts alone. None of the findings above should be read as a judgement on the people running the project or their intentions.
Given that the contract itself is unverified and several core checks returned no data, the most concrete next step is to look for the verified source code directly on the block explorer and see whether the project or community has published it elsewhere, since an unverified contract limits what any automated or manual review can confirm. It's also worth checking whether the sell-side behaviour has been independently confirmed by other tools or reports, given that this check could not determine sellability. Because this result could not confirm that selling works, it would not be appropriate to treat even a small purchase as a safe way to "test" the contract — funds placed into a token that turns out to block sales remain stuck regardless of the amount. Reviewing holder distribution trends over time, any public statements from the team, and independent audits, if they exist, would all add context this automated check cannot provide.
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 10 points out of 100.
The other 90 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.