ٹوکن کنٹریکٹ کی Mint اور Admin Permissions کیسے چیک کریں؟

کسی token contract میں mint، owner یا tax کا لفظ مل جانا صرف ایک سراغ ہے۔ اصل سوال یہ ہے کہ کون سی privileged function واقعی قابلِ رسائی ہے، اسے آج کون چلا سکتا ہے، اور کیا proxy کے ذریعے کل logic بدلی جا سکتی ہے۔ یہ طریقہ اس قاری کے لیے ہے جو block explorer سے ثبوت جمع کرنا چاہتا ہے، مگر Solidity audit کا دعویٰ نہیں کرتا۔

مختصر جواب: contract permissions جانچنے کے لیے پہلے درست chain اور address ثابت کریں، پھر verified source اور proxy status دیکھیں، اس کے بعد owner، roles، handlers اور موجودہ read-only values نوٹ کریں۔ ہر نتیجے کے ساتھ block یا وقت لکھیں۔ “verified source” کو “safe token” اور “renounced ownership” کو “کوئی admin اختیار نہیں” سمجھنا دونوں غلط ہیں۔

اس صفحے میں کیا چیک ہوگا؟

• درست network، مکمل contract address اور token identity
• source verification کا مطلب اور اس کی حد
• direct contract، proxy اور implementation کا فرق
• mint، burn، pause، blacklist، trading اور transfer limits
• buy/sell tax، fee destination اور handler contracts
• owner کے علاوہ roles، multisig، timelock اور upgrade admin
• current state، events اور transaction history سے ثبوت
• نوٹس لکھنے کا ایسا طریقہ جس میں معلوم اور نامعلوم چیز الگ رہے

تحقیق read-only رہ سکتی ہے۔ کسی explorer پر public source یا getter دیکھنے کے لیے wallet connect، seed phrase، private key یا signature کی ضرورت نہیں۔ ایسی چیز مانگنے والی غیر مانوس سائٹ بند کر دیں۔

پہلا قدم: صحیح contract کی شناخت کیسے ثابت کریں؟

سب سے پہلے project کا نام نہیں بلکہ chain اور مکمل address ملائیں۔ ایک ہی ticker کئی chains یا بالکل مختلف contracts پر استعمال ہو سکتا ہے۔ Search engine کے پہلے نتیجے، social post یا wallet logo کو ثبوت نہ بنائیں۔ project کی official documentation یا official announcement سے address لیں، پھر اسی network کے explorer میں کھولیں۔

حقیقی Blockscout API ریکارڈ، اسکرین شاٹ 2026-08 میں لیا گیا۔ یہ Ethereum address کی شناخت اور اس وقت دکھائی گئی metadata ہے، safety rating نہیں۔

اوپر کی تصویر Blockscout address API کا 2026-08-01T18:03:55+08:00 snapshot ہے۔ اس میں مکمل address، token نام، symbol اور is_verified: true دکھائی دیتا ہے۔ یہاں سے صرف اتنا اخذ کیا جا سکتا ہے کہ explorer نے اس address کے ساتھ یہ metadata جوڑی ہوئی تھی۔ تصویر میں exchange_rate اور total_supply بھی ہیں، مگر وہ permissions ثابت نہیں کرتے اور نہ اس صفحے میں انہیں موجودہ قیمت یا supply کے طور پر استعمال کیا گیا ہے۔

اپنے نوٹ کی پہلی سطر یوں بنائیں:

اگر official source اور explorer address نہ ملیں تو وہیں رک جائیں۔ غلط contract کا بڑا audit بھی بے فائدہ ہے۔ holder concentration الگ سوال ہے؛ address ملانے کے بعد اسے بڑے holders کی جانچ کے ساتھ پڑھا جا سکتا ہے۔

Verified source دراصل کیا ثابت کرتا ہے؟

Verified source عام طور پر یہ بتاتا ہے کہ جمع کرایا گیا source code، compiler settings اور deployed bytecode کے درمیان explorer کی verification process کے مطابق تعلق ملا۔ Blockscout کی verification API دستاویز مختلف verification inputs دکھاتی ہے، جبکہ Etherscan کا source-code endpoint verified contract کے source، compiler، proxy اور implementation جیسے fields واپس کر سکتا ہے۔

یہ security audit نہیں۔ verification malicious logic کو اچھا نہیں بناتی، external handler کے رویے کی ضمانت نہیں دیتی، اور current storage values نہیں بتاتی۔ similar-match label ہو تو یہ بھی دیکھیں کہ explorer نے exact match دکھایا ہے یا کسی دوسرے deployment سے مماثلت۔ compiler version، optimization، constructor arguments اور linked libraries جیسی metadata اختلاف پیدا کر سکتی ہے۔

صفحے کے آغاز میں دکھائی گئی حقیقی cover image Blockscout smart-contract record سے 2026-08-01T17:54:29+08:00 پر لی گئی تھی۔ visible حصہ contracts/Floki.sol، Ownable، taxHandler اور treasuryHandler references دکھاتا ہے۔ محتاط نتیجہ یہ ہے: source میں یہ اجزا نظر آئے؛ ان کے current addresses، callable functions اور controller الگ verify کرنے ہوں گے۔ یہ کہنا درست نہیں کہ صرف taxHandler کا لفظ ملنے سے موجودہ tax معلوم ہوگیا۔ cover screenshot source references دکھاتی ہے؛ handler کی موجودہ authority یا token کی حفاظت ثابت نہیں کرتی۔

Source پڑھتے وقت capability map کیسے بنائیں؟

Source search مفید ہے، مگر keyword list پر تحقیق ختم نہیں ہونی چاہیے۔ ہر privileged راستے کے لیے ایک capability map بنائیں:

“Function موجود ہے” اور “function قابلِ رسائی ہے” دو مختلف دعوے ہیں۔ Internal _mint standard library کا حصہ ہو سکتا ہے مگر کوئی external/public راستہ اسے call نہ کرتا ہو۔ اسی طرح Pausable import ہونے سے transfer خود بخود pausable نہیں بنتا۔ OpenZeppelin Pausable documentation واضح کرتی ہے کہ متعلقہ modifiers اور authorized pause/unpause path بھی implementation میں شامل ہونا چاہیے۔

Mint اور supply permissions کو کیسے پرکھیں؟

Mint risk کا سوال “کیا source میں _mint ہے؟” نہیں بلکہ “deployment کے بعد نئی units بنانے کا reachable راستہ کیا ہے؟” ہے۔ Ethereum کی ERC-20 وضاحت totalSupply، balances، transfers اور approvals جیسے standard interface اجزا بتاتی ہے؛ ERC-20 standard خود fixed supply کی ضمانت نہیں دیتا۔

یہ ترتیب اپنائیں:

1. mint، _mint، issue، rebase، bridge اور migration الفاظ تلاش کریں۔
2. function visibility دیکھیں: external، public، internal یا private۔
3. modifier یا inline check پڑھیں: onlyOwner، onlyRole، msg.sender == ... یا custom manager۔
4. caller کسی دوسرے contract کا address ہو تو اسے بھی کھولیں۔
5. cap ہے تو دیکھیں hard-coded ہے، storage value ہے یا admin اسے بدل سکتا ہے۔
6. current supply کو snapshot سمجھیں؛ future issuance rule source اور state سے آئے گا۔

Burn کی موجودگی mint کو cancel نہیں کرتی۔ bridge token میں mint/burn cross-chain accounting کا حصہ ہو سکتا ہے؛ پھر bridge controller اور canonical contract بھی scope میں آتے ہیں۔ supply بڑھنے کے ممکنہ معاشی اثر کو token dilution کی وضاحت سے سمجھیں، مگر calculator یا supply table contract permission کا ثبوت نہیں۔

Transfer روکنے یا محدود کرنے والی permissions کہاں ملتی ہیں؟

Transfer controls میں pause، blacklist، whitelist، max wallet، max transaction، cooldown، trading enabled اور automated-market-maker pair exemptions شامل ہو سکتے ہیں۔ نام سے نتیجہ نہ نکالیں؛ وہ code path دیکھیں جس سے user کا transfer گزرتا ہے۔

مثلاً یہ سوال الگ الگ لکھیں:

• کیا ordinary transfer paused state میں revert کرتا ہے؟
• blacklist کس address پر لگ سکتی ہے اور کون لگاتا یا ہٹاتا ہے؟
• max wallet اور max transaction limits کا current value کیا ہے؟
• owner بعض addresses کو limits سے exempt کر سکتا ہے؟
• trading switch صرف launch کے لیے تھا یا اب بھی callable ہے؟
• restriction main token میں ہے یا external handler میں؟

Read interface میں current values ملیں تو screenshot یا text note کے ساتھ block/وقت محفوظ کریں۔ Getter نہ ہو تو raw storage یا simulation زیادہ تخصص مانگتی ہے؛ ایسے میں “نامعلوم” لکھنا “کوئی limit نہیں” لکھنے سے بہتر ہے۔ Past transactions نہ ملنا اس بات کا ثبوت نہیں کہ function چل نہیں سکتی۔

Tax، fee اور handler contracts میں کیا دیکھا جائے؟

Tax analysis تین حصوں میں کریں: rate، trigger اور destination۔ Buy اور sell rate الگ ہو سکتے ہیں؛ wallet-to-wallet transfer پر مختلف branch چل سکتی ہے؛ exempt address پر rate صفر ہو سکتا ہے۔ fee tokens میں amount contract، treasury، liquidity routine یا کسی external handler کو جا سکتی ہے۔

ہر handler کے لیے یہ چیک کریں:

1. current handler address کس getter یا event سے ملا؟
2. address contract ہے یا EOA؟
3. handler source verified ہے؟
4. main token اسے کن functions پر call کرتا ہے؟
5. handler address بدلا جا سکتا ہے، اور بدلنے والا controller کون ہے؟
6. rate کے hard maximum اور current value میں فرق کیا ہے؟
7. exemptions کون بدل سکتا ہے؟

Screenshot میں taxHandler اور treasuryHandler reference نظر آنا صرف dependency کا اشارہ ہے۔ مکمل نتیجہ تب بنے گا جب referenced addresses اور current state بھی مل جائیں۔ اگر وہ دستیاب نہ ہوں تو واضح لکھیں: “source میں handler dependency ملی، مگر current controller اور effective limits verify نہیں ہوئے۔”

Owner، roles، multisig اور timelock کو الگ کیوں دیکھیں؟

Simple ownership صرف ایک ممکنہ access model ہے۔ OpenZeppelin access-control guide کے مطابق Ownable ایک owner کو restricted functions دے سکتا ہے، جبکہ AccessControl مختلف accounts کو minter، admin یا دوسری granular roles دے سکتا ہے۔ DEFAULT_ADMIN_ROLE دوسرے roles کو grant/revoke کرنے کی طاقت رکھ سکتا ہے، اس لیے صرف owner() پڑھنا ناکافی ہے۔

یہ سوال پوچھیں:

• owner() کا current address کیا ہے؟
• onlyOwner کن externally reachable functions پر لگا ہے؟
• AccessControl، custom roles یا manager contract موجود ہے؟
• ہر role کا admin کون ہے، اور role grant/revoke ہو سکتا ہے؟
• controller EOA ہے، multisig ہے، DAO ہے یا timelock؟
• multisig threshold اور signers public طور پر verify ہو سکتے ہیں؟
• timelock delay واقعی privileged operation پر لاگو ہے؟

Ownership renounced ہونے کا دعویٰ current on-chain getter اور transaction سے ملائیں۔ پھر بھی proxy admin، role admin، handler owner، bridge controller یا دوسرے contract کی authority باقی ہو سکتی ہے۔ owner zero address دکھنے سے پورے system کی تمام permissions خود بخود ختم نہیں ہوتیں۔

Multisig یا timelock عموماً single EOA کے مقابلے میں مختلف control structure دکھاتے ہیں، مگر انہیں safety certificate نہ بنائیں۔ signers، threshold، delay اور scope نامعلوم ہوں تو صرف contract label کی بنیاد پر مضبوط governance نہ لکھیں۔

Proxy اور implementation کیسے پہچانیں؟

Proxy میں user ایک stable address سے interact کرتا ہے، مگر logic دوسرے implementation contract میں ہو سکتی ہے۔ OpenZeppelin proxy-pattern guide اس forwarding model کو بیان کرتی ہے: proxy state رکھ سکتا ہے اور calls implementation کو delegate کر سکتا ہے، جبکہ authorized upgrade implementation بدل سکتی ہے۔

Explorer کا “proxy” badge اچھا آغاز ہے، آخری ثبوت نہیں۔ ERC-1967 implementation، beacon اور admin کے standard storage slots اور Upgraded/AdminChanged events بیان کرتا ہے۔ عملی طور پر یہ چیزیں نوٹ کریں:

• user-facing proxy address
• current implementation address
• proxy type اگر معلوم ہو: transparent، UUPS یا beacon
• upgrade authority یا ProxyAdmin owner
• implementation source verification
• recent Upgraded، AdminChanged یا beacon events
• implementation کب بدلی اور موجودہ version کون سا ہے

Proxy ثابت نہ ہو تو صرف upgrade keyword دیکھ کر upgradeable نہ لکھیں۔ Proxy ثابت ہو تو صرف proxy shell کا source پڑھ کر نہ رکیں؛ current implementation اور upgrade authority اصل scope کا حصہ ہیں۔ UUPS میں upgrade authorization implementation میں ہو سکتی ہے، transparent proxy میں ProxyAdmin chain دیکھنی پڑ سکتی ہے، اور beacon ایک سے زیادہ proxies کی logic بدل سکتا ہے۔

Current state اور transaction history کو کیسے ملائیں؟

Source capability بتاتا ہے؛ current state بتاتی ہے کہ capability ابھی کس configuration میں ہے۔ دونوں کے بغیر نتیجہ ادھورا ہے۔ Read-only workflow یوں رکھیں:

1. explorer کے Read Contract حصے یا trusted RPC سے owner، paused، role membership، fee values، limits اور handler addresses پڑھیں۔
2. ہر returned address کو الگ explorer tab میں کھول کر contract/EOA، verification اور ownership دیکھیں۔
3. privileged function کے events اور transactions تلاش کریں۔
4. proxy ہو تو implementation/admin slots اور explorer label کو cross-check کریں۔
5. ہر observation کے ساتھ block number یا timezone والا وقت لکھیں۔
6. جس getter یا event کا مطلب واضح نہ ہو اسے “unresolved” رکھیں۔

Solidity کا access-restriction pattern یاد دلاتا ہے کہ state پڑھنا اور state بدلنے کی اجازت الگ تصورات ہیں۔ Public chain پر bytecode، transactions اور public state دیکھی جا سکتی ہے، مگر custom assembly، external dependencies یا undocumented encoding کی درست تشریح specialist review مانگ سکتی ہے۔

ایک فرضی finding کو درست زبان میں کیسے لکھیں؟

یہ مثال کسی حقیقی token کا نتیجہ نہیں؛ صرف evidence-writing کی مشق ہے۔ فرض کریں source میں setFeeHandler(address) ایک admin modifier کے ساتھ ملا، current handler contract verified نہیں، اور proxy status ابھی resolve نہیں ہوا۔

کمزور جملہ: “Developer جب چاہے tax بدل کر صارفین کے tokens روک سکتا ہے۔”

بہتر جملہ: “Verified source میں fee-handler address بدلنے والی restricted function ملی۔ موجودہ controller اور handler code ابھی verify نہیں ہوئے، اور proxy status unresolved ہے؛ اس لیے effective fee authority اور اس کی حد نامعلوم ہے۔”

دوسری فرضی صورت میں owner() zero address واپس کرے، مگر source میں role-based minter بھی ہو۔ کمزور جملہ “ownership renounced، اس لیے mint ناممکن ہے” ہوگا۔ بہتر جملہ یہ ہے: “Ownable owner zero address دکھا رہا ہے؛ الگ minter role کی membership اور role admin ابھی جانچنا باقی ہے۔”

اس زبان میں capability، current control اور missing evidence الگ رہتے ہیں۔ قاری کو certainty کا غلط تاثر نہیں ملتا۔

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

ہر اہم finding کے لیے مختصر card بنائیں:

Explorer page بدل سکتا ہے، اس لیے URL کے ساتھ screenshot month، full address اور timestamp رکھیں۔ API response میں قیمت یا supply جیسے incidental fields آئیں تو انہیں permission evidence نہ بنائیں۔ Contract analysis میں scope صاف رکھنا زیادہ اہم ہے بنسبت اس کے کہ ہر field کو کسی نتیجے سے جوڑ دیا جائے۔

عام غلطیاں کون سی ہیں؟

• ticker یا logo سے contract شناخت کر لینا
• verified source کو audit report سمجھ لینا
• _mint دیکھ کر external mint authority فرض کر لینا
• owner() دیکھ کر تمام roles اور handlers نظر انداز کرنا
• renounced owner سے proxy admin بھی ختم سمجھنا
• proxy address پڑھنا مگر implementation نہ کھولنا
• current tax کو source کے maximum یا default سے خلط کرنا
• “admin function کبھی استعمال نہیں ہوئی” کو “ناقابلِ استعمال” کہنا
• دوسرے chain کے contract سے نتیجہ نقل کرنا
• read-only research کے لیے wallet signature دینا

یہی غلطیاں meme coin کے risk review کو binary verdict میں بدل دیتی ہیں۔ بہتر نتیجہ “safe/scam” label نہیں بلکہ permissions کی قابلِ تصدیق فہرست ہے۔ اسے میم کوائن risk checklist میں liquidity، holder concentration، supply اور contract control کے الگ خانوں کے ساتھ رکھیں۔ Liquidity کے operational risks کے لیے liquidity check الگ مکمل کریں؛ contract source pool depth نہیں بتاتا۔

آخری review checklist

• official source، network اور مکمل contract address match کیے گئے۔
• source verification type، compiler context اور proxy label نوٹ ہوا۔
• mint، burn، pause، blacklist، limits، fees اور trading switches کی reachable paths پڑھی گئیں۔
• owner کے علاوہ roles، role admins، handlers، multisig اور timelock دیکھے گئے۔
• proxy ہونے پر implementation، admin/beacon اور upgrade history چیک ہوئی۔
• current getters کے ساتھ block یا timezone والا وقت محفوظ ہوا۔
• screenshot کے incidental price/supply fields کو current claim نہیں بنایا گیا۔
• unknown کو “safe” یا “permissionless” قرار نہیں دیا گیا۔
• کسی مرحلے پر seed phrase، private key یا wallet signature نہیں دیا گیا۔

یہ مضمون تعلیمی تحقیق ہے، مالی مشورہ یا مکمل smart-contract audit نہیں۔ Verified source بھی hidden dependency، upgrade، configuration error یا code vulnerability سے مکمل تحفظ نہیں دیتی؛ غلط تشریح اور token loss ممکن ہیں۔ اہل صارف اپنی مرضی سے بائنانس دعوتی کوڈ BN8812 استعمال کر سکتا ہے۔ سائٹ آپریٹر کے مطابق اسپاٹ ٹریڈنگ فیس پر زیادہ سے زیادہ 20% رعایت ممکن ہے؛ اصل شرح، اہلیت، علاقائی دستیابی اور موجودہ شرائط بائنانس پر خود تصدیق کریں۔