| Risk factor | Finding | Evidence | Date |
|---|---|---|---|
| Sellable | Yes | ChainSift simulation | 27 Oct 2026 |
| Buy tax | 0% | ChainSift simulation | 27 Oct 2026 |
| Sell tax | 0% | ChainSift simulation | 27 Oct 2026 |
| Admin mint | Not found | Implementation code | 27 Oct 2026 |
| Transfers pausable | Not found | Implementation code | 27 Oct 2026 |
| Address blacklist | Not found | Implementation code | 27 Oct 2026 |
| Upgradeable proxy | Yes — a timelock with a 3-day delay can replace the code | Proxy contract | 27 Oct 2026 |
| Source verified | Yes | Block explorer | 27 Oct 2026 |
| Top-10 holders | 100% | Holder distribution | 27 Oct 2026 |
| Holders | 2 | Token contract | 27 Oct 2026 |
| Deployed by | 0x1cfd6a…586e1e |
| Code can be replaced by | 0x4a88c1…bcd9ad — a timelock with a 3-day delay |
| Current code | 0x0d1b64…73d145 |
| Holders | 2 |
| Rank | Address | Share |
|---|---|---|
| #1 | 0x1cfd6a…586e1e | 99.10% |
| #2 · contract | 0x7623ee…08b045 | 0.90% |
This automated check looked at the contract code behind KII on BSC and scored 11 out of 18. A few things stand out worth understanding before anything else. The contract uses an upgradeable proxy pattern, which means the logic that governs how the token behaves is not fixed — it can be replaced. In this case, that change would need to go through a timelock with a 3-day delay, so it isn't instant, but whoever controls that timelock could still swap in new code that alters how the token works, including any of the protections checked here (for example, mint limits or the absence of a blacklist could be added later even if they're not present today). Separately, the holder distribution shows only 2 holders on record, with the top 10 (effectively these same addresses) holding 100% of supply. That level of concentration means a very small number of wallets could move or sell a large share of the token at once, which can affect price sharply in either direction. On the more reassuring side, no admin mint function, pausable transfer function, or blacklist capability was found in the implementation code as of the date of this check, and a simulated buy/sell came back sellable with 0% buy and sell tax — meaning no honeypot behaviour was detected in that test. The contract source is also verified on the block explorer, which allows this kind of inspection in the first place.
It's worth being clear about what this check does not cover. This is an automated read of contract mechanics only — it has no view into who the team is, whether they have a track record, how tokens are allocated or vested, what the project claims to do, or whether any of it holds up legally or practically. A clean mechanical read says nothing about intent, and a flagged mechanical read doesn't confirm bad intent either — it just tells you what the code technically allows.
Given the concentration and upgrade flags here, it would be reasonable to look into who holds those top wallets and whether there's any public information linking them to the project team, to look up who controls the timelock and whether that control is disclosed anywhere, and to check whether the project has published documentation on tokenomics, vesting, or audits from independent firms. Searching for the contract address and team name together on independent forums or explorers before making any decisions is also a reasonable step.
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.