Beosin reviewed NEMESIS on 21 Jun 2025: 4 findings, 0 critical; all marked fixed.
Report hosted on beosin.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 1 |
| Medium | 0 | 0 | 1 |
| Low | 0 | 0 | 2 |
In deflationary tokens implemented similarly to SafeMoon, the systemoftendevelops an imbalance in the currentRate (the reflection rate) over time. Thishappens because the contract includes excluded accounts that areremovedfrom the reflection mechanism. The rOwned and _tOwned values for theseaccounts are fixed based on the rate at the time they were excluded. As users continue to transfer tokens, _rTotal decreases due to reflection-basedfees, while _tTotal remains constant. Over time, this causes a distortionintheratio between rSupply and tSupply. Since both values are calculatedbysubtracting the fixed rOwned and _tOwned of the excluded accounts (whichdonot update with the current rate), and _rTotal continues to shrink, thecurrentRate drifts further from its intended balance. At this point, an attacker can exploit the deliver function to profit fromtheliquidity pool (pair). Although the currentRate is already imbalanced, standardtransaction fees are still deducted as a fixed percentage of the transfer amount(e.g., 5%), causing only gradual shifts. In contrast, the deliver functiondeductsthe entire token amount directly from _rTotal without affecting _tTotal, whichsignificantly worsens the rate imbalance. Leveraging this mechanism, the attacker can repeatedly invoke deliver fromthepair address, effectively simulating massive token inflation at minimal cost. This allows them to arbitrage against the distorted pricing and extract profitfrom the pool.
Because _maxTxAmount and numTokensSellToAddToLiquidity are set equal tothe total token supply, the validation on maxTxAmount becomes too permissiveand effectively meaningless. Additionally, the excessively highnumTokensSellToAddToLiquidity value combined with the absence of amethodto adjust it results in a portion of tokens being locked within the contract andrendered unusable.
Since the contract has added handling for _developmentFee, the validationinthe removeAllFee function should also include checks for _developmentFee.
The contract allows the administrator to modify the fee rates without enforcingreasonable limits. If the fees are set too high, users may receive significantlyfewer tokens than expected, which could negatively impact theuserexperience.
| Address | Chain | Source code |
|---|---|---|
| 0xa3e5…b5760xa3e53296e78664d71d2b590955210eee6392b576 | Chain: BNB Chain | Source code: Verified source |
| 0x833f…b0680x833f686702e068449fd27dea3187695bb536b068 | Chain: BNB Chain | Source code: Verified source |
1 project reviewed · 1 report · latest Jun 2025
See Beosin’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us