NEMESIS

Beosin2 addresses on BNB Chain

Beosin reviewed NEMESIS on 21 Jun 2025: 4 findings, 0 critical; all marked fixed.

No open critical findings
Open the reportOpen NEMESIS’s security record

Report hosted on beosin.com.

Trustblock does not review code.

Findings4

Statuses are the security firm’s own, from its report.

SeverityOpenAcknowledgedFixed
Critical000
High001
Medium001
Low002
HighThe deliver function may enablearbitrageopportunities in the poolFixed

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.

MediumThe parameter configuration lacks rationalityFixed

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.

LowThe amount verified in removeAllFee is inconsistentFixed

Since the contract has added handling for _developmentFee, the validationinthe removeAllFee function should also include checks for _developmentFee.

LowThe fee modification lacks range restrictionsFixed

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.

Contracts in scope2

AddressChainSource code
0xa3e53296e78664d71d2b590955210eee6392b576Chain: BNB ChainSource code: Verified source
0x833f686702e068449fd27dea3187695bb536b068Chain: BNB ChainSource code: Verified source

Part of NEMESIS’s security record

NEMESIS
Audits1 audit by 1 firmLast audit Jun 2025, by Beosin.
Critical findingsNo open critical findingsIn 1 report.
Open NEMESIS’s security record

Security firm

Beosin

1 project reviewed · 1 report · latest Jun 2025

See Beosin’s audits

Something 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