[Scam Alerts] NST New Smart Token (Type 0 fake) #195
Replies: 1 comment
|
Smart Contract Security Audit Report NewSmartToken (NST) Network: Polygon Contract Name: NewSmartToken
This audit evaluates the publicly verified source code of the NewSmartToken (NST) smart contract deployed on the Polygon blockchain. The assessment focuses on: •ERC-20 compliance •Economic design and tokenomics •Security vulnerabilities •Liquidity and price-manipulation risks •Classification validity (Type 0 token claim) This is a static analysis of the verified source code. No off-chain representations or marketing claims were considered unless contradicted by on-chain logic.
The NewSmartToken (NST) contract is not a standard ERC-20 implementation and exhibits multiple critical economic and logical vulnerabilities. Additionally, the token does not meet the criteria of a “Type 0” token, despite being described or perceived as such. Overall Risk Rating: High
Finding: Non-Standard Transfer Logic Severity: High The transfer() and transferFrom() functions do not follow ERC-20 behavioral assumptions. Observed behavior: •Sender balance is reduced by 103% of the requested transfer amount •Recipient receives 97% •The remaining 6% is burned This implicit tax and burn mechanism is not disclosed via standard ERC-20 interfaces and causes: •Incompatibility with wallets and DeFi protocols •Failed router interactions •Unexpected balance reductions for users Impact:
Finding: Token Is Not Type 0 Severity: High A Type 0 token is generally characterized by: •Passive balance tracking •No internal pricing logic •No mint/burn on user interaction •No internal buy/sell mechanisms NST violates all of these conditions. Observed deviations: •Internal buy() function that mints tokens •Internal sell() function that burns tokens and transfers MATIC •On-chain price calculation based on internal liquidity •Dynamic and user-driven supply changes Conclusion:
Finding: Division by Zero Risk Severity: Critical At deployment: • _totalSupply = 0 • _maticLiquidity = 0 In mintToken():
If addLiquidity() is not executed prior to the first buy() call, the transaction reverts due to division by zero. Impact: •Initial buyers cannot purchase tokens •Transactions fail unpredictably •Users may lose gas repeatedly
Finding: Unprotected Price Formula Severity: High Price is calculated as:
The contract lacks: •Time-weighted average pricing (TWAP) •Slippage controls •Transaction size limits •Anti-whale mechanisms Impact:
Finding: No Liquidity Safeguards Severity: High The sell() function allows users to redeem NST for MATIC based on current liquidity without: •Minimum liquidity reserve •Circuit breakers •Rate limits A single large holder can drain most or all available MATIC, leaving remaining holders unable to exit.
Finding: Use of send() Severity: Medium The contract transfers MATIC using:
Issues: •Limited gas stipend (2300) •Fails when recipient is a contract •Causes legitimate sell operations to revert This pattern is deprecated and unsafe.
Finding: Implicit Supply Creation Severity: Medium On the first addLiquidity() call when total supply is zero: •1,000,000 NST are minted and locked in the contract This behavior: •Is not transparently disclosed •Alters tokenomics without explicit user awareness •Functions as an implicit premine
Finding: No Recovery or Safety Mechanisms Severity: Medium The contract includes: •No emergency pause •No owner withdrawal mechanism •No recovery logic in case of failure If a critical bug is triggered, funds may become permanently inaccessible.
Area Risk Level ERC-20 Compliance High
Although the NewSmartToken contract is source-verified, verification does not imply correctness or safety. The contract: •Is not a Type 0 token •Deviates significantly from ERC-20 standards •Contains critical economic and logical vulnerabilities •Presents substantial risk of user fund loss
It is recommended that: •The token be clearly labeled high risk •Users be warned prior to interaction •The project not be integrated into DeFi systems without major redesign •Claims of Type 0 classification be corrected Audit Conclusion: |
Uh oh!
There was an error while loading. Please reload this page.
توکن NewSmartToken (NST)
آدرس قرارداد (شبکه Polygon):
0x2EC65e4301Ed2Aca71AdEC14AaEDce0924FbF2F2
این گزارش به بررسی قرارداد هوشمند NewSmartToken (NST) میپردازد که کد منبع آن در PolygonScan وریفای شده است.
با وجود وریفای بودن کد، این توکن دارای نقصهای جدی در طراحی، رفتار غیر استاندارد ERC-20 و ریسکهای شدید اقتصادی است.
این پروژه «تایپ زیرو (Type 0)» نیست و معرفی آن با این عنوان، گمراهکننده محسوب میشود.
طراحی قرارداد بهگونهای است که حتی بدون نیت بد از طرف سازنده، میتواند باعث از دست رفتن سرمایه کاربران شود.
نتیجه نهایی:
این توکن یک پروژه پرریسک و ناامن تلقی میشود و برای استفاده در DeFi مناسب نیست.
تعریف عملی Type 0 (در عرف بازار)
توکن Type 0 معمولاً:
ERC-20 کاملاً استاندارد است
منطق خرید/فروش داخلی ندارد
مالیات، burn یا fee در transfer ندارد
قیمت داخلی تعریف نمیکند
قرارداد آن passive است (فقط نگهدارنده موجودی)
چرا NST تایپ زیرو نیست؟
❌ دارای منطق داخلی خرید و فروش است
توابع:
buy() → مینت توکن
sell() → برن توکن + ارسال MATIC
این یعنی قرارداد فعال مالی است، نه یک ERC-20 ساده.
❌ دارای تابع قیمت داخلی است
price = _maticLiquidity * 10^decimals / _totalSupplyتوکن Type 0 اصلاً قیمت را در قرارداد تعریف نمیکند.
❌ عرضه (Supply) داینامیک است مینت و برن دائمی انجام میشود.
❌ رفتار انتقال (transfer) غیر استاندارد است در انتقال توکن، کسری و سوزاندن انجام میشود.
➡️ نتیجه:
این توکن از نظر فنی Type 2 / Type 3 است، نه Type 0.
معرفی آن بهعنوان Type 0 اطلاعات نادرست به کاربر میدهد.
مالیات و سوزاندن مخفی در transfer
در transfer و transferFrom:
فرستنده باید 103٪ مقدار را داشته باشد
گیرنده فقط 97٪ دریافت میکند
6٪ سوزانده میشود
مثال:
انتقال 100 NST
از فرستنده: 103 NST کم میشود
به گیرنده: 97 NST میرسد
6 NST burn میشود
❌ این رفتار:
با کیفپولها ناسازگار است
با DEXها fail میشود
با Routerهای DeFi کار نمیکند
این موضوع بهتنهایی یک پرچم قرمز بزرگ است.
مشکل
در زمان دیپلوی:
_totalSupply = 0; _maticLiquidity = 0;در تابع mint:
userMintAmount = remainAmount * _totalSupply / _maticLiquidity;اگر addLiquidity() قبل از اولین buy() اجرا نشود:
تقسیم بر صفر رخ میدهد
تراکنش revert میشود
پیامد:
کاربران اولیه نمیتوانند خرید کنند
گس از دست میرود
ترتیب خاص و پنهان لازم است
این یک نقص منطقی بحرانی است.
قیمت فقط بر اساس:
price = _maticLiquidity / _totalSupplyهیچکدام وجود ندارد:
❌ TWAP
❌ کنترل اسلیپیج
❌ محدودیت تراکنش
❌ ضد نهنگ
📉 یک تراکنش بزرگ میتواند قیمت را:
بهصورت مصنوعی بالا ببرد
یا ناگهانی سقوط دهد
در sell:
maticAmount = amount * _maticLiquidity / _totalSupply;هیچ حداقل لیکوییدیتی تعریف نشده
هیچ توقف اضطراری وجود ندارد
هیچ سقف فروش نیست
نتیجه:
یک هولدر بزرگ میتواند تقریباً کل MATIC را خارج کند
بقیه هولدرها گیر میکنند
استفاده از:
send()
مشکلات:
فقط 2300 گس
اگر گیرنده قرارداد باشد → fail
فروش کاربر ممکن است انجام نشود
این روش قدیمی و ناامن است.
در اولین addLiquidity:
1,000,000 NST
بدون شفافسازی به کاربر
قفل دائمی
تغییر توکنومیکس بهصورت مخفی
در ممیزیها این موضوع پرچم قرمز جدی محسوب میشود.
owner نمیتواند برداشت کند
pause وجود ندارد
اگر باگ فعال شود → پول قفل میشود
بخش سطح ریسک
انطباق ERC-20 ❌ بسیار بالا
طراحی اقتصادی ❌ بسیار بالا
امنیت لیکوییدیتی ❌ بسیار بالا
پایداری قیمت ❌ بسیار بالا
Type 0 بودن ❌ نادرست
امنیت کاربران ❌ بسیار بالا
وریفای بودن کد ≠ امن بودن پروژه
NewSmartToken (NST):
❌ تایپ زیرو نیست
❌ ERC-20 استاندارد نیست
❌ دارای نقصهای اقتصادی و منطقی جدی است
❌ میتواند باعث ضرر کاربران بدون اسکم مستقیم شود
این پروژه باید:
پرریسک تلقی شود
اسکم و کلاهبرداری سطح بالا دارد
All reactions