| Risk factor | Finding | Evidence | Date |
|---|---|---|---|
| Sellable | No — transfers blocked | Transfer simulation | 7 Oct 2026 |
| Buy tax | No data | Contract | 7 Oct 2026 |
| Sell tax | No data | Contract | 7 Oct 2026 |
| Admin mint | Not present | Contract | 7 Oct 2026 |
| Transfers pausable | Not present | Contract | 7 Oct 2026 |
| Address blacklist | Not present | Contract | 7 Oct 2026 |
| Upgradeable proxy | No | Contract | 7 Oct 2026 |
| Source verified | Yes | Block explorer | 7 Oct 2026 |
| Top-10 holders | 63.4% | Holder distribution | 7 Oct 2026 |
| Liquidity locked | No | LP holders | 7 Oct 2026 |
| Holders | 207433 | Token contract | 7 Oct 2026 |
| Deployed by | 0x18dd4e…2272f8 |
| Current owner | 0xeaa099…af6d06 |
| Holders | 207,433 |
| Rank | Address | Share |
|---|---|---|
| #1 | 0xca97e5…48c00c | 37.94% |
| #2 | 0xf97781…41acec | 6.92% |
| #3 | 0x50260d…e8f705 | 6.52% |
| #4 · contract | 0x40ec5b…5bbbdf | 4.42% |
| #5 · contract | 0x8ffa64…ed8068 | 2.08% |
This automated check flagged several mechanics worth understanding before deciding what to do next. The simulation found that selling currently appears blocked by the contract — meaning the code itself prevents transfers out, a pattern typically described as honeypot behaviour. Alongside this, the check found that the contract owner retains the ability to change wallet balances directly, which in practice means the owner could alter how many tokens an address holds without that holder's involvement. Liquidity in the trading pool was found not to be locked, so whoever controls that liquidity could withdraw it from the pool at their discretion. The top 10 holders were found to control 63.4% of total supply, a concentration level that means a small number of wallets could influence price significantly if they chose to sell. On the other side, the contract source code was found to be verified on the block explorer, and no admin mint function, pausable transfers, upgradeable proxy, or blacklist function were detected as of the date of this check.
It's important to be clear about what this check does and doesn't cover. This is an automated read of the contract's code and on-chain data only — it looks at what the contract mechanically permits, not at who is behind it, what they intend to do, or whether their stated plans are credible. It does not assess the project's team, roadmap, tokenomics design, marketing claims, legal structure, or jurisdiction. A contract can show no dangerous flags and still be attached to a project with weak fundamentals or poor execution, and conversely a flagged contract isn't a determination of fraud — these are indicators of risk, not conclusions about intent.
Given the combination of blocked selling in simulation, owner balance-change capability, and unlocked liquidity, it would be reasonable to look further before acting. Concrete next steps include attempting a small test transaction to see directly whether selling is possible under current conditions, reviewing the contract's owner/admin functions line by line or via a trusted audit if one exists, checking whether the liquidity pool tokens are held by a known locker contract or by an individual wallet, and researching the team's public identity, prior projects, and community discussion for independent reports of similar issues. None of these steps guarantee an outcome, but they add context this automated check cannot provide on its own.
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.