| Risk factor | Finding | Evidence | Date |
|---|---|---|---|
| Sellable | Yes | Transfer simulation | 29 Sept 2026 |
| Buy tax | No data | Contract | 29 Sept 2026 |
| Sell tax | No data | Contract | 29 Sept 2026 |
| Admin mint | Enabled | Contract | 29 Sept 2026 |
| Transfers pausable | Not present | Contract | 29 Sept 2026 |
| Address blacklist | Not present | Contract | 29 Sept 2026 |
| Upgradeable proxy | No | Contract | 29 Sept 2026 |
| Source verified | Yes | Block explorer | 29 Sept 2026 |
| Top-10 holders | 100% | Holder distribution | 29 Sept 2026 |
| Holders | 3 | Token contract | 29 Sept 2026 |
| Deployed by | 0xab2892…7403d9 |
| Current owner | 0xc50ebe…54a511 |
| Holders | 3 |
| Rank | Address | Share |
|---|---|---|
| #1 | 0xc50ebe…54a511 | 99.70% |
| #2 | 0x983873…d2f679 | 0.30% |
| #3 | 0xc4752c…04c662 | 0.00% |
This automated check found that REUR's contract includes a function allowing the owner to mint new tokens at will. In practice, this means the person or entity controlling the contract can increase the total token supply at any point, which can dilute the value held by existing holders without their consent or any on-chain restriction preventing it. The check also found that the top 10 wallet addresses hold 100% of the circulating supply, and that there are only 3 holders in total. This level of concentration means that a very small number of addresses control the entire token supply, so any decision by those holders to sell would directly affect the market for everyone else. On a more reassuring note, the contract source code is verified on the block explorer, meaning the code is publicly readable and matches what is deployed, and a transfer simulation indicated the token can be sold. No transfer-pausing function, address blacklist, or upgradeable proxy pattern was detected on the date of this check, though buy and sell tax data could not be retrieved from the contract.
It's important to understand what this check does not tell you. This is an automated review of contract mechanics only — it reads what the code allows the owner to do, not what they intend to do, and not whether they will do it. It does not assess the team behind the token, their identity, track record, or reachability. It says nothing about tokenomics design, roadmap, marketing claims, or whether any legal entity stands behind the project. A verified contract and clean simulation are not statements about legitimacy, safety, or future price behaviour — they simply describe what was observed in the code and a test transaction at the time of the check.
Before considering any transaction, it's worth looking into who controls the contract's owner address and whether that control is renounced, held by a multisig, or timelocked — this materially affects how the mint function could be used. Given that only 3 addresses hold the entire supply, it's worth investigating who those wallets belong to and whether any are exchange or liquidity pool addresses rather than individual holders. Checking whether liquidity is locked, for how long, and by whom is also a concrete next step, as is searching for any independent audit, team disclosure, or community discussion about this specific contract address. None of these steps are covered by this automated check, and none of the findings above should be read as a recommendation either way.
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.