میم کوائن ریسرچ
میم کوائن خریدنے سے پہلے 12 نکاتی Risk Checklist
Contract، holders، liquidity، unlocks، mint authority اور جعلی hype کو جانچنے کے لیے قابلِ عمل 12 نکاتی فہرست۔
Meme coin خریدنے سے پہلے “community بڑی ہے” یا “market cap کم ہے” کافی جواب نہیں۔ اصل کام یہ ہے کہ درست contract سے شروع کر کے admin powers، holder concentration، liquidity، supply schedule، public claims اور اپنی exit capacity تک ایک ہی evidence sheet میں لکھا جائے۔ جہاں جواب نہ ملے، وہاں “safe” نہ لکھیں؛ unknown خود ایک risk state ہے۔
یہ 12 نکاتی checklist کسی token کو محفوظ قرار نہیں دیتی۔ اس کا مقصد research کو repeatable بنانا ہے تاکہ آپ symbol، screenshot یا influencer claim کے بجائے contract address اور timestamped evidence سے نتیجہ نکالیں۔ مثال کے طور پر استعمال ہونے والی FLOKI اور BONK تصاویر صرف مخصوص public records دکھاتی ہیں، investment recommendation نہیں۔
مختصر فیصلہ: خرید سے پہلے کن 12 چیزوں کو دیکھیں؟
- Asset identity اور درست contract
- Verified source، proxy اور implementation
- Mint، pause، blacklist، tax اور admin powers
- Holder concentration اور wallet labels
- Liquidity، executable exit اور price impact
- LP lock، burn اور withdrawal control
- Circulating، total، max اور multi-chain supply
- Allocation، cliff، unlock اور vesting
- Audit report کا exact scope
- Website، documentation اور official claims
- Wallet approvals، phishing اور social engineering
- Position size، custody اور exit plan
اس checklist کو کیسے استعمال کریں؟
ہر نکتے کے لیے چار fields رکھیں: status، evidence، timestamp، unresolved question۔ Status صرف verified، partly verified، unknown یا risk ہو۔ Green/red score اکیلا نہ دیں، کیونکہ ایک critical mint key پانچ cosmetic green checks سے ختم نہیں ہوتی۔ آخر میں risk کو severity سے ترتیب دیں:
- Critical: ایسا control یا evidence gap جو supply، transfers یا funds کو فوری متاثر کر سکتا ہے۔
- High: concentrated control، thin exit یا بڑا قریب unlock۔
- Medium: documentation mismatch یا incomplete attribution۔
- Low: presentation، minor metadata یا آسانی سے درست ہونے والا gap۔
1. کیا contract address واقعی اسی asset کا ہے؟
صحیح contract کے بغیر باقی تحقیق بے معنی ہے۔ نام اور ticker آسانی سے نقل ہو سکتے ہیں، اس لیے project کے official page سے chain اور address لیں، پھر explorer میں symbol، decimals، deployer اور creation transaction دیکھیں۔ Search-engine result، ad یا wallet suggestion کو primary source نہ بنائیں۔
یہ identity card لکھیں:
| Field | کیا محفوظ کرنا ہے |
|---|---|
| Chain | Ethereum، BNB Chain، Solana یا دوسری network |
| Contract/mint address | مکمل string؛ درمیان سے مختصر نہیں |
| Token standard | ERC-20 یا متعلقہ chain standard |
| Decimals | raw units کو انسانی units میں بدلنے کے لیے |
| Official source | project documentation کا exact URL |
| Explorer source | address page اور retrieval time |
Ethereum ERC-20 documentation standard functions میں totalSupply، balanceOf اور transfers دکھاتی ہے۔ یہ interface شناخت میں مدد دیتا ہے، مگر ERC-20 compatible ہونا safety certificate نہیں۔ ایک malicious token بھی common interface رکھ سکتا ہے۔
Multi-chain asset میں ہر network address الگ row میں رکھیں۔ Bridge-wrapped representation، native issuance اور fake copy کو جمع نہ کریں۔ Contract بدلنے یا migration claim کی صورت میں old/new addresses اور official migration transaction دونوں verify کریں۔
2. Source code verified ہے، مگر کیا یہی active logic ہے؟
Verified source transparency بڑھاتا ہے، guarantee نہیں۔ Explorer پر compilation match دیکھنے کے بعد معلوم کریں کہ address direct implementation ہے یا proxy۔ Proxy ہو تو implementation، proxy admin، upgrade events اور current implementation slot اہم ہیں۔ صرف proxy shell پڑھنا اصل behavior چھوڑ سکتا ہے۔
اوپر Blockscout کا مخصوص smart-contract record ہے۔ Visible JSON source references دکھاتا ہے؛ یہ contract audit یا harmless ہونے کا اعلان نہیں۔ Source keyword ملنے کے بعد function body، modifiers، callable path اور current state الگ دیکھیں۔
OpenZeppelin proxy documentation سمجھاتی ہے کہ proxy calls کو implementation کی طرف delegate کر سکتا ہے۔ اس لیے “verified proxy” کو “immutable code” نہ سمجھیں۔ Upgrade authority single wallet، multisig، governance یا timelock میں کس کے پاس ہے، یہ نتیجے میں لکھیں۔
3. Mint، pause، blacklist، tax اور admin powers کس کے پاس ہیں؟
Admin powers کو function-name checklist نہیں بلکہ actor → capability → delay → evidence table میں رکھیں۔ owner کے علاوہ DEFAULT_ADMIN_ROLE، MINTER_ROLE، guardian، fee handler، treasury handler اور proxy admin دیکھیں۔ Hidden path inheritance یا external module میں ہو سکتا ہے۔
OpenZeppelin Access Control guide واضح کرتی ہے کہ access control mint، freeze اور دوسرے sensitive actions طے کر سکتا ہے۔ renounceOwnership event ملنے سے ہر privileged role ختم ہونا ثابت نہیں؛ role members، proxy admin اور external controllers باقی ہو سکتے ہیں۔
ان سوالات کے جواب لکھیں:
- کیا نئی supply mint ہو سکتی ہے، اور cap ہے؟
- کیا transfers pause یا مخصوص wallets block ہو سکتے ہیں؟
- کیا buy/sell/transfer fee بدلی جا سکتی ہے؟ Maximum on-chain حد کیا ہے؟
- کیا fee destination یا treasury address بدلا جا سکتا ہے؟
- کیا liquidity-related wallets سے funds نکالنے کی permission ہے؟
- کیا upgrade فوری ہے یا public delay کے بعد؟
- Admin EOA ہے، multisig ہے یا governance contract؟
OWASP SCSVS access-control requirements least privilege اور restricted functions کی verification کو security control بناتی ہیں۔ OWASP checklist بھی deployed asset کی safety guarantee نہیں؛ یہ سوالات منظم کرنے کا testing framework ہے۔
4. Top holders میں حقیقی concentration کتنی ہے؟
Raw top-10 percentage اکثر غلط impression دیتی ہے۔ Burn address، liquidity pool، bridge، vesting contract، exchange custody اور treasury کو الگ classify کریں۔ پھر unknown externally controlled wallets کا concentration نکالیں۔ Label نہ ملے تو identity نہ گھڑیں۔
یہ Ethplorer address page ایک وقت کا Ethereum-chain snapshot ہے۔ Screenshot wallet balances اور ranking دکھاتا ہے، wallet کی حقیقی مالک identity نہیں۔ Exchange omnibus wallet ہزاروں users کی custody ہو سکتا ہے؛ اسے single whale کہنا غلط ہوگا۔ اسی طرح LP contract balance public float نہیں، مگر liquidity withdrawal risk سے متعلق ہے۔
Holder table میں یہ columns رکھیں: address، balance، supply share، label source، contract/EOA، last relevant movement، confidence۔ Top holders کو holder concentration verification guide کے مطابق الگ پڑھیں؛ repeated transfers کو multiple independent whales سمجھنے سے بچیں۔
5. Market cap کے مقابل واقعی کتنی liquidity نکل سکتی ہے؟
Market cap exit capacity نہیں۔ کسی کم-liquidity pool میں چھوٹا trade بھی price curve بدل سکتا ہے۔ Intended sale size کا quote، minimum received، pool reserves، route، spread اور price impact دیکھیں۔ 24-hour volume کو اکیلا معیار نہ بنائیں؛ duplicated markets یا incentives quality خراب کر سکتے ہیں۔
Uniswap کی price-impact documentation trade size اور pool liquidity کے تعلق کو واضح کرتی ہے۔ اوپر Uniswap Labs کا market-depth research page broader liquidity comparison دکھاتا ہے؛ اسے کسی مخصوص meme coin کی current depth نہ سمجھیں۔
تین exits test کریں: اپنی position کا 10%، 50% اور 100%۔ یہ quote-based stress test ہے، actual trade نہیں۔ Quote time اور chain لکھیں، کیونکہ route چند منٹ میں بدل سکتا ہے۔ اگر sell fails ہو تو gas، allowance، token restriction، router compatibility اور scam behavior سب possibilities ہیں؛ ایک failed attempt سے اکیلا verdict نہ دیں۔
6. Liquidity “locked” یا “burned” ہونے کا دعویٰ کیسے verify کریں؟
LP lock claim میں locked LP token amount، total LP supply، locker contract، beneficiary، unlock time اور early-withdraw conditions دیکھیں۔ صرف project کا badge یا screenshot ثبوت نہیں۔ Locker خود upgradeable یا admin-controlled ہو سکتا ہے۔
LP tokens burn address پر بھیجنے سے متعلقہ pool position واپس لینا مشکل ہو سکتا ہے، مگر یہ پورے token کو محفوظ نہیں بناتا۔ Admin نئی pool بنا سکتا ہے، token tax بدل سکتا ہے، mint کر سکتا ہے یا external treasury dump ہو سکتی ہے۔ Concentrated-liquidity NFT position میں ERC-20 LP-token assumptions لاگو نہیں بھی ہو سکتیں۔
ہر pool الگ لکھیں۔ چھوٹا locked pool دکھا کر بڑی unlocked liquidity کو نظر انداز کرنا marketing trick ہو سکتی ہے۔ Pair address، token0/token1، fee tier، position owner اور current liquidity amount verify کریں۔
7. Circulating، total، max اور multi-chain supply آپس میں ملتی ہیں؟
Supply کے کم از کم تین numbers الگ ہیں۔ Total supply minted units minus verified burns ہو سکتی ہے؛ circulating public float کی methodology ہے؛ max supply theoretical cap یا contract rule ہو سکتا ہے۔ Contract میں mint authority ہو تو marketing “fixed supply” claim کے ساتھ code reconcile کریں۔
CoinGecko Supply Methodology locked، vested، team، foundation اور treasury wallets کو circulating figure میں الگ رکھنے کی اپنی policy بیان کرتی ہے۔ Provider methodology project claim سے مختلف ہو سکتی ہے؛ اختلاف کو فوراً fraud نہ کہیں، denominator اور excluded wallets compare کریں۔
Bridge model بھی لکھیں: lock-and-mint، burn-and-mint یا multiple native issuances۔ Ethereum اور BNB Chain پر ایک ہی brand کے balances کو جمع کرنا double counting بنا سکتا ہے۔ تفصیل circulating، total اور maximum supply guide میں ہے۔
8. Allocation اور اگلا unlock float کو کتنا بدل سکتے ہیں؟
Unlock calendar کو current circulating supply کے تناسب میں دیکھیں۔ Allocation bucket، cliff، release curve، recipient اور transferability الگ fields ہیں۔ “Unlocked” کا مطلب “sold” نہیں، مگر recipient کے پاس sell option بڑھ سکتی ہے۔
اوپر BONK Paper کا historical project-authored page ہے۔ یہ documented allocation/vesting بیان کرتا ہے، آج کا locked balance یا implementation نہیں۔ Current announcement، contract، vesting wallets اور observed transfers سے دوبارہ verify کریں۔
Gross unlock ratio = اگلی releasable units ÷ current circulating supply × 100
Ratio sell-pressure forecast نہیں۔ Recipient cost basis، demand اور liquidity outcome بدلتے ہیں۔ مکمل workflow token unlock اور dilution guide میں رکھیں۔
9. Audit report واقعی اسی code کو cover کرتی ہے؟
Audit logo نہیں، scoped document پڑھیں۔ Report title سے آگے contract address، commit hash، chain، audit date، methodology، severity definitions، unresolved findings اور remediation status دیکھیں۔ “Passed” graphic critical assumptions چھپا سکتی ہے۔
یہ سوالات لکھیں:
- Audited source اور deployed bytecode match ہیں؟
- Proxy implementation audit کے بعد بدلی؟
- Token کے ساتھ locker، staking، bridge اور treasury contracts scope میں تھے؟
- Centralization یا privileged roles informational کہہ کر چھوڑے گئے؟
- Fix review واقعی final deployment پر ہوا؟
- Economic design، liquidity اور holder concentration audit scope سے باہر تھے؟
OWASP Smart Contract Security Testing Guide مختلف risk categories کے لیے testing methodologies دیتا ہے۔ ایک audit zero-risk certificate نہیں اور OWASP coverage بھی project-specific review کا بدل نہیں۔
10. Website، documentation اور official claims آپس میں consistent ہیں؟
Contract address، supply، team/treasury wallets، roadmap اور audit references مختلف official surfaces پر match ہونے چاہئیں۔ Domain creation history، documentation repository اور announcement dates دیکھیں۔ Copied legal text یا fake partnership logo credibility نہیں بناتے۔
Mismatch table بنائیں: claim، page URL، page date، chain evidence، status۔ Project silently page بدل دے تو archived copy یا saved PDF useful ہو سکتی ہے، مگر archive current truth نہیں۔ Partnership کو partner کے own channel سے verify کریں؛ صرف token site کا logo کافی نہیں۔
Social engagement بھی آسانی سے خریدی جا سکتی ہے۔ Followers، likes یا trending hashtag کو code/liquidity evidence کے برابر weight نہ دیں۔ Urgency language، guaranteed listing یا “last chance” countdown کے ساتھ independent source نہ ہو تو risk بڑھتا ہے۔
11. Wallet approval، seed phrase اور social engineering کا خطرہ ہے؟
Research کے دوران بھی wallet drain ہو سکتا ہے۔ Contract inspect کرنے کے لیے wallet connect ضروری نہیں۔ Search ads، cloned domains، fake support DMs اور unexpected signature requests سے بچیں۔ Seed phrase یا private key کبھی website، bot، support agent یا form میں نہ دیں۔
Approval میں spender address، token، amount اور function پڑھیں۔ Unlimited approval convenience دے سکتی ہے، مگر malicious یا compromised spender زیادہ balance منتقل کر سکتا ہے۔ Permit/signature کو “gasless login” سمجھ کر blind sign نہ کریں۔ Hardware wallet بھی غلط transaction approve کرنے سے نہیں بچاتا۔
Safe research environment میں bookmarked official domains، separate browser profile، low-value test wallet اور approval review مددگار ہیں۔ پھر بھی test transaction scam-proof certificate نہیں؛ admin بعد میں parameters بدل سکتا ہے اگر control موجود ہو۔
12. Position size، custody اور exit plan کیا ہے؟
Final risk token سے زیادہ آپ کی exposure پر منحصر ہے۔ Investor.gov crypto-asset alert volatility، illiquidity، custody failure اور market disappearance سمیت significant loss risks بیان کرتا ہے۔ صرف وہ capital risk کریں جس کا مکمل loss برداشت ہو سکے؛ leverage نقصان اور liquidation speed بڑھا سکتا ہے۔
خرید سے پہلے یہ لکھیں:
- Maximum amount at risk؛
- Custody location اور withdrawal test؛
- Planned entry size اور DEX/CEX venue؛
- 25%، 50% اور 100% exit quote؛
- کون سا evidence thesis invalidate کرے گا؛
- Admin change، unlock یا liquidity removal alert کیسے دیکھیں گے؛
- Loss پر averaging-down rule کیا ہوگا؛
- Records اور transaction evidence کہاں محفوظ ہوں گے۔
Plan profit target کی guarantee نہیں۔ اگر exit liquidity position سے بہت کم ہے تو displayed portfolio value قابلِ وصول cash نہیں۔
ایک 12-point result sheet کیسا دکھے؟
| # | Check | Status | Evidence | Unresolved |
|---|---|---|---|---|
| 1 | Contract identity | verified/partial/unknown/risk | official + explorer | migration؟ |
| 2 | Source/proxy | verified source | implementation؟ | |
| 3 | Admin powers | roles/state | timelock؟ | |
| 4 | Holders | timestamped list | labels؟ | |
| 5 | Liquidity | full-size quote | route change؟ | |
| 6 | LP control | locker/burn tx | early exit؟ | |
| 7 | Supply | provider + chain | bridge scope؟ | |
| 8 | Unlocks | document + contract | recipient؟ | |
| 9 | Audit | report + commit | deployment match؟ | |
| 10 | Claims | official cross-check | mismatch؟ | |
| 11 | Wallet safety | approval/signature | spender؟ | |
| 12 | Personal risk | written plan | exit capacity؟ |
ہر evidence URL کے ساتھ RFC3339 timestamp اور chain لکھیں۔ Risk checklist tool status منظم کر سکتا ہے، مگر “verified” صرف آپ کے source quality جتنا مضبوط ہے۔
فوری reject signals کیا ہیں؟
- Official contract address نہ ملے یا مختلف pages پر بدلتا ہو۔
- Sell restriction یا extreme tax observed ہو اور transparent explanation نہ ہو۔
- Hidden/unbounded mint capability concentrated admin کے پاس ہو۔
- Liquidity claim on-chain pool/position سے match نہ کرے۔
- Audit logo ہو مگر report، address یا commit نہ ملے۔
- Team guaranteed return یا guaranteed listing کا وعدہ کرے۔
- Website seed phrase/private key مانگے۔
- Support DM urgent transfer یا wallet synchronization کہے۔
- Supply/holder data صرف cropped screenshot ہو، reproducible URL نہ ہو۔
- Unknown wallet float اور intended exit liquidity کے مقابل بہت concentrated ہو۔
ایک signal ہمیشہ fraud ثابت نہیں کرتا، مگر seed phrase request یا unverifiable sell restriction جیسے signals فوری رکنے کے لیے کافی ہیں۔ “FOMO کی وجہ سے بعد میں دیکھ لیں گے” research plan نہیں۔
عام سوالات
کیا verified contract محفوظ ہوتا ہے؟
نہیں۔ Verification source-bytecode match دکھا سکتی ہے؛ business logic، admin intent، liquidity اور future upgrades کی safety ثابت نہیں کرتی۔
Ownership renounced ہو تو rug pull ناممکن ہے؟
نہیں۔ دوسرے roles، proxy admin، treasury، LP control یا pre-minted concentrated supply باقی ہو سکتی ہے۔ تمام control paths دیکھیں۔
Liquidity locked ہو تو token safe ہے؟
نہیں۔ Lock صرف مخصوص liquidity position کے withdrawal risk کو محدود کر سکتا ہے۔ Mint، tax، blacklist، upgrade اور external-holder risks الگ رہتے ہیں۔
Top holder exchange ہو تو concentration ignore کریں؟
نہیں۔ Custody wallet کی beneficial ownership مختلف ہو سکتی ہے، مگر venue/custody risk اور outflow monitoring پھر بھی relevant ہیں۔ Label source verify کریں۔
Audit نہ ہو تو token لازماً scam ہے؟
نہیں، مگر independent review کم اور verification burden زیادہ ہوتا ہے۔ Audit موجود ہو تب بھی scope اور deployment match دیکھنا ضروری ہے۔
Small test buy/sell کافی ہے؟
نہیں۔ Test current path دکھاتا ہے، future admin changes یا full-position price impact نہیں۔ Intended size کا quote اور control review پھر بھی کریں۔
آخری احتیاط
اچھی risk checklist green badges جمع نہیں کرتی؛ وہ critical unknowns دکھاتی ہے۔ Contract identity سے شروع کریں، code/control، holders، liquidity، supply اور unlocks کو الگ verify کریں، پھر اپنی position اور exit کے ساتھ نتیجہ لکھیں۔ Evidence پرانا ہو تو timestamp واضح رکھیں اور خرید سے پہلے refresh کریں۔ Meme coin میں مکمل loss، illiquidity، malicious code، custody failure اور social engineering سب ممکن ہیں۔
یہ مواد تعلیمی ہے، مالی مشورہ نہیں۔ اہل صارف اپنی صوابدید پر بائنانس دعوتی کوڈ BN8812 استعمال کر سکتا ہے۔ سائٹ آپریٹر کے مطابق اسپاٹ ٹریڈنگ فیس پر زیادہ سے زیادہ 20% رعایت ممکن ہے؛ اصل شرح، اہلیت، علاقائی دستیابی اور موجودہ شرائط بائنانس پر خود تصدیق کریں۔