بعد از گرفتن transaction hash چه کنیم: قدم بعدی برای Not found، Pending، Fail و گیرکردن در bridge

در ۳۰ ثانیه تشخیص دهید تراکنش در کدام لایه است

1. ابتدا network و block explorer درست را انتخاب کنید

یک address ممکن است روی چند chain وجود داشته باشد و با وجود format مشابه، balance و history مستقل است. نام network و Chain ID را از Wallet Activity یا project page بردارید و explorer عمومی همان network را باز کنید. پیدا شدن hash به‌تنهایی نشانهٔ معتبر بودن سایت نیست؛ explorer جعلی می‌تواند ظاهر را کپی کند و network اشتباه Not found می‌دهد.

1. Network و account نمایش‌داده‌شده هنگام submit را ثبت کنید.
2. از documentation شبکه/پروژه وارد explorer شوید، نه تبلیغ یا DM.
3. پس از paste، hostname، network badge، From و time را تطبیق دهید.
4. برای Not found، hash اصلی را دوباره از wallet کپی و کم‌شدن کاراکتر یا اشتباه‌گرفتن address را رد کنید.

در testnet، mainnet و testnet می‌توانند format آدرس مشابه داشته باشند ولی asset و transaction جداست. پیش از هر چیز network را بررسی کنید؛ برای «پیداشدن تراکنش» دارایی واقعی واریز نکنید.

2. فرق transaction hash، wallet address، block و contract

Hash در EVM معمولاً با 0x شروع می‌شود، اما prefix به‌تنهایی proof نیست. در Solana معمولاً transaction identifier را signature می‌نامند. Source، format و object type برگشتی explorer را با هم ببینید.

3. چرخهٔ Status: Not found، Pending، Success و Failed

Not found الزاماً failure نیست: network اشتباه، index delay، broadcast ناموفق RPC یا request ناقص wallet ممکن است علت باشد. Pending یعنی execution نهایی نشده و nonce قبلی می‌تواند tx بعدی را نگه دارد. Success یعنی execution انجام شده، اما فراخوانی اشتباه هم می‌تواند موفق باشد. Failed/Reverted یعنی tx وارد block شده و اجرای آن rollback شده است.

قدم بعدی بر اساس Status

5. Fieldهای صفحهٔ EVM transaction را چگونه بخوانیم

با ABI تأییدشده، explorer می‌تواند Method و parameters را decode کند. اگر فقط input خام می‌بینید، کورکورانه retry نکنید؛ expected method را در instruction برنامه پیدا کنید.

6. Receipt، Logs، Token Transfers و Internal Transactions

Transaction object می‌گوید چه چیزی درخواست شد؛ receipt نتیجهٔ execution را نشان می‌دهد. Status، Gas Used، contractAddress در deployment و logs شواهد پس از اجرا هستند.

• Logs/Events: رویداد ساختاریافتهٔ قرارداد؛ Transfer، Approval و NFT movement معمولاً از اینجا decode می‌شود.
• Token Transfers: نمای خوانای explorer از events؛ token contract را تطبیق دهید.
• Internal Transactions/Traces: call و value flow در execution؛ تراکنش external جداگانه‌ای نیست که wallet امضا کرده باشد.
• Balance change: برای نتیجهٔ کاربر مفید است ولی scope هر explorer فرق دارد؛ با raw event و wallet تطبیق دهید.

نبودن Transfer event به معنی نبودن تغییر نیست؛ internal accounting، position یا approval ممکن است تغییر کرده باشد. وجود transfer هم ارزش بازار token را ثابت نمی‌کند.

7. ترتیب کامل عیب‌یابی تراکنش Failed

1. Failed یا Pending؟ برای Pending ابتدا nonce و broadcast؛ این دو مشکل متفاوت‌اند.
2. Receipt و error دقیق: Block، To، Method، Gas Used و revert reason را نگه دارید.
3. Business precondition: Balance، approval، deadline، slippage، whitelist، claim limit و contract state را چک کنید.
4. Gas limit یا business revert: Out of gas ممکن است estimate درست بخواهد؛ شرط صریح قرارداد با افزایش کور Gas حل نمی‌شود.
5. پیش از retry شبیه‌سازی: با state/params یکسان ممکن است failure و هزینه تکرار شود.

اگر reason خالی است، Debug/Trace explorer (در صورت وجود) یا simulation فقط‌خواندنی برنامه را ببینید. Private key را به «پشتیبانی on-chain» ندهید و script ناشناس اجرا نکنید.

متن خطای کنار Fail: علت‌های رایج و راه‌حل

نام این خطاها از توضیح Etherscan دربارهٔ تراکنش‌های ناموفق و کد منبع قراردادهای OpenZeppelin ERC-20 و Uniswap router برداشته شده است (بررسی‌شده در سپتامبر 2026). پروژه‌های دیگر ممکن است عبارت خودشان را داشته باشند، اما روش شناختن علت همین است.

8. Confirmations و finality: چه وقت ادامه دهیم

Confirmations تعداد blockهای ساخته‌شده پس از block تراکنش است. Requirement شبکه، bridge، exchange و app متفاوت است؛ یک عدد ثابت برای همهٔ chainها ایمن نیست. Policy عمومی گیرنده و وضعیت live chain را ملاک قرار دهید.

با اولین Success evidence را حذف نکنید. App مقصد ممکن است دیرتر index کند؛ در testnet نیز Success روی chain و Completed در task دو state جداست.

9. در L2 و bridge یک hash کل مسیر را نشان نمی‌دهد

L2 explorer ممکن است L1 data fee، batch یا message status را جدا نشان دهد. Bridge می‌تواند source lock/burn، relay و destination mint/release داشته باشد. Success در source chain به معنی رسیدن asset در destination نیست.

• Source و destination chain را ثبت کنید.
• Source hash، message ID و destination hash را نگه دارید.
• Status bridge مانند waiting/challenge/claimable/completed را بخوانید.
• برای delay به صفحهٔ ناشناس «manual sync» متصل نشوید.

در زنجیرهٔ مبدأ Success، در مقصد نرسیده: کجا ببینیم و سراغ چه کسی برویم

1. به سایت رسمی همان پلی که استفاده کرده‌اید برگردید و صفحهٔ تاریخچهٔ تراکنش آن را باز کنید (معمولاً History، Transactions یا Activity)؛ همان کیف پول را وصل کنید یا با source hash وضعیت را ببینید.
2. اگر پل message explorer دارد، آنجا هم قابل بررسی است: برای پیام‌های LayerZero از LayerZero Scan (برای تست‌نت testnet.layerzeroscan.com) که وضعیت را Confirming، Inflight، Delivered، Failed، Blocked یا Payload Stored نشان می‌دهد، و برای Wormhole از Wormholescan. در حالت Delivered، hash مقصد را در explorer زنجیرهٔ مقصد ببینید؛ Confirming یا Inflight یعنی هنوز تأیید یا اجرا مانده؛ Payload Stored معمولاً باید از صفحهٔ پل یا برنامه retry شود.
3. برداشت از پل‌های رسمی native اغلب چندمرحله‌ای است: طبق مستندات Optimism، برداشت از OP Mainnet به Ethereum mainnet دورهٔ اعتراض 7 روزه دارد و در این میان باید خودتان تراکنش‌های دیگری هم بفرستید. اگر صفحهٔ پل از شما prove یا claim خواست، خودتان کلیک کنید؛ وگرنه دارایی نمی‌رسد.
4. اگر Failed یا Blocked دیدید یا زمان تخمینی صفحهٔ پل گذشت: از سایت رسمی پل (نه تبلیغ جست‌وجو یا لینک پیام خصوصی) به Help Center یا تیکت Discord بروید و نام زنجیرهٔ مبدأ و مقصد، source hash، message ID (در صورت وجود)، آدرس کیف پول، زمان و اسکرین‌شات را بدهید.
5. «پشتیبانی پل» که خودش پیام خصوصی می‌دهد، شما را به سایت «sync/repair» می‌فرستد یا عبارت بازیابی می‌خواهد، کلاهبردار است؛ پشتیبانی واقعی به کلید خصوصی شما نیاز ندارد. اگر فریب خورده‌اید، TxID، آدرس‌ها و گفت‌وگوها را نگه دارید و از مسیر رسمی پشتیبانی پل و کیف پول پیگیری کنید.

10. Solana: Signature، Slot، Instruction و Program Logs

Explorerهای Solana معمولاً signature، slot، block time، fee payer، account keys، instructions، program logs، compute units و token balance changes را نشان می‌دهند. مدل nonce/gas price/event در EVM را عیناً به Solana تعمیم ندهید.

1. Cluster یعنی mainnet، devnet یا محیط پروژه را مشخص کنید.
2. Signature status و slot و سپس fee payer را ببینید.
3. Instructions را باز و program و accounts را تطبیق دهید.
4. در failure اولین error مرتبط در Program Logs را پیدا کنید.
5. Pre/post token balances را با نتیجهٔ مورد انتظار مقایسه کنید.

11. آیا transaction hash را می‌توان share کرد؟ بله، با توجه به linkability

Hash رمز عبور نیست و chain عمومی قابل جست‌وجوست، اما address، زمان، balance change، contractها و history را به هم متصل می‌کند. برای support فقط hash، network و error ضروری را بدهید و screenshot را ماسک کنید.

• Seed phrase، private key، OTP، session cookie یا wallet export هرگز ارسال نشود.
• Email، social account، extensions، notification و tabهای دیگر ماسک شوند.
• برای جلوگیری از اتصال walletها، همهٔ addressها را در یک تصویر/جدول نگذارید.
• برای DM مدعی support، از مسیر رسمی سایت دوباره تماس را شروع کنید.

12. از Wallet تا نتیجه: workflow کامل

1. Hash اصلی، network و time را از Wallet Activity بگیرید.
2. Explorer درست را از documentation باز کنید.
3. Status را خوانده و شاخهٔ Not found/Pending/Success/Failed را انتخاب کنید.
4. From، To، Method/Instruction و Value را تطبیق دهید.
5. Receipt، Logs، Token Transfers، Internal calls یا Program Logs را ببینید.
6. Wallet balance و app page را مقایسه و chain/app sync را جدا کنید.
7. Evidence حداقلی و conclusion را ثبت کنید؛ بدون علت روشن دوباره sign نکنید.

نتیجه را در testnet task record بنویسید. برای fee از راهنمای Gwei/Gas و برای approval از راهنمای Revoke استفاده کنید.

13. سه سناریوی رایج

A: Wallet می‌گوید Sent، explorer می‌گوید Not found

Network و source hash را تطبیق دهید. در network درست کمی صبر و Wallet Activity را refresh کنید؛ بدون chain hash، RPC/error evidence را ببینید و مبلغ دیگری فوری نفرستید.

B: Status موفق است اما token دیده نمی‌شود

Token contract، target address و network را چک کنید. Add نشدن token به wallet، display delay، مرحلهٔ بعدی bridge یا token جعلی هم‌نام ممکن است علت باشد.

C: Failed و Gas کم شده

Tx وارد block شده و rollback کرده؛ computation انجام شده و fee ممکن است مصرف شود. Revert reason و precondition را اصلاح و دوباره simulate کنید. Cancel، Gas خرج‌شده را برنمی‌گرداند.

14. چک‌لیست بررسی

• Network/Chain ID یا Solana cluster مشخص است.
• Hash از Wallet Activity خودتان است.
• Status و confirmations خوانده شده.
• From، To، Method/Instruction و Value تطبیق داده شده.
• Receipt، Logs/Transfers یا Program Logs دیده شده.
• Token contract/mint و destination تأیید شده.
• Chain state و app state جدا ثبت شده.
• Screenshot ماسک و بدون secret است.
• بدون علت روشن retry نمی‌شود.

پرسش‌های رایج

منابع

آخرین بررسی: 2026-09-28. در این نسخه قدم بعدی بر اساس وضعیت، جدول خطاهای رایج و اینکه هنگام گیرکردن در bridge کجا ببینید و سراغ چه کسی بروید اضافه شد؛ پیام‌های explorer و نام وضعیت‌های پل در سپتامبر 2026 بررسی شد.

• Ethereum Transactions
• EIP-658
• EIP-2718
• Solana Transactions
• Solana getTransaction
• Etherscan: Reason for Failed Transaction
• Blockscan: multichain search
• LayerZero Scan
• Optimism Docs: Standard Bridge