Wallet کے ہر popup کو “sign” نہ کہیں: پہلے سمجھیں اجازت کس چیز کی ہے

Wallet request کی قسم چند سیکنڈ میں کیسے پہچانیں؟

دیکھیں کہ popup میں gas، readable message، spender، asset change یا contract call موجود ہے یا نہیں۔ Address connect عموماً gas نہیں مانگتا۔ Message signature خود block میں شامل نہیں ہوتی۔ Approve اور transfer on-chain transactions ہیں۔ Permit بسا اوقات gas کے بغیر sign ہوتا ہے مگر بعد میں کوئی دوسرا اسے submit کر کے allowance چلا سکتا ہے۔

Wallet brands کے الفاظ مختلف ہوتے ہیں۔ “Details”، “Data”، “Permission” یا “Advanced” کھولیں۔ اہم field دکھائی نہ دے تو website کی اپنی “safe” تحریر آزاد ثبوت نہیں۔ Reject کرنے سے جائز asset غائب نہیں ہوتا؛ official flow دوبارہ شروع کیا جا سکتا ہے۔

صرف Connect Wallet سے website کیا جان سکتی ہے؟

Connect عموماً منتخب public address، active chain اور wallet capability website کو دیتا ہے؛ یہ token spending approval نہیں۔ پھر بھی privacy cost موجود ہے۔ Public address کی history دیکھی جا سکتی ہے اور site اسے browser session، social login یا campaign profile سے جوڑ سکتی ہے۔

Testnet کے لیے الگ wallet رکھنا main holding address کی غیر ضروری exposure کم کرتا ہے۔ الگ account اور الگ seed کا فرق سمجھیں۔ ایک seed کے accounts کا رشتہ chain پر لازماً صاف نہیں، مگر ایک دوسرے کو funds بھیجنے یا یکساں استعمال سے pattern بن سکتا ہے۔ نامعلوم task page پر high-value wallet connect نہ کرنا بہتر ہے۔

Connect کے فوراً بعد آنے والے popup کو نئی درخواست سمجھیں۔ Phishing page پہلے harmless connection لیتا ہے، پھر user کی توجہ کم ہونے پر approve یا permit دکھاتا ہے۔ پہلے popup کا کم خطرہ دوسرے کو محفوظ نہیں بناتا۔ مسلسل requests آئیں تو سب cancel کر کے official steps پڑھیں۔

Wallet میں Connected sites سے disconnect کرنے پر front-end session ختم ہوتا ہے، on-chain approval نہیں۔ Browser history صاف کرنا، wallet lock کرنا یا extension دوبارہ install کرنا بھی allowance ختم نہیں کرتا۔ Privacy connection اور blockchain permission الگ records ہیں۔

personal_sign login message کب نسبتاً محفوظ سمجھا جا سکتا ہے؟

Readable message جس میں درست domain، واضح مقصد اور nonce ہو عموماً محدود login کے لیے ہوتا ہے، مگر blind sign پھر بھی درست نہیں۔ EIP-191 signed data کو عام transaction سے الگ کرنے کے لیے prefix کا معیار دیتا ہے؛ یہ message کے مقصد کو سچا ثابت نہیں کرتا۔

ایک بہتر login message کی نشانیاں

Service domain، wallet address، login statement، random nonce، issued time اور ضرورت کے مطابق expiry دکھنی چاہیے۔ Browser domain اور message domain ملائیں۔ “Sign in to example.org” سمجھ میں آتا ہے؛ نامعلوم domain، غیر محدود terms یا asset سے متعلق مبہم اقرار آئے تو reject کریں۔

Zero gas کا مطلب zero risk نہیں

Message local wallet میں sign ہوتا ہے، اس لیے gas نہیں لگتا۔ Signature سے service ثابت کر سکتی ہے کہ address controller نے کوئی statement قبول کیا۔ Malicious site اسے login token، marketplace order یا دوسرے authorization کے لیے استعمال کر سکتی ہے۔ Gas صرف fee بتاتا ہے، permission کی قدر نہیں۔

Hex message کیوں روکنے کی وجہ ہے؟

اگر مکمل payload انسانی زبان میں نہ پڑھے تو sign نہ کریں اور project docs میں method تلاش کریں۔ Hardware wallet screen مختصر ہو تو desktop wallet interface میں full data دیکھیں۔ Website کے پاس لکھا “یہ صرف verification ہے” کافی نہیں، کیونکہ request اسی website نے بنائی ہے۔

Login signature کے ساتھ seed phrase، password یا OTP form میں نہیں دیا جاتا۔ Wallet خود signature بناتا ہے۔ کوئی page secret مانگے تو flow بند کریں۔ Support کے لیے public address اور message context کافی ہونا چاہیے۔

EIP-712 readable ہونے کے باوجود خطرناک کیسے ہو سکتا ہے؟

EIP-712 data کو domain، types اور fields میں دکھاتا ہے؛ صاف layout permission کو harmless نہیں کرتا۔ Marketplace order، governance، permit، smart-account action اور delegation میں یہ استعمال ہوتا ہے۔ Domain section اور message section دونوں پڑھیں۔

Domain fields

Name، version، chainId اور verifyingContract دیکھیں۔ Website testnet کہے مگر chainId mainnet کا ہو تو رکیں۔ Contract official documentation یا verified explorer record سے ملائیں۔ Name صرف text ہے اور copy ہو سکتا ہے؛ address اور chain context زیادہ وزن رکھتے ہیں۔

Message fields

Owner آپ کا address ہے؟ Spender یا operator کون ہے؟ Value کتنا ہے؟ Deadline اور nonce کیا ہیں؟ Large integer scientific notation میں ہو تو details کھولیں اور token decimals سمجھیں۔ Unknown spender کے لیے unlimited value اور چھوٹا test allowance ایک جیسے نہیں۔

Deadline اور replay

بہت دور یا open deadline signature کو بعد میں استعمال کے قابل رکھ سکتا ہے۔ Nonce عام طور پر replay روکتا ہے، مگر implementation contract پر منحصر ہے۔ User popup سے پورا code audit نہیں کر سکتا؛ اسی لیے official contract اور documented flow ضروری ہیں۔

Field کا نام “Login” ہو تو بھی type permit یا order ہو سکتا ہے۔ Wallet method اور verifying contract پڑھیں، social post کا خلاصہ نہیں۔ نامعلوم typed data reject کرنا موقع کھونا نہیں، بلکہ ناقابل وضاحت اختیار نہ دینا ہے۔

Approve، permit اور setApprovalForAll میں کیا فرق ہے؟

تینوں کسی دوسرے address کو asset پر اختیار دے سکتے ہیں، مگر asset کی حد اور chain پر جمع ہونے کا طریقہ مختلف ہے۔ ERC-20 approve spender کو allowance دیتا ہے۔ EIP-2612 permit signature کے ذریعے allowance بیان کرتا ہے جسے relayer submit کر سکتا ہے۔ NFT setApprovalForAll پورے collection کے لیے operator permission دے سکتا ہے۔

Approve میں تین field لازمی

Token contract، spender اور amount ملائیں۔ Approve on-chain transaction ہے، اس لیے gas دکھتا ہے۔ Unlimited allowance آئندہ gas بچا سکتا ہے مگر contract compromise، upgrade یا malicious spender کی صورت میں exposure بڑھاتا ہے۔ Testnet task اگر mainnet stablecoin کی اجازت مانگے تو عمل سے مطابقت نہیں رکھتا۔

Permit gas کے بغیر بھی حقیقی اختیار ہے

Permit کے وقت wallet “signature request” لکھ سکتا ہے۔ مگر owner، spender، value، deadline اور verifyingContract مل کر spending permission بنا سکتے ہیں۔ Attacker signature خود submit کر سکتا ہے۔ Disconnect permit کو cancel نہیں کرتا۔ مشکوک permit کے بعد دیکھیں آیا chain پر استعمال ہوا، token-specific revoke path معلوم کریں، اور قیمتی assets خطرے میں ہوں تو منتقل کریں۔

NFT operator پورے collection کو چھو سکتا ہے

setApprovalForAll صرف ایک NFT کی اجازت نہیں۔ “Ownership verify” یا “Mint pass” کے نام پر mainnet collection-wide approval آئے تو official reason تلاش کریں۔ Test badge کے لیے قیمتی NFT collection کا مکمل operator عام طور پر غیر متناسب مطالبہ ہے۔

Website بند، app delete یا session disconnect ہونے سے chain permission باقی رہتی ہے۔ Allowance خرچ ہو، user صفر کرے یا contract-specific condition بدلے تب حالت بدلتی ہے۔ High-permission interaction کے فوراً بعد اور project ختم کرتے وقت review کریں؛ مصنوعی مقررہ schedule کی ضرورت نہیں۔

Transaction popup میں کون سے fields ضرور پڑھیں؟

Network، From، To، value، token changes، contract method اور متوقع نتیجہ ملائیں۔ Website button “Claim”، “Mint” یا “Verify” ہو سکتا ہے مگر chain پر اصل کام data طے کرتا ہے۔ transferFrom، multicall یا unknown call کو صرف button کے نام سے محفوظ نہ سمجھیں۔

1. Chain ID expected testnet ہے؟ Mainnet gas symbol آئے تو cancel کریں۔
2. From address الگ test wallet ہے یا غلطی سے holding wallet؟
3. To address official contract یا expected recipient سے ملتا ہے؟
4. Native value صفر نہ ہو تو asset کیوں بھیجی جا رہی ہے؟
5. Token/NFT changes میں غیر متوقع outgoing item تو نہیں؟
6. Method اور parameters موجودہ task سے تعلق رکھتے ہیں؟
7. Simulation ہو تو result پڑھیں، مگر اسے ضمانت نہ سمجھیں۔

چھوٹا gas malicious transfer کو محفوظ نہیں بناتا۔ Gas execution fee ہے، security score نہیں۔ Failed simulation بھی اکیلا scam ثابت نہیں کرتا؛ RPC یا decoder issue ہو سکتا ہے۔ تضاد ہو تو confirm نہ کریں اور official technical support سے request details پر بات کریں۔

Upgradeable proxy کا logic بعد میں بدل سکتا ہے۔ Simulation موجودہ state اور دستیاب decoder دیکھتی ہے؛ delayed execution، reused signature یا future upgrade ہمیشہ نظر نہیں آتے۔ Limited permission اور verified source اس لیے اہم ہیں۔

Sign سے پہلے چھ مرحلوں کی معمول کی جانچ کیا ہو؟

Domain—network—request type—target—scope—exit path کی ترتیب رکھیں۔ Project کا follower count، influencer کی تعریف یا خوبصورت interface مستقل safety signal نہیں۔ ایک ہی checklist ہر page پر کام کرتی ہے۔

1. Domain: Website یا docs کے official راستے سے آئیں؛ spelling اور subdomain دیکھیں۔
2. Network: Chain ID اور selected account دیکھیں؛ test wallet الگ رکھیں۔
3. Type: Connect، message، typed data، allowance یا transaction طے کریں۔
4. Target: Contract، spender، operator، recipient اور token ملائیں۔
5. Scope: Amount، unlimited flag، NFT collection، deadline اور replay سمجھیں۔
6. Exit: Disconnect، revoke، cancel یا asset move کا راستہ جانیں۔

اہم field نہ سمجھ آئے تو details کھولیں۔ پھر بھی واضح نہ ہو تو cancel کریں۔ غیر یقینی airdrop کے لیے main wallet permission دینا کمزور risk-reward ہے۔ Legitimate project user کو پڑھنے کا وقت دیتا ہے؛ countdown اور private admin pressure خطرے کی نشانیاں ہیں۔

Mobile wallet truncated address دکھائے تو copy کر کے official address پورا ملائیں، مگر public chat میں paste نہ کریں۔ WalletConnect QR public screen یا screen-share پر نہ دکھائیں۔ Shared phone یا cyber cafe پر seed import نہ کریں۔

غلط signature یا approval ہو جائے تو پہلے کیا کریں؟

نئی requests روکیں، پھر signature کی قسم کے مطابق قدم اٹھائیں۔ Page بند اور disconnect کرنا future popup روکتا ہے؛ on-chain permission کے لیے revoke یا asset move درکار ہو سکتا ہے۔ قیمتی assets فوری risk میں ہوں تو نئی seed والے wallet میں منتقلی priority ہو سکتی ہے۔

• صرف connect: Connected site remove، session logout اور unusual requests پر نظر۔
• Login message: Service sessions revoke، linked account security review، official support کو domain دیں۔
• Permit: Explorer میں استعمال دیکھیں، token-specific revoke یا nonce path معلوم کریں، ضرورت ہو تو asset منتقل کریں۔
• Approve: درست chain پر spender allowance zero/revoke کریں اور history دیکھیں۔
• setApprovalForAll: متعلقہ collection کے operator کو revoke کریں؛ collections الگ الگ ہیں۔
• Asset transfer: Chain transaction عموماً واپس نہیں ہوتی۔ Hash محفوظ کریں، platform اور مناسب authority کو report کریں، recovery scam کو fee نہ دیں۔

Seed phrase “scan” کرنے کے لیے کسی website میں نہ ڈالیں۔ Remote-control access نہ دیں۔ Public hash، contract اور error سے جائز helper analysis کر سکتا ہے۔ گھبراہٹ میں دوسرا scam آسان ہوتا ہے، اس لیے تحریری checklist کے مطابق قدم اٹھائیں۔

تین مختصر مثالیں

Login message

Readable statement، browser سے ملتا domain، nonce اور issued time، کوئی asset field نہیں۔ Risk نسبتاً محدود ہے، مگر address کو social profile سے جوڑنے کی privacy cost باقی ہے۔ Holding wallet کے بجائے activity wallet بہتر ہو سکتا ہے۔

Testnet swap allowance

Chain واقعی testnet، token test asset، spender official router ہے۔ Approval expected ہو سکتا ہے، مگر unlimited لازمی ہے یا custom amount ممکن، دیکھیں۔ Task ختم ہونے پر allowance review کریں۔

Mainnet permit کو “verification” کہنا

Page reward کا دعویٰ کرے مگر typed data میں mainnet chainId، stablecoin contract اور unknown spender ہو۔ Gas نہ ہونا safety نہیں۔ Reject کریں، domain report کریں اور دیکھیں کوئی پچھلا signature تو نہیں دیا۔

عام سوالات

بنیادی تکنیکی ماخذ

• EIP-191: Signed Data Standard
• EIP-712: Typed Structured Data
• ERC-20: approve and allowance
• EIP-2612: permit
• Ethereum.org: Transactions
• MetaMask Wallet API: Sign data
• MetaMask Support: Protect yourself