میم کوائن رسک چیک لسٹ

Meme Coin risk checklist کا مقصد “safe/unsafe” score بنانا نہیں۔ اس کا کام یہ دکھانا ہے کہ کون سی critical بات evidence سے supported ہے، کہاں contradiction ہے اور کہاں data missing ہے۔ ایک serious unknown کو دس cosmetic green checks cancel نہیں کرتے۔ یہ manual due-diligence worksheet ہے، audit، malware scanner یا investment recommendation نہیں۔

مختصر جواب: تحقیق کہاں سے شروع کریں؟

Full contract/mint address سے identity بند کریں، پھر contract permissions، holder concentration، liquidity، supply/unlocks، project claims اور exit route کو الگ evidence layers میں check کریں۔ Ticker، logo، social followers یا verified source اکیلے safety proof نہیں۔

Evidence statuses

• Confirmed: primary source اور chain state دونوں match
• Supported: مضبوط evidence ہے مگر ایک layer باقی
• Unknown: کافی evidence نہیں
• Contradicted: معتبر sources براہ راست مختلف
• Not applicable: mechanism اس token پر لاگو نہیں

Numeric score نہ دیں۔ Unknown کو zero یا neutral بنا کر total score بڑھانا خطرناک ہے۔ Critical contradiction آئے تو analysis pause کریں۔

Check 1: Contract identity

Ethereum ERC-20 overview standard token functions کا context دیتی ہے۔ Standard compliance safety، fair launch یا honest team کی ضمانت نہیں۔

Check 2: Verified source کو صحیح معنی دیں

یہ 2026-08 میں لیا گیا حقیقی Blockscout smart-contract response ہے۔ Source text میں Ownable اور handler references دکھنا audit conclusion نہیں؛ یہ investigation clues ہیں۔ Screenshot FLOKI کو safe یا unsafe قرار نہیں دیتی۔

Verified source کا مطلب explorer نے published source کو deployed bytecode سے match کیا۔ Logic harmless، admins trustworthy یا upgrade impossible ہونا ثابت نہیں۔

Check 3: Privileged permissions

OpenZeppelin AccessControl role-based permissions کی reference دیتی ہے۔ Search terms:

• mint / minter role
• pause/unpause
• blacklist/denylist
• fee/tax setters
• max transaction/wallet limits
• trading enable flag
• rescue/withdraw
• ownership transfer
• upgrade admin
• external handler/router setters

Function موجود ہونا active permission کا proof نہیں؛ current owner/roles اور reachable call path دیکھیں۔ Function absent دکھے تو proxy implementation اور delegated modules check کریں۔

OpenZeppelin proxy documentation upgradeable pattern کے storage/implementation context دیتی ہے۔ Proxy admin future logic بدل سکتا ہے، اس لیے current implementation snapshot permanent guarantee نہیں۔

Check 4: Admin security

Admin EOA، multisig، timelock یا governance contract ہو سکتا ہے۔ Record کریں:

• owner/admin address
• signers/threshold، اگر public multisig
• timelock delay
• role grant/revoke history
• recent admin changes
• renounce claim کی current state

OWASP Smart Contract Security Verification Standard authorization controls privileged access review کا security context دیتا ہے۔ Checklist formal audit کا substitute نہیں۔

Check 5: Holder concentration

Top-holder percentage سے پہلے addresses classify کریں:

• burn/dead
• liquidity pool
• bridge vault
• exchange custody
• vesting/team/treasury
• smart contracts
• unknown wallets

Unknown wallet کو team نہ کہیں۔ Exchange address ہزاروں users کی custody ہو سکتی ہے؛ LP contract tradable liquidity represent کر سکتا ہے؛ burn balance economic circulation سے باہر ہو سکتا ہے۔ Raw top-10 اور adjusted top-10 دونوں دکھائیں، exclusions کی evidence list ساتھ دیں۔

Concentration measure:

Top-N share = selected holder balances ÷ chosen supply base × 100

Denominator circulating یا total واضح کریں۔ Same address cluster multiple wallets میں split ہو سکتا ہے، اس لیے result lower bound بھی ہو سکتا ہے۔

Check 6: Liquidity اور exit

یہ 2026-08 میں محفوظ حقیقی Uniswap research screenshot ہے۔ Chart liquidity research context دیتی ہے؛ کسی خاص Meme Coin کی current pool depth نہیں۔

Uniswap price impact explanation trade size کے pool liquidity پر اثر کو بیان کرتی ہے۔ Check کریں:

• correct token pair اور pool address
• active liquidity range
• reserve/depth
• small/medium/intended exit quotes
• price impact، fee، minimum received
• route alternatives
• token tax یا transfer restrictions
• LP ownership/lock claim

Reported 24h volume exit guarantee نہیں۔ Wash trading، one-sided activity اور concentration possible ہیں۔

Check 7: Supply اور mint risk

CoinGecko Supply Methodology circulating/total/max definitions کا provider context دیتی ہے۔ Contract totalSupply()، provider circulation اور project max الگ fields ہیں۔

Record:

• current total supply
• circulating estimate + exclusions
• coded/policy max
• mint authority
• burn mechanics
• bridge/multi-chain scope
• recent mint/burn events

Supply numbers reconcile نہ ہوں تو valuation calculate روکیں۔

Check 8: Unlocks اور allocations

یہ 2026-08 میں محفوظ BONK Paper کا historical project-document example ہے۔ Document allocation claim دکھاتا ہے، current locked balance یا completed vesting نہیں۔ Current chain evidence الگ درکار ہے۔

ہر allocation کے لیے amount، denominator، start، cliff، duration، beneficiary wallet اور actual release state لکھیں۔ Announcement، claimable اور sold states الگ رہیں۔

Check 9: Contract tests اور audit claims

Audit report ملے تو verify کریں:

• auditor کی official domain/repository
• exact contract commit/address
• audit date
• scope/excluded modules
• findings severity
• fixes verified یا صرف claimed
• deployment audit کے بعد بدلا؟

OWASP Smart Contract Security Testing Guide testing categories کا reference ہے۔ Audit zero-risk certificate نہیں؛ out-of-scope admin key، economic design یا later upgrade risk باقی رہ سکتے ہیں۔

Check 10: Website اور communication claims

Official links multiple sources سے match کریں۔ Search ad یا social reply سے contract copy نہ کریں۔ Website پر:

• team/organization claim
• legal entity/contact
• token utility
• roadmap status
• supply/vesting document
• security/audit links
• corrections/change log

Roadmap promise completion proof نہیں۔ Partnership logos کے لیے partner-side confirmation دیکھیں۔ Deleted pages کو archive میں دیکھ سکتے ہیں، مگر archive current endorsement نہیں۔

Check 11: Trading restrictions

Contract code اور actual quote دونوں دیکھیں۔ Warning signs:

• buy succeeds، sell reverts
• owner tax بدل سکتا ہے
• max-wallet/transaction dynamic
• blacklist path
• trading enable centralized
• router/pair mutable
• external handler opaque
• proxy upgraded recently

Test transaction کرنا financial action ہے؛ یہ site execute نہیں کرتی۔ Public simulation یا code inspection بھی complete guarantee نہیں۔ Unknown restriction ہو تو position نہ assume کریں۔

Check 12: Fraud اور platform risk

Investor.gov crypto asset securities alert fraud، volatility اور platform protections سمیت official risk context دیتی ہے۔ Private key/seed phrase مانگنے والا page، urgent countdown، guaranteed return یا impersonated support critical red flag ہے۔

Exchange listing rumor official listing proof نہیں۔ Listing موجود ہو تو بھی smart-contract، liquidity یا price risk ختم نہیں ہوتا۔

فرضی evidence matrix

یہ table final score نہیں۔ Stop condition کسی بھی row میں analysis روک سکتی ہے۔

Evidence freshness

Dynamic fields کے لیے last-checked date لکھیں: owner، roles، balances، pool liquidity، price quotes اور website claims بدل سکتے ہیں۔ Static standards کو بار بار screenshot کرنے کی ضرورت نہیں، مگر deployed state decision کے قریب دوبارہ read کریں۔ Old screenshot کو current proof نہ کہیں۔

کیا checklist سے “safe” کہا جا سکتا ہے؟

نہیں۔ Checklist visible risks اور evidence gaps کم کرتی ہے؛ unknown exploits، private agreements، compromised keys، market manipulation، legal actions یا sudden liquidity withdrawal ختم نہیں کرتی۔ بہتر conclusion “critical evidence gaps نہیں ملے/یہ gaps باقی ہیں” ہے، “safe coin” نہیں۔

Go، pause اور stop decision

Checklist کو score میں بدلنے کے بجائے action threshold لکھیں:

• Stop: contract identity conflict، sell route failure، hidden mint/upgrade path، fake audit یا official schedule contradiction
• Pause: large unknown holder، unexplained supply gap، liquidity evidence stale، admin ownership unclear
• Continue research: evidence mostly consistent مگر normal market risks باقی

Continue research buy recommendation نہیں۔ اس کا مطلب صرف یہ ہے کہ next verification step معلوم ہے۔ Stop item حل ہو تو نئی date کے ساتھ review دوبارہ کریں؛ پرانا status overwrite نہ کریں۔

Change-monitor list

Decision کے بعد dynamic fields کی watchlist رکھیں: owner/admin change، new implementation، mint/burn event، top-holder movement، liquidity withdrawal، schedule amendment اور official-domain change۔ Alert نہ ہو تو بھی اہم transaction کے قریب fresh check کریں۔ Static checklist screenshot کو indefinite approval stamp نہ بنائیں۔

ہر revisit میں صرف بدلی fields update کریں اور evidence URL محفوظ رکھیں۔ اس سے project narrative کے بجائے observable change history بنتی ہے۔

عام غلطیاں

• verified contract کو audited کہنا
• audit کو guarantee کہنا
• unknown holder کو team کہنا
• LP lock کو permanent liquidity کہنا
• renounced ownership میں proxy بھولنا
• old tokenomics کو current state کہنا
• social popularity کو identity proof بنانا
• market cap کو liquidity کہنا
• green checks جمع کر کے critical conflict ignore کرنا
• affiliate code کو token endorsement سمجھنا

Evidence packet کیسے محفوظ کریں؟

Risk review صرف browser tabs کا مجموعہ نہیں ہونا چاہیے۔ ہر session کے لیے ایک چھوٹا evidence packet بنائیں جس میں asset identity، observation time، source URL، field name، screenshot یا raw response، اور آپ کی interpretation الگ خانوں میں ہوں۔ Screenshot کو اصل data سمجھنے کے بجائے capture evidence کہیں؛ raw value اور method link ساتھ نہ ہو تو تصویر بعد میں قابلِ تکرار نہیں رہتی۔

Packet کی پہلی سطر میں chain، مکمل contract/mint، decimals اور review کا مقصد لکھیں۔ دوسری سطر میں block number یا RFC3339 timestamp دیں۔ پھر ہر claim کو ایک ID دیں، مثلاً C-01 mint authority، H-02 treasury wallet اور L-03 intended exit quote۔ Claim کے سامنے source اور status درج کریں۔ اس naming سے بعد میں معلوم رہتا ہے کہ کون سا red flag contract سے آیا، کون سا wallet classification سے اور کون سا صرف project statement تھا۔

Secret، API token، connected wallet، email یا account identifier packet میں نہ رکھیں۔ Public research کے لیے public endpoints کافی ہیں۔ کسی private account screen کی ضرورت پڑے تو اسے خودکار evidence workflow میں شامل نہ کریں۔

Critical stop rules پہلے لکھیں

Checklist شروع کرنے سے پہلے طے کریں کہ کون سی finding تحقیق کو فوراً روکے گی۔ یہ rule result دیکھنے کے بعد نہ بنائیں، ورنہ confirmation bias آسانی سے threshold بدل دے گا۔ مثال کے طور پر official address اور deployed contract میں mismatch، intended sell کا مسلسل fail ہونا، hidden proxy implementation، نامعلوم active mint role، یا supply figure کا orders-of-magnitude اختلاف critical stop ہو سکتا ہے۔

Stop rule کا مطلب ہمیشہ “scam ثابت” نہیں۔ اس کا مطلب یہ ہے کہ موجود evidence کے ساتھ risk accept کرنے کا جواز نہیں بنا۔ Status unresolved-critical رکھیں، missing evidence لکھیں اور نئی snapshot کے بغیر green نہ کریں۔ Social explanation، anonymous comment یا “community نے کہا ہے” critical contradiction ختم نہیں کرتا۔

تین severity lanes مفید ہیں:

• Critical: identity، sellability، admin control یا supply integrity پر براہ راست اثر
• Material: holder، unlock، liquidity یا methodology میں ایسا فرق جو valuation بدل سکتا ہے
• Context: branding، activity یا documentation quality کا اشارہ، مگر اکیلا فیصلہ نہیں

ایک critical unknown دس context positives سے cancel نہیں ہوتا۔ اسی لیے total score کے بجائے lane-by-lane conclusion لکھا جاتا ہے۔

Holder classification lab

Top-holder table سے پہلے raw top-10 اور top-20 share نکالیں۔ پھر addresses کو labels کے بجائے evidence کے ساتھ classify کریں۔ Explorer tag discovery ہے، proof نہیں۔ Exchange wallet کے لیے exchange کی اپنی address disclosure، repeated deposit pattern یا مضبوط explorer attribution دیکھیں۔ Burn address کے لیے spendability اور protocol mechanism سمجھیں۔ LP address کے لیے factory، pair tokens اور pool contract match کریں۔ Bridge vault کے لیے source/destination relationship اور mint-lock model پڑھیں۔

ہر exclusion کے ساتھ reason code لکھیں:

• EX-BURN: cryptographically یا protocol کے مطابق ناقابلِ خرچ
• EX-LP: verified liquidity pool، مگر LP control الگ check ہو گا
• EX-BRIDGE: verified lock/mint vault؛ double counting test باقی
• EX-EXCHANGE: مضبوط attribution والا omnibus wallet
• IN-UNKNOWN: identity ثابت نہیں، calculation میں شامل

Unknown whale کو team، exchange یا market maker نہ کہیں۔ Adjusted concentration ہمیشہ raw concentration کے ساتھ دکھائیں۔ اگر exclusion سے top-10 share 70% سے 25% ہو جائے تو conclusion exclusion assumptions پر شدید dependent ہے؛ اسے headline میں نمایاں کریں۔

Contract change surface map

Verified source دیکھ کر صرف keywords گننا کافی نہیں۔ ہر privileged path کے لیے actor، action، limit، delay اور current state لکھیں۔ owner() address ملنے کے بعد دیکھیں وہ EOA ہے، multisig ہے یا contract۔ AccessControl میں role admin کون ہے؟ Proxy میں implementation اور admin کہاں ہیں؟ External tax/treasury handler بعد میں بدل سکتا ہے؟ Pause یا blacklist پوری transfer path پر لاگو ہے یا صرف خاص addresses پر؟

Map کی ایک row یوں بنائیں: Actor → callable function → maximum effect → delay/timelock → present holder → evidence time۔ “Ownership renounced” صرف owner path کو address کرتی ہے؛ alternate roles، proxy admin اور external modules باقی ہو سکتے ہیں۔ اسی طرح verified bytecode audit، economic fairness یا key security کی guarantee نہیں۔

دو snapshots کے درمیان owner، role members، implementation، fee caps اور handler addresses compare کریں۔ Change آئے تو پرانی risk conclusion expire سمجھیں۔ Manual monitoring کا مقصد live alert کا دعویٰ نہیں؛ ہر اہم decision سے پہلے fresh state لینا ہے۔

Liquidity failure drill

Liquidity row میں TVL یا volume کا ایک عدد نہ لکھیں۔ Intended exit کو size ladder میں تقسیم کریں: چھوٹا diagnostic quote، درمیانہ quote، اور اپنی ممکنہ exit size۔ ہر quote کے لیے route، input، expected output، minimum received، fee، price impact، block/time اور quote expiry درج کریں۔

اگر چھوٹا quote چلتا ہے مگر بڑا quote fail ہو تو “token sellable ہے” لکھنا نامکمل ہے۔ اسے size-dependent exit risk کہیں۔ اگر route دوسرے token یا chain سے گزرتا ہے تو ہر hop الگ dependency ہے۔ High slippage tolerance liquidity پیدا نہیں کرتی؛ صرف خراب execution قبول کرنے کی حد بڑھاتی ہے۔ Quote کے بعد contract restriction، tax اور balance rules بھی دیکھیں، کیونکہ good pool depth honeypot-like restriction ختم نہیں کرتی۔

Transaction بھیجے بغیر quote research execution guarantee نہیں۔ State بدل سکتی ہے، competing trade آ سکتی ہے، network fee بڑھ سکتی ہے یا route expire ہو سکتا ہے۔ Worksheet میں quote اور completed receipt کو الگ evidence types رکھیں۔

Unlock اور treasury pressure review

Project schedule کو current unlock truth نہ کہیں۔ Allocation table، vesting contract، beneficiary wallets، release function، cliff، revocation یا ownership terms، اور actual transfer events کو جوڑیں۔ Document version اور publication date محفوظ کریں۔ اگر schedule میں “linear” لکھا ہو تو یہ بھی دیکھیں کہ release مسلسل claimable ہے یا periodic transaction سے نکلتی ہے۔

Treasury wallet سے exchange deposit risk کا اشارہ ہو سکتا ہے، مگر transfer خود sale ثابت نہیں۔ Destination attribution، transaction path اور بعد کا balance movement دیکھیں۔ اسی طرح unlock ہونے والے tokens لازماً فروخت نہیں ہوتے؛ worksheet صرف available supply اور potential pressure دکھاتی ہے۔ Conclusion میں plan، on-chain availability اور observed sale تین الگ columns رکھیں۔

Contradiction register

دو معتبر sources مختلف ہوں تو خاموشی سے ایک number نہ چنیں۔ دونوں readings، scope، time اور method ساتھ لکھیں۔ پھر فرق کو identity، decimals، chain coverage، excluded wallets، provider lag، price aggregation یا document version میں trace کریں۔ وجہ نہ ملے تو status unresolved رہے۔

Contradiction register میں یہ سوال ہوں:

1. کیا contract/mint بالکل ایک ہے؟
2. کیا دونوں sources ایک chain دکھاتے ہیں؟
3. raw اور display units درست ہیں؟
4. snapshot times کتنے مختلف ہیں؟
5. circulating definition میں کون سے wallets exclude ہیں؟
6. bridge یا wrapped supply double-count ہو رہی ہے؟
7. project document کا version current ہے؟

Unresolved difference کو average کر کے خوبصورت number بنانا evidence نہیں۔ Range دکھائیں اور دونوں scenarios کے نتیجے الگ نکالیں۔

Research environment safety

Due diligence کرتے ہوئے user کو token contract کے ساتھ interact کرنے کی ضرورت نہیں۔ Public explorer، verified documentation اور read-only quote سے زیادہ تر ابتدائی سوال حل ہو سکتے ہیں۔ Unknown website پر wallet connect کرنا، message sign کرنا، token approval دینا یا executable file download کرنا research step نہیں۔ Checklist میں no-wallet research default رکھیں۔

Domain کو official project channel سے cross-check کریں، مگر social profile کا blue badge domain ownership کی مکمل ضمانت نہیں۔ Browser history یا search ad سے ملنے والے clone page پر contract copy نہ کریں۔ Downloaded document کا source URL اور file hash محفوظ کیا جا سکتا ہے، لیکن private key، seed phrase یا login code کبھی research artifact میں نہیں آتا۔

Contract address paste کرتے وقت first/last characters دیکھنے کے علاوہ پورا string machine-readable field سے compare کریں۔ Address poisoning میں ملتے جلتے آغاز اور اختتام استعمال ہو سکتے ہیں۔ QR code یا shortened link کو canonical source نہ سمجھیں۔ اگر chain explorer wrong network کھولے تو symbol match ہونے کے باوجود identity unresolved ہے۔

Approval exposure audit

اگر user پہلے ہی token یا dApp کے ساتھ interact کر چکا ہو تو wallet approvals الگ risk layer ہیں۔ Token balance zero ہونے سے unlimited approval خود ختم نہیں ہوتی۔ Approved spender، allowance amount، chain اور last interaction دیکھیں۔ Revoke transaction بھی on-chain action ہے؛ official wallet/explorer instructions اور network fee verify کیے بغیر random revoke site استعمال نہ کریں۔

Worksheet میں approval کو token contract permission سے الگ رکھیں۔ Token owner roles پورے asset behavior کو بدل سکتے ہیں؛ user approval کسی spender کو مخصوص wallet کے tokens خرچ کرنے کی اجازت دے سکتی ہے۔ دونوں خطرات مختلف actors اور remedies رکھتے ہیں۔ “Contract ownership renounced” user کی پرانی malicious approval کو safe نہیں بناتا۔

Evidence aging rules

ہر evidence کی عمر ایک جیسی نہیں۔ Standard document نسبتاً stable ہو سکتی ہے، مگر owner address، pool liquidity، top holders، quote اور unlock balance تیزی سے بدل سکتے ہیں۔ Review شروع کرتے وقت freshness class دیں:

• Event-triggered: upgrade، migration، mint/burn، unlock یا exploit کے بعد فوراً دوبارہ check
• Decision-time: price، route، liquidity، holder balances اور approvals ہر عملی decision سے پہلے
• Version-triggered: methodology، tokenomics document یا contract implementation بدلنے پر
• Stable reference: protocol standard، مگر نئی revision آئے تو citation update

ایک پرانی screenshot اپنی capture date کے لیے درست evidence ہو سکتی ہے، current state نہیں۔ Checklist green status کے ساتھ valid_at لکھیں؛ material state change ملے تو status expire کر دیں۔ Calendar reminder مدد کر سکتا ہے مگر event-driven recheck کی جگہ نہیں لیتا۔

Claim-to-evidence matrix

Project کے ہر بڑے claim کو ایک independent row میں رکھیں۔ “Liquidity locked”، “ownership renounced”، “fixed supply”، “fair launch”، “audited” اور “multi-chain” الگ claims ہیں؛ ایک audit badge سب کو prove نہیں کرتا۔ Claim source، exact wording، supporting on-chain/document evidence، contradiction اور status لکھیں۔

Audit report کے لیے exact contract address، chain، version/commit اور scope match کریں۔ Report پرانے implementation یا صرف library code کی ہو تو current deployed contract covered نہیں سمجھا جاتا۔ Audit vulnerabilities نہ ملنے کو future exploit ناممکن ہونے کا ثبوت نہ کہیں۔

“Community-owned” claim کے لیے holder distribution کے علاوہ treasury keys، website/domain control، upgrade admin، liquidity ownership اور governance execution دیکھیں۔ Marketing label legal یا technical control map کی جگہ نہیں لیتا۔

Decision record: proceed، pause یا reject

Checklist investment signal نہیں، مگر research process کا next action طے کر سکتی ہے۔ Proceed to deeper review کا مطلب صرف یہ ہے کہ identity اور critical controls پر فوری contradiction نہیں ملا۔ Pause کا مطلب missing evidence material ہے۔ Reject current evidence کا مطلب available data آپ کے پہلے سے لکھے stop rule سے ٹکراتا ہے؛ token کو universally fraudulent کہنا ضروری نہیں۔

Decision record میں risk budget یا expected return نہ گھڑیں۔ یہ لکھیں کہ کون سا سوال resolved ہے، کون سا نہیں، اور اگلا evidence کیا چاہیے۔ مثال: “Sell quote چھوٹے size پر available ہے، intended size پر route fail ہے؛ contract source verified ہے مگر proxy admin unresolved؛ current review pause ہے۔”

نئی evidence آئے تو previous record overwrite نہ کریں۔ نئی dated revision بنائیں اور status change کی وجہ لکھیں۔ اس سے بعد میں معلوم ہوتا ہے کہ decision market move سے بدلا، methodology correction سے یا contract state change سے۔

Worked review: فرضی asset کا evidence flow

یہ مثال صرف process دکھاتی ہے؛ نام، addresses اور numbers فرضی ہیں۔ Asset M کے official document میں Ethereum contract 0x…A1 درج ہے۔ Explorer پر یہی address اور 9 decimals match ہوتے ہیں، مگر page title میں ایک پرانا symbol بھی نظر آتا ہے۔ Identity status supported ہے، کیونکہ migration notice ابھی check ہونا باقی ہے۔ Researcher symbol سے search جاری رکھنے کے بجائے old/new address relation تلاش کرتا ہے۔

Source verified ہے اور Ownable کے ساتھ external fee handler دکھتا ہے۔ Current owner multisig address ہے، مگر signer threshold public interface سے واضح نہیں۔ Fee handler بدلنے کی function reachable ہے اور maximum cap code reading سے 10% نظر آتی ہے۔ Current UI tax 2% دکھاتی ہے۔ Record یہ نہیں کہتا کہ tax ہمیشہ 2% رہے گی؛ وہ current observation 2%, reachable cap 10%, admin delay unresolved لکھتا ہے۔

Holder list میں raw top-10 share 68% ہے۔ Verified pool 22%، bridge vault 15%، attributed exchange wallet 8% اور unknown wallet 9% رکھتا ہے۔ Pool، bridge اور exchange exclusions کے بعد adjusted top-10 31% بنتی ہے، مگر bridge model lock-and-mint ہونے کا صرف project claim ملا ہے۔ اس لیے primary conclusion raw 68%، supported-adjusted 46% (صرف pool/exchange exclusion) اور conditional 31% (bridge exclusion) تین rows میں رکھتا ہے۔

Liquidity test میں چھوٹا sell quote available، درمیانہ quote کا impact نمایاں اور intended size پر route output غیرموزوں ہے۔ Checklist sellable کا binary green check نہیں دیتی۔ Status small-size route observed; intended-size exit risk material ہے۔ No transaction submit کیا گیا، اس لیے quote completed execution نہیں۔

Unlock document اگلے مہینے allocation release دکھاتا ہے، مگر beneficiary wallet اور vesting contract match نہیں ہوئے۔ Schedule issuer claim، contract mechanism unknown اور observed sale not established رہتے ہیں۔ Final decision pause ہے، scam verdict نہیں۔ Required next evidence migration notice، multisig threshold، bridge vault proof اور beneficiary mapping ہے۔

یہ example دکھاتی ہے کہ ہر layer الگ status رکھتی ہے۔ ایک verified source باقی unknowns ختم نہیں کرتی، اور ایک بڑا raw holder number wallet categories جانے بغیر مکمل conclusion نہیں۔

Red-team سوالات

Final note لکھنے سے پہلے اپنی پسندیدہ conclusion کے خلاف سوال کریں:

• اگر official site compromise ہو تو contract identity کا دوسرا anchor کیا ہے؟
• اگر explorer tag غلط ہو تو wallet category کس evidence پر قائم ہے؟
• اگر proxy upgrade ہو جائے تو reviewed source کتنی دیر relevant رہے گی؟
• اگر liquidity کا بڑا حصہ inactive range میں ہو تو displayed TVL کیا چھپا رہی ہے؟
• اگر bridge vault exclude نہ کیا جائے تو concentration اور supply کیسے بدلیں گے؟
• اگر intended exit quote half size پر لیا جائے تو result کتنا بدلتا ہے؟
• اگر next unlock نہ بکے تو dilution conclusion کی زبان کیا ہو گی؟
• اگر project document delete ہو جائے تو claim کی محفوظ version اور date موجود ہے؟

Red-team سوال کا مقصد ہر asset کو خطرناک ثابت کرنا نہیں۔ مقصد یہ ہے کہ conclusion صرف compatible evidence پر قائم رہے اور missing layer صاف نظر آئے۔

Project communication کو evidence میں کیسے رکھیں؟

Announcement، FAQ، social post اور whitepaper issuer evidence ہیں۔ Exact wording، publication date اور version محفوظ کریں۔ “Locked”، “burned”، “renounced” اور “audited” جیسے لفظ operational definition کے بغیر green check نہیں بنتے۔ Lock کس contract میں، کس beneficiary کے لیے، کس وقت تک؟ Burn supply function کم کرتی ہے یا dead address balance ہے؟ Renounced کون سا role، جبکہ proxy admin یا handler باقی ہے؟ Audit کس chain/address/version کا؟

Project correction useful evidence ہے، مگر prior contradiction کی history overwrite نہ کریں۔ Updated claim کے ساتھ on-chain check دوبارہ کریں۔ Deleted announcement automatically fraud ثابت نہیں، مگر transparency risk note بن سکتا ہے۔

ہر claim کے لیے expiry trigger بھی لکھیں۔ Contract upgrade، role transfer، liquidity unlock، bridge migration یا نئی tokenomics version آئے تو پرانی green status خودکار طور پر current نہیں رہتی۔ Claim card پر recheck_on event لکھنے سے checklist static badge بننے کے بجائے dated research record رہتی ہے۔

اگر project representative clarification دے تو اسے issuer response label کے ساتھ محفوظ کریں۔ Private message کو public chain state سے اوپر نہ رکھیں، اور identity verify کیے بغیر anonymous reply کو official clarification نہ کہیں۔

Review handoff template

اگر دوسرا researcher packet کھولے تو اسے browser history کے بغیر calculation دوبارہ بنا سکنا چاہیے۔ Handoff میں identity، used sources، rejected sources، assumptions، formulas، screenshots کے capture month، open questions اور next trigger لکھیں۔ ہر conclusion کے ساتھ “valid as of” timestamp دیں۔

ایک مفید handoff sentence یوں ہے: “Identity اور decimals confirmed ہیں؛ admin role supported ہے مگر multisig ownership unresolved؛ top-holder adjusted share bridge exclusion پر dependent ہے؛ intended exit quote صرف observation time پر valid تھا؛ next unlock project schedule سے documented ہے مگر current beneficiary balance دوبارہ دیکھنا باقی ہے۔” یہ زبان certainty اور uncertainty دونوں محفوظ رکھتی ہے۔

Final note template

“Asset identity ___ evidence سے confirmed ہے۔ Contract میں ___ permissions observed ہیں اور admin state ___ ہے۔ Adjusted top-holder share ___، intended exit quote ___ اور next documented unlock ___ ہے۔ یہ issues unresolved/contradicted ہیں: ___. اس review سے safety یا return guarantee نہیں نکلتی۔”

نتیجہ ہمیشہ واضح evidence status کے ساتھ محفوظ کریں۔

آخری checklist

• official address full match
• proxy/implementation/admin checked
• mint/pause/blacklist/tax roles
• top holders classified
• LP/pool identity verified
• three exit-size quotes
• supply labels reconciled
• unlock wallets/events checked
• audit exact address/commit match
• website claims independently checked
• timestamps recorded
• critical unknowns visible

Meme Coin risk article اور contract permissions guide مزید context دیتی ہیں۔

یہ worksheet educational ہے، financial/security advice یا token endorsement نہیں۔ Fraud، exploits، liquidity loss اور extreme volatility سے مکمل سرمایہ ضائع ہو سکتا ہے۔ اہل صارف Binance دعوتی کوڈ BN8812 اپنی صوابدید پر استعمال کر سکتا ہے۔ سائٹ آپریٹر کے مطابق spot trading fee پر زیادہ سے زیادہ 20% رعایت ممکن ہے؛ actual rate، eligibility، regional availability اور current Binance rules خود verify کریں۔