هر popup کیف پول یک «امضا» نیست؛ اول نوع اختیار را تشخیص دهید
روی وبسایت شاید فقط «Continue» یا «Verify» ببینید، اما کیف پول ممکن است login message، allowance توکن، اختیار operator برای NFT یا انتقال مستقیم دارایی بخواهد. تصمیم را بر اساس network، method، contract، spender، amount و message در خود popup بگیرید، نه رنگ button یا محبوبیت پروژه.
نوع wallet request را چطور سریع تشخیص دهیم؟
وجود gas، readable message، spender، asset change یا contract call را بررسی کنید. اتصال ساده آدرس معمولاً gas ندارد. Message signature خودش وارد block نمیشود. Approve و transfer روی chain هستند. Permit شاید هنگام امضا gas نداشته باشد، اما شخص دیگری میتواند آن را submit و allowance را فعال کند.
| Request | نمایش معمول | روی chain؟ | خطر اصلی |
|---|---|---|---|
| Connect | Account/address access | خیر | ارتباط address و profile سایت |
| personal_sign | Text یا hex message | خود signature خیر | Login یا off-chain consent |
| EIP-712 | Domain و structured fields | خود signature خیر | Order، permit یا delegation |
| approve | Allow spender | بله | مصرف token تا سقف allowance |
| permit | Owner، spender، value، deadline | بعداً قابل submit | Allowance از طریق signature |
| Transaction | To، value، gas، data | بله | انتقال asset یا تغییر state |
واژههای کیف پولها متفاوتاند. بخش Details، Data، Permission یا Advanced را باز کنید. اگر field مهم نمایش داده نمیشود، جمله «safe» در همان سایت دلیل مستقل نیست. رد کردن request دارایی معتبر را حذف نمیکند؛ flow رسمی را دوباره میتوان شروع کرد.
Connect Wallet چه اطلاعاتی به وبسایت میدهد؟
Connect معمولاً public address انتخابشده، active chain و قابلیتهای کیف پول را در اختیار سایت میگذارد؛ spending approval نیست. با این حال privacy cost دارد. تاریخچه آدرس عمومی است و سایت میتواند آن را به browser session، social login یا campaign profile مرتبط کند.
کیف پول جداگانه برای testnet، exposure آدرس نگهداری اصلی را کم میکند. تفاوت account دیگر روی همان seed با walletی دارای seed کاملاً تازه را بفهمید. رابطه accountهای یک seed همیشه مستقیم روی chain مشخص نیست، اما transfer و الگوی استفاده میتواند آنها را مرتبط کند. High-value wallet را به task page ناشناس وصل نکنید.
هر popup بعد از connect یک request تازه است. الگوی phishing میتواند با اتصال بیخطر شروع شود و سپس approve یا permit نمایش دهد، وقتی کاربر به confirm عادت کرده است. کمخطر بودن popup اول، دومی را امن نمیکند. درخواستهای متوالی را cancel و مراحل مورد انتظار را در docs بخوانید.
Disconnect در Connected sites فقط session front end را تمام میکند، نه on-chain approval را. پاک کردن history، lock کردن wallet یا reinstall extension نیز allowance را حذف نمیکند. Privacy connection و blockchain permission دو record جدا هستند.
personal_sign برای login چه زمانی ریسک کمتری دارد؟
Message قابلخواندن با domain درست، هدف روشن و nonce معمولاً برای login محدود استفاده میشود، اما نباید blind sign شود. EIP-191 برای جدا کردن signed data از transaction معمولی prefix تعریف میکند؛ درباره صداقت هدف message تضمین نمیدهد.
Login message مناسب چه چیزهایی دارد؟
Service domain، wallet address، statement ورود، random nonce، issued time و در صورت نیاز expiry باید دیده شوند. Domain مرورگر و message را تطبیق دهید. «Sign in to example.org» قابل فهم است؛ domain متفاوت، terms باز یا عبارت نامرتبط با asset دلیل رد است.
Zero gas یعنی zero risk نیست
Message بهصورت local امضا میشود و gas ندارد. Service میتواند از signature برای اثبات پذیرش یک statement استفاده کند. سایت بدخواه شاید آن را login token، marketplace order یا authorization دیگری بهکار ببرد. Gas فقط fee را توضیح میدهد، نه ارزش permission را.
با hex message چه کنیم؟
اگر payload قابل خواندن نیست، امضا نکنید و method دقیق را در docs پروژه پیدا کنید. اگر hardware wallet اطلاعات کمی نشان میدهد، full data را در interface دسکتاپ کیف پول ببینید. «فقط برای verification» که خود سایت نوشته، توضیح مستقل نیست چون همان سایت request را ساخته است.
برای login signature نباید seed phrase، password یا OTP را در form وارد کنید. Wallet خودش signature را میسازد. صفحهای که secret جداگانه میخواهد باید بسته شود.
چرا EIP-712 خوانا هنوز میتواند خطرناک باشد؟
EIP-712 داده را به domain، type و field تقسیم میکند تا wallet آن را بهتر نشان دهد؛ خوانایی permission را بیخطر نمیکند. Marketplace order، governance vote، permit، smart-account action و delegation از آن استفاده میکنند. هر دو بخش domain و message را بخوانید.
Domain fields
Name، version، chainId و verifyingContract را ببینید. اگر صفحه testnet میگوید ولی chainId mainnet است، توقف کنید. Contract را با official docs یا verified explorer تطبیق دهید. Name فقط text و قابل copy است؛ address و chain context اهمیت بیشتری دارند.
Message fields
Owner آدرس شماست؟ Spender یا operator چه کسی است؟ Value چقدر است؟ Deadline و nonce چیست؟ اگر عدد بزرگ با scientific notation نشان داده میشود، details را باز و token decimals را درک کنید. Allowance کوچک test با unlimited value برای unknown spender یکسان نیست.
Deadline و replay
Deadline باز یا بسیار دور اجازه استفاده دیرهنگام میدهد. Nonce معمولاً replay را متوقف میکند، ولی به implementation وابسته است. کاربر از روی popup نمیتواند همه code را audit کند؛ به همین دلیل official contract و documented flow لازماند.
حتی اگر نام field «Login» باشد، type ممکن است permit یا order باشد. Method کیف پول و verifying contract را بخوانید، نه caption شبکه اجتماعی را.
Approve، permit و setApprovalForAll چه تفاوتی دارند؟
هر سه میتوانند به آدرس دیگری اختیار بدهند، اما نوع asset، محدوده و روش submit فرق میکند. ERC-20 approve به spender allowance میدهد. EIP-2612 permit همان مفهوم را با signature بیان میکند که relayer میتواند submit کند. NFT setApprovalForAll ممکن است کل collection را پوشش دهد.
سه field اصلی approve
Token contract، spender و amount را تطبیق دهید. Approve transaction on-chain و دارای gas است. Unlimited allowance interaction بعدی را ساده میکند اما exposure در زمان compromise یا upgrade contract را بیشتر میکند. درخواست mainnet stablecoin در task آزمایشی با هدف سازگار نیست.
Permit بدون gas هم permission واقعی است
کیف پول شاید فقط «signature request» بنویسد، اما owner، spender، value، deadline و verifyingContract میتوانند spending allowance بسازند. مهاجم signature را خودش submit میکند. Disconnect آن را cancel نمیکند. پس از permit مشکوک، استفاده on-chain را بررسی، راه revoke مخصوص token را پیدا و در صورت خطر دارایی مهم را منتقل کنید.
NFT operator ممکن است کل collection را بگیرد
setApprovalForAll تنها یک NFT را پوشش نمیدهد. اگر صفحه برای «verify ownership» یا «mint pass» اختیار کامل collection mainnet میخواهد، دلیل رسمی را پیدا کنید. چنین محدودهای برای test badge معمولاً متناسب نیست.
Approval با بسته شدن سایت، حذف app یا disconnect session باقی میماند. مصرف کامل allowance، صفر کردن، revoke operator یا rule خاص contract وضعیت را عوض میکند. بعد از high-permission action و هنگام خروج از project review کنید.
کدام fieldهای transaction popup را نباید رد کرد؟
Network، From، To، value، token changes، contract method و نتیجه مورد انتظار را تطبیق دهید. Button ممکن است Claim، Mint یا Verify باشد، ولی data عمل on-chain را تعیین میکند. transferFrom، multicall یا unknown method فقط بهخاطر label خوب امن نیست.
- Chain ID همان testnet مورد انتظار است؟ اگر mainnet gas symbol آمد cancel کنید.
- From address همان test wallet است، نه holding wallet؟
- To address با official contract یا recipient هماهنگ است؟
- اگر native value صفر نیست، علت ارسال asset را میفهمید؟
- در token/NFT changes خروجی نامنتظره دیده میشود؟
- Method و parameters به task فعلی مربوطاند؟
- Simulation را بخوانید، ولی guarantee فرض نکنید.
Gas کم، transaction بدخواه را امن نمیکند. Gas هزینه اجراست نه امتیاز امنیت. Failed simulation نیز بهتنهایی scam را ثابت نمیکند؛ RPC یا decoder ممکن است مشکل داشته باشد. در تعارض page و wallet، confirm نکنید و از support فنی رسمی بپرسید.
Logic یک upgradeable proxy ممکن است بعداً تغییر کند. Simulation state فعلی و decoder موجود را میبیند؛ delayed execution، reused signature یا upgrade بعدی شاید دیده نشود. Limited permission و verified source همچنان مهماند.
پیش از هر امضا چه بررسی ششمرحلهای داشته باشیم؟
Domain—network—request type—target—scope—exit path را همیشه با همین ترتیب طی کنید. این روال از follower count، endorsement یا interface زیبا قابل اعتمادتر است.
- Domain: از official website یا docs وارد شوید؛ spelling و subdomain را ببینید.
- Network: Chain ID و selected account را بررسی و test wallet را جدا کنید.
- Type: Connect، message، typed data، allowance یا transaction؟
- Target: Contract، spender، operator، recipient و token را تطبیق دهید.
- Scope: Amount، unlimited flag، NFT collection، deadline و replay را بفهمید.
- Exit: راه disconnect، revoke، cancel یا انتقال asset را بدانید.
اگر field مهم روشن نیست، details را باز کنید. اگر هنوز توضیحپذیر نیست، cancel کنید. دادن permission کیف پول اصلی برای airdrop نامطمئن risk-reward ضعیفی دارد. پروژه معتبر زمان مطالعه میدهد؛ countdown و فشار ادمین خصوصی هشدارند.
در موبایل address کوتاهشده است. آن را copy و با آدرس official کامل مقایسه کنید، اما در chat عمومی paste نکنید. WalletConnect QR را در screen share نشان ندهید. Seed را در device مشترک import نکنید.
پس از signature یا approval اشتباه اول چه کنیم؟
درخواستهای تازه را متوقف و بعد بر اساس نوع امضا اقدام کنید. بستن page و disconnect، popup بعدی را میبندد؛ on-chain permission ممکن است revoke یا انتقال asset بخواهد. اگر دارایی مهم در خطر است، انتقال به wallet با seed تازه میتواند اولویت داشته باشد.
- فقط Connect: Connected site را حذف، session را logout و request غیرعادی را بررسی کنید.
- Login message: Sessionها را revoke، امنیت account متصل را بررسی و domain را به support رسمی بدهید.
- Permit: در explorer ببینید استفاده شده، revoke یا nonce path مخصوص token را پیدا و در صورت نیاز asset را منتقل کنید.
- Approve: در chain درست allowance spender را صفر یا revoke و history را بررسی کنید.
- setApprovalForAll: Operator را در collection مربوطه revoke کنید؛ هر collection جداست.
- Asset transfer: Transaction بلاکچین معمولاً برنمیگردد. Hash را نگه دارید، به platform و مرجع مناسب گزارش کنید و به recovery scam fee ندهید.
Seed phrase را در «scanner» وارد نکنید و remote-control access ندهید. Helper معتبر با public hash، contract و error تحلیل میکند. در زمان نگرانی، scam دوم آسانتر است؛ طبق checklist مکتوب پیش بروید.
سه سناریوی کوتاه
Login message
Statement خوانا، domain هماهنگ، nonce و issued time و بدون asset field. ریسک محدودتر است اما privacy cost اتصال address به profile باقی میماند. Activity wallet از holding wallet مناسبتر است.
Testnet swap approval
Chain واقعاً testnet، token آزمایشی و spender همان router رسمی است. Approval میتواند طبیعی باشد، ولی امکان custom amount در برابر unlimited را ببینید و بعد از task review کنید.
Mainnet permit با عنوان verification
Page از reward حرف میزند اما typed data شامل mainnet chainId، stablecoin و unknown spender است. نبود gas نشانه امنیت نیست. Reject، report و history امضاهای قبلی را بررسی کنید.
پرسشهای رایج
آیا صرفاً connect کردن کیف پول میتواند دارایی را منتقل کند؟
Connect معمولاً فقط آدرس عمومی انتخابشده و شبکه را به وبسایت نشان میدهد و خودش transfer نیست. با این حال صفحه میتواند بعداً message signature، approval یا transaction جداگانه بخواهد؛ هر popup را دوباره بخوانید.
آیا personal_sign همیشه امن است؟
خیر. Login message روشن معمولاً فوراً دارایی را جابهجا نمیکند، اما signature میتواند برای ورود یا authorization خارج از chain استفاده شود. اگر domain، هدف، nonce یا expiry نامشخص است، رد کنید.
خطر مشترک approve و permit چیست؟
هر دو میتوانند به spender اجازه استفاده از token بدهند. Approve یک transaction روی chain است؛ permit را ممکن است فرد دیگری بعداً submit کند. Token، spender، مقدار، chain و deadline را بررسی کنید.
اگر wallet simulation وضعیت امن نشان دهد میتوان confirm کرد؟
Simulation کمک میکند اما تضمین نیست. Upgradeable contract، ارسال با تأخیر، decoding ناقص یا call بعدی ممکن است دیده نشود. Domain، contract و permission را مستقل بررسی کنید.