Crypto ကို Network မှားပို့မိပါသလား? ဘယ် Transfer တွေကို တကယ်ပြန်လည်ရယူနိုင်သလဲ?

Network မှားပို့မိသော crypto ကို တချို့အခြေအနေများတွင် ပြန်လည်ရယူနိုင်ပါတယ်။ သင့်ရဲ့ ရွေးချယ်စရာတွေက လက်ခံမယ့် address ကို ဘယ်သူက ထိန်းချုပ်ထားသလဲ၊ အဲဒီ network ပေါ်မှာ အဲဒီ address ကို သုံးနိုင်သလား၊ ဘယ် token ရောက်သွားသလဲဆိုတာပေါ် မူတည်ပါတယ်။

Transaction အောင်မြင်တယ်ဆိုတာ blockchain က အဲဒီ transaction ကို process လုပ်ပြီးပြီလို့သာ ဆိုလိုပါတယ်။ Exchange က သင့် account ထဲ credit ထည့်ပြီးပြီလို့ မသက်သေပြသလို၊ လက်ခံသူက အဲဒီငွေကို သုံးနိုင်ပြီလို့လည်း မသက်သေပြပါဘူး။ Recovery လုပ်ဖို့ ပထမဆုံးလုပ်ရမယ့်အရာက တကယ်ဖြစ်ခဲ့တဲ့ token transfer ကိုရှာပြီး အဲဒီ token တွေကို ဘယ်သူက လွှဲပြောင်းနိုင်သလဲဆိုတာ သိအောင်လုပ်တာပါ။

သင့် recovery လမ်းကြောင်းကို ရှာပါ

• ကိုယ့် wallet ကိုယ်: ကိုယ်ထိန်းချုပ်တဲ့ သာမန် account တစ်ခုဆီကို compatible network ပေါ်မှာ ငွေတွေ ရောက်သွားရင် အများအားဖြင့် ပြန်ရနိုင်ပါတယ်။ Smart wallet ဆိုရင် သီးခြားစစ်ဆေးဖို့ လိုပါတယ်။
• Exchange တစ်ခု: Recovery ဖြစ်နိုင်မဖြစ်နိုင်ဆိုတာ လက်ခံတဲ့ exchange ရဲ့ tools, custody system နဲ့ အဲဒီ token နဲ့ network အတိအကျအတွက် သတ်မှတ်ထားတဲ့ policy ပေါ် မူတည်ပါတယ်။ Deposit address ကို exchange ကိုယ်တိုင်ပဲ ကိုင်တွယ်နိုင်ပါတယ်။
• အခြားလူတစ်ယောက်: အဲဒီလူက ငွေပြန်ပို့နိုင်ရမယ်၊ ပြန်ပို့ဖို့လည်း သဘောတူရမယ်။ သူပေးထားတာ exchange deposit address ဆိုရင် အဲဒီ exchange ကို သူကိုယ်တိုင် ဆက်သွယ်ရပါမယ်။
• Smart contract တစ်ခု: Recovery ဖြစ်နိုင်မဖြစ်နိုင်ဆိုတာ contract ရဲ့ code နဲ့ authorized operator တွေပေါ် မူတည်ပါတယ်။ Contract တချို့က token ပြန်ထုတ်ပေးနိုင်ပေမယ့် တချို့က မရနိုင်ပါဘူး။

အရေးအကြီးဆုံးမေးခွန်းက ဒီတစ်ခုပါ: တကယ်သုံးခဲ့တဲ့ network ပေါ်မှာ လက်ခံ address ကနေ transfer တစ်ခုကို ဘယ်သူက authorize လုပ်နိုင်သလဲ? Address တစ်ခုမှာ balance ပြနေတယ်ဆိုတာတင် မလုံလောက်ပါဘူး။

Recovery မစခင် transaction ကို အရင်စစ်ပါ

1. Transfer တကယ်ဖြစ်သွားပြီလား စစ်ပါ

Withdrawal သို့မဟုတ် sending record ကိုဖွင့်ပြီး blockchain transaction ID ကို copy လုပ်ပါ။ အဲဒါကို TxID သို့မဟုတ် transaction hash လို့လည်း ခေါ်ပါတယ်။ Exchange ရဲ့ internal withdrawal ID က ဒီ ID နဲ့ မတူနိုင်ပါဘူး။

• Blockchain transaction မရှိသေး: Withdrawal က sending platform အတွင်းမှာပဲ ရှိနေနိုင်ပါတယ်။ Cancel လုပ်လို့ရသေးလား စစ်ပြီး platform ကို ချက်ချင်းဆက်သွယ်ပါ။
• Blockchain ပေါ်မှာ pending: Wallet တချို့မှာ unconfirmed transaction ကို replace သို့မဟုတ် cancel လုပ်ဖို့ ကြိုးစားနိုင်ပါတယ်။ Wallet ရဲ့ official instructions ကို လိုက်နာပါ။ အောင်မြင်မယ်လို့ အာမခံမရှိပါဘူး၊ မှားပို့ထားတဲ့ transfer ကို speed up လုပ်မိရင် ပြဿနာပိုဆိုးသွားနိုင်ပါတယ်။
• Failed သို့မဟုတ် reverted: ဘာကြောင့် fail ဖြစ်သွားလဲနဲ့ sender ရဲ့ balance ကို စစ်ပါ။ ဒါက wrong network ပေါ်ကို successful deposit ဖြစ်သွားတာနဲ့ မတူပါဘူး။ Ethereum ပုံစံ transaction တစ်ခု fail ဖြစ်သွားတောင် network fee က ကုန်နိုင်ပါတယ်။
• Successfully confirmed: ပုံမှန် cancel သို့မဟုတ် chargeback button မရှိပါဘူး။ Recovery ဆိုတာ များသောအားဖြင့် ငွေတွေ ရောက်သွားတဲ့နေရာကနေ transfer အသစ်တစ်ခု ပြန်လုပ်ရတာပါ။

2. သင်တကယ်ရွေးခဲ့တဲ့ network ရဲ့ explorer ကို သုံးပါ

မူလ withdrawal record ထဲမှာ network ကို စစ်ပြီး အဲဒီ network ရဲ့ blockchain explorer ကို ဖွင့်ပါ။ ဥပမာ Ethereum transaction တွေကို Etherscan မှာ၊ BNB Smart Chain transaction တွေကို BscScan မှာ၊ TRON transaction တွေကို TRONSCAN မှာ တွေ့နိုင်ပါတယ်။

Ethereum explorer မှာ transaction မတွေ့တာက BNB Smart Chain ပေါ်မှာ အဲဒီ transaction ဖြစ်ခဲ့တာသာ ဖြစ်နိုင်ပါတယ်။ ကိုယ်ရည်ရွယ်ထားတဲ့ network ပေါ်မှာပဲ ရှာတာနဲ့ ငွေတွေ ပျောက်သွားတယ်လို့ မဆိုနိုင်ပါဘူး။

Bridge သုံးခဲ့ရင် bridge transfer status ကိုလည်း စစ်ပါ။ စတင်တဲ့ network ပေါ်က completed transaction က transfer တစ်ခုလုံးရဲ့ အစိတ်အပိုင်းတစ်ခုပဲ ဖြစ်နိုင်ပါတယ်။ Destination transaction သို့မဟုတ် bridge က တောင်းဆိုတဲ့ claim/refund step တစ်ခုခု ရှိမရှိ စစ်ပါ။

3. Token တကယ်ရောက်သွားတဲ့ recipient ကို ရှာပါ

USDT နဲ့ Ethereum ပုံစံ token တွေအတွက် transaction ရဲ့ token transfers section ကို ဖွင့်ပါ။ အဲဒီမှာ recipient, amount နဲ့ token contract ကို စစ်ပါ။

Transaction ရဲ့ အဓိက To field မှာ token ကို run လုပ်တဲ့ contract ပြနေနိုင်ပါတယ်။ ဒါဟာ ပုံမှန်ပါပဲ။ Token transfer တစ်ခုက အဲဒီ contract ကို call လုပ်ပြီး ဘယ် address က token ရရမလဲဆိုတာ ပြောတာပါ။ ဒီအချက်တစ်ခုတည်းကြောင့် token contract ဆီကို ငွေမှားပို့လိုက်တယ်လို့ မဆိုနိုင်ပါဘူး။

Transaction က ဘာလုပ်ခဲ့လဲဆိုတာလည်း စစ်ပါ။ Successful token approval ဆိုတာ token သုံးဖို့ permission ပေးတာဖြစ်ပြီး payment ကိုယ်တိုင် မဟုတ်ပါဘူး။ Contract call အများကြီးပါဝင်တဲ့ transaction တစ်ခုမှာ transfer အများကြီး ပါနိုင်ပါတယ်။

4. Token နဲ့ လက်ရှိတည်နေရာကို အတည်ပြုပါ

Receiving address အပြည့်အစုံ၊ တကယ်သုံးခဲ့တဲ့ network၊ amount နဲ့ token contract ကို မှတ်ထားပါ။ အဲဒီ contract ကို token issuer သို့မဟုတ် receiving platform ရဲ့ အဲဒီ network အတွက် official information နဲ့ တိုက်စစ်ပါ။ Token name သို့မဟုတ် logo ကို ကူးယူတုပနိုင်ပါတယ်။

ပြီးရင် receiving address ရဲ့ token balance နဲ့ နောက်ပိုင်း transfer တွေကို စစ်ပါ။ Original transaction က token ဘယ်နေရာရောက်ခဲ့လဲဆိုတာ သက်သေပြပေမယ့် အဲဒီနောက်ပိုင်း token တွေ ပြောင်းရွှေ့ပြီးသား ဖြစ်နိုင်ပါတယ်။

Exchange က အဲဒီ token တွေကို wallet တစ်ခုကနေ တခြား wallet တစ်ခုဆီ ရွှေ့ထားရင် ပုံမှန် internal handling ဖြစ်နိုင်ပါတယ်။ သင့် account ထဲ credit ဝင်ပြီးပြီလို့ မသက်သေပြပါဘူး။ ကိုယ့် wallet ထဲက မမျှော်လင့်ထားတဲ့ transfer တစ်ခု ထွက်သွားရင် ငွေထပ်မဖြည့်ခင် compromise ဖြစ်နိုင်မဖြစ်နိုင် စစ်ပါ။

ဒီစစ်ဆေးမှုတွေက public information ကိုပဲ သုံးပါတယ်။ Address တစ်ခုကို စစ်ဖို့ wallet ကို connect လုပ်စရာ မလိုသလို recovery phrase ကိုလည်း မပြောရပါဘူး။

Wrong network, unsupported token နဲ့ wrong address က မတူတဲ့ပြဿနာတွေပါ

မှားနေတဲ့ သို့မဟုတ် မပံ့ပိုးတဲ့ network

သင် USDT ကို Ethereum ပေါ် ပို့ချင်ပေမယ့် BNB Smart Chain ကိုရွေးလိုက်တယ်ဆိုပါစို့။ Transfer က BNB Smart Chain ပေါ်က address တစ်ခုဆီ ရောက်သွားပြီး receiving service က အဲဒီ chain ကို မပံ့ပိုးနိုင်ပါတယ်။

Withdrawal screen တွေမှာ Ethereum (ERC20) က များသောအားဖြင့် Ethereum mainnet ကို ဆိုလိုပြီး BNB Smart Chain (BEP20) က BNB Smart Chain ကို ဆိုလိုပါတယ်။ ERC20 နဲ့ BEP20 က token standard တွေကို ဖော်ပြတာပါ။ Standard တစ်ခုတည်းကို destination လို့ မယူဆဘဲ network name အပြည့်အစုံကို စစ်ပါ။

0x နဲ့စတဲ့ address တစ်ခုက ဘယ် network သုံးရမလဲဆိုတာ မပြောပါဘူး။ Network အများကြီးက ဒီ format ကိုသုံးပြီး balance တွေကို သီးခြားထားပါတယ်။

မှန်တဲ့ network ပေါ်က unsupported token

Network နဲ့ address မှန်နိုင်ပေမယ့် receiving platform က သင်ပို့လိုက်တဲ့ token contract အတိအကျကို လက်မခံနိုင်ပါတယ်။

ဥပမာ native USDC နဲ့ bridged USDC version တစ်ခုက network တစ်ခုတည်းပေါ်မှာ ရှိနိုင်ပါတယ်။ Arbitrum ပေါ်က bridged USDC ကို Circle Mint မပံ့ပိုးကြောင်း Circle က သတိပေးထားပြီး မှားပို့တဲ့ deposit တွေကို ပြန်မရနိုင်တာလည်း ဖြစ်နိုင်ပါတယ်။ Arbitrum ပေါ်မှာ USDC လက်ခံတယ်ဆိုတာ အဲဒီ network ပေါ်က USDC လို့ခေါ်သမျှ token အားလုံးကို လက်ခံတယ်လို့ မဆိုလိုပါဘူး။

USDT မှာလည်း bridge သို့မဟုတ် အခြား service တွေက ကိုယ်စားပြုထားတဲ့ version တွေ ရှိပါတယ်။ USDT လို့ နာမည်ပါတဲ့ token တိုင်း Tether က တိုက်ရိုက်ထုတ်ထားတယ် သို့မဟုတ် recovery route တူတယ်လို့ မယူဆပါနဲ့။

Receiving address မှားခြင်း

သင်ရည်ရွယ်ထားတဲ့ address မဟုတ်ဘဲ တခြား address တစ်ခုဆီ ပို့လိုက်တာ ဖြစ်နိုင်ပါတယ်။ ဥပမာ အရင် copy လုပ်ထားတဲ့ address ဟောင်း၊ မသိတဲ့သူတစ်ယောက်ရဲ့ wallet သို့မဟုတ် token contract တစ်ခု ဖြစ်နိုင်ပါတယ်။

Network ပြောင်းတာနဲ့ အဲဒီ address ကို ထိန်းချုပ်ခွင့် မရနိုင်ပါဘူး။ Recovery က တကယ့် recipient သို့မဟုတ် သက်ဆိုင်တဲ့ contract/issuer recovery process ရှိမရှိပေါ် မူတည်ပါတယ်။

Memo သို့မဟုတ် tag မပါခြင်းက သီးခြားအမျိုးအစားပါ။ ငွေက မှန်တဲ့ shared exchange address ဆီ ရောက်သွားပေမယ့် သင့် account ကို ခွဲခြားသတ်မှတ်ဖို့ လိုအပ်တဲ့အချက်အလက် မပါသွားတာ ဖြစ်နိုင်ပါတယ်။ အဲဒီ exchange ရဲ့ memo/tag recovery process ကို သုံးပါ။

Address, token, network နဲ့ လိုအပ်တဲ့ memo အားလုံး မှန်တယ်ဆိုရင် confirmation requirement, deposit minimum နဲ့ receiving platform ရဲ့ deposit status ကို စစ်ပါ။ Wrong-network transfer မဟုတ်ဘဲ crediting delay ဖြစ်နိုင်ပါတယ်။

1. ငွေတွေ ကိုယ့် wallet ဆီ ရောက်သွားတယ်

သာမန် wallet account တစ်ခုနဲ့ ဘယ်အချိန်မှာ ပြန်ရနိုင်သလဲ

Network အများကြီးက Ethereum ပုံစံ account တွေကို သုံးပါတယ်။ ဒီ network တွေကို များသောအားဖြင့် EVM-compatible networks လို့ ခေါ်ပါတယ်။ Private key တစ်ခုနဲ့ တိုက်ရိုက်ထိန်းချုပ်ထားတဲ့ သာမန် account တစ်ခုအတွက် အဲဒီ key တစ်ခုတည်းက network တွေတစ်လျှောက် same address ကို ပုံမှန်အားဖြင့် ထိန်းချုပ်ပါတယ်။

ဒါကြောင့် ကိုယ့် Ethereum-style address ကို BNB Smart Chain ပေါ်မှားပို့မိရင် wallet မှာ အစပိုင်း ဘာမှမပြသေးတောင် access ရနိုင်ပါတယ်။ Token balance က BNB Smart Chain ပေါ်မှာ ရှိနေတာဖြစ်ပြီး app က Ethereum ကိုပဲ ပြနေတာ ဖြစ်နိုင်ပါတယ်။

ဒီအချက်က သင်တကယ်ထိန်းချုပ်ထားတဲ့ account အတိအကျ အတွက်ပဲ ဖြစ်ပါတယ်။ Smart wallet, exchange address သို့မဟုတ် same recovery phrase ကနေ ထွက်လာတဲ့ အခြား address တစ်ခုအတွက် အလိုအလျောက် မသက်ဆိုင်ပါဘူး။

လုံခြုံစွာ စစ်ဆေးနည်း

1. Receiving account ကို ထိန်းချုပ်တဲ့ wallet ကို ဖွင့်ပါ။ Wallet address အပြည့်အစုံကို transaction ထဲက တကယ့် token recipient နဲ့ တိုက်စစ်ပါ။
2. Transfer အတွက် သုံးခဲ့တဲ့ network ကို ရွေးပါ။ မရှိသေးရင် wallet maker ရဲ့ instructions အတိုင်း enable လုပ်ပါ သို့မဟုတ် official network settings ကို ထည့်ပါ။
3. Token အတိအကျကို ပြပါ။ အလိုအလျောက် မပေါ်ရင် အဲဒီ network အတွက် verified contract address ကိုသုံးပြီး wallet ရဲ့ add-token function နဲ့ ထည့်ပါ။
4. Account က sign လုပ်နိုင်မနိုင် စစ်ပါ။ Watch-only wallet က ဘယ်သူ့ balance မဆို ပြနိုင်ပါတယ်။ Return transfer ကို authorize မလုပ်နိုင်ပါဘူး။
5. မပို့ခင် destination ကို စီစဉ်ပါ။ နောက်တစ်ဆင့် wallet သို့မဟုတ် exchange က သင်လက်ရှိကိုင်ထားတဲ့ network ပေါ်က ဒီ token အတိအကျကို လက်ခံကြောင်း အတည်ပြုပါ။
6. Network fee ကို ပြင်ဆင်ပါ။ BNB Smart Chain ပေါ်မှာ သာမန် BEP20 transfer လုပ်ဖို့ ပုံမှန်အားဖြင့် အဲဒီ chain ပေါ်မှာ BNB နည်းနည်းလိုပါတယ်။ Wallet estimate ကိုကြည့်ပြီး လိုအပ်သမျှ transaction တွေအတွက် လုံလောက်အောင် ချန်ထားပါ။

Network သို့မဟုတ် token တစ်ခုထည့်တာက wallet ကပြတဲ့အရာကိုပဲ ပြောင်းစေပါတယ်။ ငွေကို မရွှေ့ပေးသလို မပြောင်းလဲပေးပါဘူး။ Token ကို wallet မှာ ပြလိုက်တာနဲ့ fake သို့မဟုတ် unbacked token တစ်ခုတန်ဖိုးရှိလာတာ မဟုတ်ပါဘူး။

ဥပမာ: ERC20 အစား BEP20 USDT ပို့မိတယ်

Exchange တစ်ခုကနေ 500 USDT ကို ကိုယ့်သာမန် personal wallet ဆီ withdraw လုပ်တယ်ဆိုပါစို့။ Ethereum သုံးဖို့ ရည်ရွယ်ပေမယ့် BNB Smart Chain ကိုရွေးလိုက်ပါတယ်။

Withdrawal record နဲ့ BscScan မှာ token transfer က သင့် wallet address အတိအကျဆီ ရောက်သွားတာကို ပြပါတယ်။ အဲဒီ account ကို BNB Smart Chain ပေါ်မှာ ဖွင့်ပြီး verified token ကို ပြလိုက်တော့ 500-token balance ပေါ်လာပါတယ်။

အခု သင် BNB Smart Chain ပေါ်က token တွေကို သုံးနိုင်ပါပြီ။ Ethereum ပေါ်မှာ ငွေလိုချင်တယ်ဆိုရင် network နှစ်ခုကြား supported transfer route တစ်ခု လိုသေးပါတယ်။ BNB Smart Chain ကိုသုံးပြီး ကိုယ့် address ဆီပဲ ပြန်ပို့လိုက်ရင် token တွေက BNB Smart Chain ပေါ်မှာပဲ ဆက်ရှိနေမှာပါ။

Ethereum ပေါ်မှာရှိတဲ့ ETH က ဒီ BNB Smart Chain transfer အတွက် fee မပေးနိုင်ပါဘူး။ Wallet က အခြား supported payment method တစ်ခုကို တိတိကျကျ ပံ့ပိုးထားတာ မဟုတ်ရင် gas က transaction ကို process လုပ်တဲ့ network ပေါ်မှာ ရှိရပါမယ်။

အခြား wallet app တစ်ခုက address မတူတာ ပြရင်

ခဏရပ်ပြီး account selection ကို စစ်ပါ။ Recovery phrase တစ်ခုက account အများကြီး ဖန်တီးနိုင်ပြီး app မတူရင် အဲဒီ account တွေကို ရွေးသုံးတဲ့ setting လည်း မတူနိုင်ပါတယ်။ Wallet documentation မှာ ဒီ setting ကို derivation path လို့ ခေါ်နိုင်ပါတယ်။

Same phrase ကို restore လုပ်ပြီး empty account ပေါ်လာတာနဲ့ original balance ပျောက်သွားတယ်လို့ မဆိုနိုင်ပါဘူး။ တခြား account တစ်ခုကို ဖွင့်မိတာ ဖြစ်နိုင်ပါတယ်။ Original wallet maker ရဲ့ recovery instructions ကို လိုက်နာပြီး destination address အပြည့်အစုံကို စစ်ပါ။

မှန်တဲ့ account ကို ရှာပေးမယ်လို့ ဆိုတဲ့ website ထဲကို recovery phrase မထည့်ပါနဲ့။

Hardware wallet သုံးရင်

Device ရဲ့ ပုံမှန် app က အဲဒီ network ကို ပံ့ပိုးသလား စစ်ပါ။ မပံ့ပိုးရင် device maker က အခြား wallet interface တစ်ခုနဲ့ device ကို ချိတ်သုံးဖို့ ပံ့ပိုးထားနိုင်ပါတယ်။

ဥပမာ Trezor က supported EVM network အခြားတွေမှာ asset တွေကို access လုပ်ဖို့ Trezor Connect ကတစ်ဆင့် compatible third-party wallet သုံးနည်းကို documentation မှာ ရှင်းပြထားပါတယ်။ Transaction တွေကို device ကိုယ်တိုင်ပဲ sign လုပ်နေဆဲ ဖြစ်ပါတယ်။

Hardware-wallet connection process ကိုသုံးပြီး ရွေးထားတဲ့ account မှန်မမှန် စစ်ပါ။ Balance မြင်ချင်ရုံနဲ့ device ရဲ့ recovery phrase ကို website သို့မဟုတ် software wallet ထဲ မထည့်ပါနဲ့။

ကိုယ့် wallet က smart wallet ဖြစ်ရင်

Smart wallet တစ်ခုက receiving address ကို contract code နဲ့ ထိန်းချုပ်ထားနိုင်ပါတယ်။ App ရဲ့ recovery phrase, passkey သို့မဟုတ် signing key ရှိတယ်ဆိုတာတင် အခြား network ပေါ်မှာ အဲဒီ address ကနေ တိုက်ရိုက်ပို့နိုင်တယ်လို့ မဆိုလိုပါဘူး။

ရွေးခဲ့တဲ့ network ပေါ်မှာ account ကို deploy လုပ်ပြီး အသုံးပြုနိုင်သလားဆိုတာ wallet provider ကို မေးပါ။ မရရင် အောက်က smart-contract section ကို ကြည့်ပါ။ ပုံမှန် network-switching steps နဲ့ မလုံလောက်နိုင်ပါဘူး။

2. ငွေတွေ exchange ဆီ ရောက်သွားတယ်

Receiving exchange ကို ဆက်သွယ်ပါ။ Exchange deposit address က သင့် account ထဲမှာ ပေါ်နေသော်လည်း exchange ရဲ့ custody system က ထိန်းချုပ်ထားတာပါ။

အဲဒီ address ကို personal wallet ထဲ import လုပ်ရုံနဲ့ ထိန်းချုပ်ခွင့် မရနိုင်ပါဘူး။ Customer support ကလည်း private key ကို ရိုးရိုးပေးလို့မရပါဘူး။ Exchange recovery လုပ်ဖို့ platform ရဲ့ custody နဲ့ security system အတွင်းမှာ အလုပ်လုပ်နိုင်တဲ့ process တစ်ခု လိုပါတယ်။

Sending exchange က withdrawal record ကို ပေးနိုင်ပြီး ဘယ် network သုံးခဲ့လဲ ရှင်းပြနိုင်ပါတယ်။ Confirmed withdrawal တစ်ခု external address ဆီ ရောက်သွားပြီးရင် sender က ပုံမှန်အားဖြင့် ပြန်ဆွဲယူလို့ မရတော့ပါဘူး။

Technical access နဲ့ recovery eligibility က သီးခြားကိစ္စတွေပါ

Exchange တစ်ခုက address ကို သိနိုင်ပေမယ့် အခြား network ပေါ်က အဲဒီ token ကို အဲဒီ address ကနေ ရွှေ့ဖို့ supported method မရှိနိုင်ပါတယ်။ Operational limit, security check သို့မဟုတ် service policy ကြောင့် recovery ကို ငြင်းနိုင်ပါတယ်။

ဒီမေးခွန်းသုံးခုက မတူပါဘူး:

• တကယ်သုံးခဲ့တဲ့ network ပေါ်က ဒီ address ကို exchange က ထိန်းချုပ်သလား?
• သူ့ system က ဒီ token အတိအကျကို လုံခြုံစွာ ရွှေ့နိုင်သလား?
• သူ့ recovery service က ဒီ deposit ကို လက်ခံသလား?

Exchange တစ်ခုက token ကို trading အတွက် list လုပ်ထားတာတစ်ခုတည်းနဲ့ ဒီမေးခွန်းတွေထဲက တစ်ခုကိုမှ မဖြေနိုင်ပါဘူး။

လက်ရှိ recovery service တွေက ဘာကို ပြသလဲ

Binance: သူ့ global recovery guide မှာ unsupported token တချို့နဲ့ unsupported EVM network ပေါ်က deposit တချို့ကို potential recovery category အဖြစ် ထည့်ထားပါတယ်။ Result ကို အာမခံမထားပါဘူး။ Recipient က ကိုယ့် Binance account ထဲရောက်တဲ့ deposit အတွက် ကိုယ်တိုင် apply လုပ်ရပါတယ်။

Binance က 2025 ခုနှစ်အတွင်း incorrect-deposit recovery case 38,648 ခု၊ စုစုပေါင်း $48 million ကို ကူညီပေးခဲ့တယ်လို့ ဖော်ပြထားပါတယ်။ ဒီကိန်းဂဏန်းတွေက deposit error အားလုံးကို ကျယ်ကျယ်ပြန့်ပြန့် ထည့်တွက်ထားတာဖြစ်ပြီး wrong network တင် မဟုတ်ပါဘူး။ သင့် case အတွက် success rate ကို မပြောပြနိုင်ပါဘူး။

Coinbase: သူ့ recovery service က asset နဲ့ network အချို့ကိုပဲ လက်ခံပြီး eligible recovered funds ကို connected self-custody wallet ဆီ ပို့ပါတယ်။ Transaction ID, Coinbase receiving address နဲ့ actual network လိုပါတယ်။ Confirm မလုပ်ခင် destination wallet ကို သေချာစစ်ပါ။

စစ်ဆေးထားတဲ့အချိန်အရ Coinbase service fee က $100 ကျော်တဲ့ amount ရဲ့ 5% ဖြစ်ပြီး network fee ထပ်ပေးရပါတယ်။ ဒါကြောင့် $1,000 recovery တစ်ခုအတွက် network cost မပါခင် service fee $45 ဖြစ်ပါတယ်။ တကယ့် recovery process ထဲမှာ ပြတဲ့ fee ကိုပဲ အတည်ယူရပါမယ်။

Kraken: သူ့ recovery guidance က supported network ပေါ်က unsupported token နဲ့ unsupported network ပေါ်က unlisted asset ကို ခွဲထားပါတယ်။ Case တချို့က recover မရနိုင်ပြီး recovery work မစခင် cost ကို အသိပေးပါတယ်။

ကိုယ်သုံးနေတဲ့ platform နဲ့ account အတိအကျအတွက် guidance ကို သုံးပါ။ Binance နဲ့ Binance.US ရဲ့ recovery policy တွေ မတူပါဘူး။ Availability က account သို့မဟုတ် region အလိုက်လည်း ကွာနိုင်ပါတယ်။

Exchange example နဲ့ recovery policy တွေကို 18 October 2026 ရက်နေ့မှာ စစ်ဆေးထားပါတယ်။ Eligibility, fee နဲ့ procedure တွေ ပြောင်းလဲနိုင်ပါတယ်။

Exchange ကို ဘာမေးရမလဲ

သူ့ official missing-deposit သို့မဟုတ် asset-recovery process ကိုဖွင့်ပြီး ဒီ article ရဲ့ အောက်ပိုင်းမှာ ဖော်ပြထားတဲ့ evidence တွေကို ပေးပါ။ ဒီ specific token contract ကို ဒီ specific network ပေါ်မှာ ဒီ specific deposit address အတွက် recover လုပ်ပေးနိုင်သလား မေးပါ။

Tool က transaction ကို မရှာနိုင်ရင် ဒီ detail တွေကို အရင်စစ်ပါ။ Public explorer ပေါ်မှာ transaction ရှိနေတာတောင် tool ရဲ့ supported case မဖြစ်နိုင်ပါဘူး။ Manual review ရှိမရှိ support ကို မေးပါ။

Recovery ကို လက်ခံမလုပ်ခင် fee, ခန့်မှန်း processing time နဲ့ ရလဒ်က account credit ဖြစ်မလား external refund ဖြစ်မလား အတည်ပြုပါ။ Fee estimate က အာမခံမဟုတ်ပါဘူး။ Deposit သေးရင် cost က recovered amount ရဲ့ အများကြီးကို စားသွားနိုင်ပါတယ်။

Support က ငြင်းရင် evidence မလုံလောက်လို့လား၊ technical limitation ကြောင့်လား၊ current policy ကြောင့်လား မေးပါ။ သူတို့အဖြေနဲ့ transaction details ကို သိမ်းထားပါ။ နောက်ပိုင်း policy ပြောင်းနိုင်ပေမယ့် deposit ဟောင်းတစ်ခုကို ကူညီမယ်လို့ အာမခံမရှိပါဘူး။

Refund ကို ဒုတိယ missing deposit မဖြစ်အောင် သတိထားပါ

Original sending address က သင့် deposit address မဟုတ်နိုင်ပါဘူး။ Exchange တွေက shared operational wallet တွေကနေ withdrawal ပို့တာ များပါတယ်။

Recovery က token ကို အဲဒီ shared wallet ဆီ ပြန်ပို့ရင် sending exchange က token ရနိုင်ပေမယ့် သင့် account ကို အလိုအလျောက် credit မလုပ်ပေးနိုင်ပါဘူး။ Coinbase က payment ကို သူ့ original sending address ဆီ ပြန်မပို့ဖို့ သတိပေးထားပြီး Kraken က returned withdrawal တွေမှာ manual recovery လိုနိုင်တယ်လို့ ပြောထားပါတယ်။

Recovery process တချို့က receiving wallet ကို ကိုယ်တိုင်ရွေးခွင့်ပေးပါတယ်။ တချို့က original source ဆီပဲ ပြန်ပို့ရမယ်လို့ သတ်မှတ်ပါတယ်။ မစခင် ဘယ် rule သက်ဆိုင်လဲ မေးပါ။

• ဘယ် token ကို ပြန်ပို့မှာလဲ?
• ဘယ် network ပေါ်မှာလဲ?
• ဘယ် address အတိအကျဆီလဲ?
• Receiving service က အဲဒီ token နဲ့ network ကို လက်ခံမလား?
• Memo သို့မဟုတ် tag လိုသလား?

Exchange B က Exchange A ရဲ့ shared sending wallet ဆီ refund လုပ်ရင် Exchange A က အဲဒီငွေကို သင့် account ထဲ ဘယ်လို credit လုပ်မလဲ မေးပါ။ Original transaction ID, refund transaction ID နဲ့ support record နှစ်ဖက်စလုံးကို သိမ်းထားပါ။ Exchange A က return ကို ရှာတွေ့ပြီး သင့် account ထဲ credit လုပ်ပြီးမှ သင့်အတွက် recovery ပြီးဆုံးပါတယ်။

3. ငွေတွေ အခြားလူတစ်ယောက်ဆီ ရောက်သွားတယ်

ကိုယ်သိတဲ့လူတစ်ယောက်ဆီ ပို့ခဲ့တာဆိုရင် transaction ID, actual network, token contract နဲ့ receiving address ကို သူ့ကို ပေးပါ။

သူက compatible ဖြစ်တဲ့ ordinary wallet account ကို ထိန်းချုပ်ထားရင် အဲဒီ network ပေါ်မှာ balance ကို စစ်ပြီး transfer အသစ်တစ်ခု ပြန်လုပ်နိုင်ပါတယ်။ သူ့ recovery phrase ကို သင်မလိုသလို သင့် recovery phrase ကိုလည်း သူမလိုပါဘူး။

သူက exchange deposit address ပေးခဲ့တာဆိုရင် ပုံမှန်အားဖြင့် recipient ကိုယ်တိုင် သူ့ account ထဲကနေ recovery request ဖွင့်ရပါတယ်။ သင့် withdrawal record က ကူညီနိုင်ပေမယ့် သင့် recovery form ကတစ်ဆင့် သူ့ exchange account ကို သင်မစီမံနိုင်ပါဘူး။

Merchant သို့မဟုတ် payment processor ဖြစ်ရင် payment support team ကို ဆက်သွယ်ပါ။ Transaction detail တွေအပြင် invoice သို့မဟုတ် payment reference ကိုပါ ထည့်ပေးပါ။ မြင်နေရတဲ့ address က merchant မဟုတ်ဘဲ processor ရဲ့ address ဖြစ်နိုင်ပါတယ်။

Address က မသိတဲ့သူတစ်ယောက်ပိုင်တာဆိုရင် refund ကို အတင်းလုပ်ခိုင်းနိုင်တဲ့ ပုံမှန် wallet function မရှိပါဘူး။ Transaction hash က private key ကို ဖော်ထုတ်မပေးနိုင်ပါဘူး။ Explorer label က ဘယ် service ကို ဆက်သွယ်ရမလဲဆိုတာ အကြံပြုနိုင်ပေမယ့် address ကို ဘယ်သူထိန်းချုပ်ထားတယ်ဆိုတာ အတည်မပြုနိုင်ပါဘူး။

ဘယ်သူပဲ ပြန်ပို့ပေးမယ်ဆိုတာဖြစ်ဖြစ် အဲဒီ token နဲ့ network အတိအကျကို လက်ခံတဲ့ destination တစ်ခုကို အရင်သဘောတူထားပါ။ Original sending address က သင့်တော်မယ်လို့ မယူဆပါနဲ့။

4. Receiving address က smart contract ဖြစ်နေတယ်

Smart contract တစ်ခုက သူ့ထဲမှာ program လုပ်ထားတဲ့ rule တွေအတိုင်းပဲ လုပ်ပါတယ်။ အဲဒီ contract ကို ဖန်တီးထားတဲ့ လူ သို့မဟုတ် ကုမ္ပဏီမှာ အဲဒီဆီပို့ထားတဲ့ token အားလုံးကို ထုတ်ယူနိုင်တဲ့နည်း အလိုအလျောက် ရှိနေမယ်လို့ မဆိုနိုင်ပါဘူး။

Transfer အောင်မြင်ပေမယ့် token တွေ ပိတ်မိနေနိုင်တဲ့အကြောင်း

Standard ERC20 transfer တစ်ခုက contract address အောက်မှာ balance တစ်ခု record လုပ်နိုင်ပေမယ့် အဲဒီ contract ကို token ပြန်ထုတ်ပေးနိုင်သလား မမေးပါဘူး။ Transfer အောင်မြင်ပေမယ့် recipient ဘက်မှာ သုံးလို့ရတဲ့ withdrawal route မရှိနိုင်ပါတယ်။

Contract မှာ အောက်ပါတို့ရှိရင် recovery ဖြစ်နိုင်ပါတယ်:

• Token အတိအကျအတွက် အလုပ်လုပ်တဲ့ withdrawal သို့မဟုတ် rescue function။
• Authorized owner တွေက token ကို ပို့ဖို့ သုံးနိုင်တဲ့ general transaction function။
• Authorized administrator တွေက recovery route တစ်ခု ထည့်နိုင်တဲ့ existing upgrade mechanism။

ဒီထဲက ဘာတစ်ခုမှ မသက်ဆိုင်ရင် project team က မကူညီနိုင်တာ ဖြစ်နိုင်ပါတယ်။ Token issuer မှာ case အနည်းငယ်အတွက် သီးခြား intervention process ရှိနိုင်ပေမယ့် ordinary wallet setting နဲ့ contract ထဲက မရှိတဲ့ functionality ကို ထည့်လို့ မရပါဘူး။

Token ကို token contract ကိုယ်တိုင်ဆီ ပို့မိတဲ့အခြေအနေပါ ဒီအထဲ ဝင်ပါတယ်။ Contract က တကယ့် token recipient ဖြစ်ခဲ့သလား၊ ဒါမှမဟုတ် main transaction ရဲ့ To address ပဲလားဆိုတာ အရင်စစ်ပါ။

Smart wallet က အဲဒီ chain ပေါ်မှာ မရှိသေးတောင် recover ဖြစ်နိုင်ပါတယ်

Smart wallet တချို့မှာ contract မဖန်တီးခင်ကတည်းက တွက်ချက်လို့ရတဲ့ address ရှိပါတယ်။ Wallet ကို အဲဒီ network ပေါ် deploy မလုပ်ရသေးခင် အခြား network တစ်ခုမှာ အဲဒီ address ဆီ ငွေရောက်နိုင်ပါတယ်။

Wallet provider က အဲဒီ address အတိအကျမှာ မှန်ကန်တဲ့ wallet ကို ဖန်တီးပြီး access ပြန်ပေးနိုင်တာ ဖြစ်နိုင်ပါတယ်။ ဒါက original setup နဲ့ လိုအပ်တဲ့ deployment contract တွေ second network ပေါ်မှာ compatible ဖြစ်ပြီး ရှိမရှိပေါ် မူတည်ပါတယ်။

Safe က ဒီလို recovery ကို documentation ထဲမှာ ဖော်ပြထားပေမယ့် Safe အားလုံး သို့မဟုတ် network အားလုံးအတွက် မဖြစ်နိုင်ပါဘူး။

အလွယ်မမြင်နိုင်တဲ့ ပြဿနာတစ်ခုက original signer list ပါ။ Safe ကို အခြား network ပေါ်မှာ ပြန်ဖန်တီးရင် initial owner တွေနဲ့ လိုအပ်တဲ့ signature အရေအတွက်ကို ပြန်ရနိုင်ပါတယ်။ ပထမ network ပေါ်မှာ နောက်ပိုင်းပြောင်းထားတဲ့ အချက်တွေက အလိုအလျောက် မလိုက်ပါဘူး။ Original signing key တွေ ပျောက်သွားတာ သို့မဟုတ် compromise ဖြစ်တာဆိုရင် recovery ပိတ်သွားနိုင်သလို မလုံခြုံနိုင်ပါဘူး။

မစခင် deployment နဲ့ ownership history ကို provider ဆီ စစ်ခိုင်းပါ။ Random contract သို့မဟုတ် wallet အသစ်တစ်ခု ဖန်တီးရုံနဲ့ arbitrary address တစ်ခုကို claim လုပ်လို့ မရပါဘူး။

Project team က ဘာတွေ စစ်ရမလဲ

• Actual network ပေါ်မှာ ဒီ address အတိအကျမှာ မှန်တဲ့ contract ကို deploy လုပ်ထားသလား?
• မလုပ်ရသေးရင် အဲဒီ wallet အတိအကျကို အဲဒီမှာ deploy လုပ်လို့ ရသေးသလား?
• ဘယ် owner သို့မဟုတ် signer တွေက ထိန်းချုပ်မလဲ?
• သူ့ code က ဒီ token အတိအကျကို ရွှေ့ခွင့်ပေးသလား?
• Token တွေ address မှာ ရှိသေးသလား?

Explorer မှာ contract code မပြတာတစ်ခုတည်းနဲ့ အဖြေမဆုံးဖြတ်နိုင်ပါဘူး။ Ordinary account, မသုံးရသေးတဲ့ address သို့မဟုတ် smart wallet တစ်ခုရဲ့ အနာဂတ် address ဖြစ်နိုင်ပါတယ်။ Contract label ရှိနေတာတောင် account ကို ဘယ်လိုထိန်းချုပ်ထားလဲ အပြည့်အစုံ မရှင်းပြနိုင်ပါဘူး။ Wallet provider ရဲ့ documentation နဲ့ case-specific review ကို သုံးပါ။

Official project team ကို မြန်မြန်ဆက်သွယ်ပါ။ Routing contract တချို့က balance ကို လုံခြုံစွာ သိမ်းဖို့ ဒီဇိုင်းမလုပ်ထားပါဘူး။ Uniswap က router address တချို့မှာ ကျန်နေတဲ့ token တွေကို နောက်ပိုင်း transaction တွေက အသုံးပြုနိုင်တယ်လို့ သတိပေးထားပါတယ်။ ဘာလုပ်မလဲ စဉ်းစားနေချိန်အတွင်း contract deposit တိုင်း ဆက်ရှိနေမယ်လို့ မယူဆပါနဲ့။

TRC20, Bitcoin, Solana သို့မဟုတ် BEP2 ဆိုရင်ကော?

ERC20 အစား TRC20 ဆိုရင် သီးခြားစစ်ဆေးရမယ်

ပုံမှန် EVM recovery steps တွေက network combination အားလုံးကို မဖုံးလွှမ်းပါဘူး။ TRON, Bitcoin, Solana နဲ့ အခြား system တွေက address format, account rule သို့မဟုတ် signing key မတူတာတွေ ရှိနိုင်ပါတယ်။

Withdrawal form က address ကို လက်မခံရင် transfer ကို အတင်းလုပ်ဖို့ address ကို မပြင်ပါနဲ့။ Transfer ဖြစ်ပြီးသားဆိုရင် blockchain record ကနေ တကယ့် receiving address ကို ရှာပြီး receiving wallet သို့မဟုတ် platform ကို case-specific စစ်ဆေးခိုင်းပါ။

Address system မတူတာကြောင့် case တိုင်း impossible ဖြစ်တာ မဟုတ်ပါဘူး။ TRON developer documentation အရ same public key အတွက် TRON address က Ethereum address နဲ့ ဆက်စပ်ပါတယ်။ ဒါပေမယ့် recovery phrase တစ်ခုတည်းကနေ default အဖြစ်ထွက်တဲ့ TRON နဲ့ Ethereum account တွေက key မတူနိုင်ပါတယ်။

ဒါဟာ address ပြောင်းရေးနည်းအတွက် general recipe မဟုတ်ဘဲ exact technical assessment လုပ်ဖို့ လိုတဲ့အကြောင်းပြချက်ပါ။ Address ရေးပုံပြောင်းတာနဲ့ network ကြား ငွေမရွှေ့သလို ငွေကို ထိန်းချုပ်ခွင့်လည်း မရပါဘူး။

BEP2 က BEP20 မဟုတ်ပါဘူး

BEP2 က အနားပေးထားပြီးဖြစ်တဲ့ BNB Beacon Chain နဲ့ သက်ဆိုင်ပြီး bnb1 နဲ့စတဲ့ address တွေကို သုံးပါတယ်။ BEP20 က BNB Smart Chain နဲ့ သူ့ Ethereum-style address တွေနဲ့ သက်ဆိုင်ပါတယ်။

BEP2 နဲ့ BEP8 token အဟောင်းတွေမှာ သီးခြား recovery process ရှိပြီး BNB Smart Chain ပေါ်က corresponding token တစ်ခုနဲ့ ချိတ်ထားတဲ့ eligible asset တွေအတွက်ပဲ အကန့်အသတ်ရှိပါတယ်။ 1 July 2026 ကစပြီး BNB Chain ရဲ့ hosted recovery tool ကို ရပ်နားပြီး locally run self-service tool ကို သုံးစေထားပါတယ်။ အနားပေးထားတဲ့ tool အကြောင်း guide အဟောင်းကို မလိုက်ဘဲ လက်ရှိ official instructions ကို လိုက်ပါ။

Wrong network ပေါ်မှားပို့ထားတဲ့ USDT ကို Tether က recover လုပ်ပေးနိုင်သလား?

တချို့အခြေအနေမှာ receiving wallet သို့မဟုတ် contract က မကိုင်တွယ်နိုင်တဲ့ recovery ကို Tether က စစ်ဆေးပေးနိုင်ပါတယ်။ ဒါဟာ issuer ရဲ့ အကန့်အသတ်ရှိ service တစ်ခုဖြစ်ပြီး USDT အားလုံးအတွက် refund system မဟုတ်ပါဘူး။

Tether က recover လုပ်ပေးနိုင်တယ်လို့ သတ်မှတ်ထားတဲ့ contract mistake တချို့နဲ့ အခြား destination တချို့ကို စာရင်းပြုထားပါတယ်။ ပထမဆုံး receiving party ဆီ အကူအညီတောင်းဖို့ user ကို တိုက်တွန်းပါတယ်။

သူတို့ထုတ်ပြန်ထားတဲ့ condition တွေထဲမှာ:

• Request က $1,000 ထက် ကျော်ရပါမယ်။
• Tether service သုံးခွင့်ရှိရမယ်၊ verified user ဖြစ်ရပါမယ်။
• Recovery ကို နည်းပညာအရ လုပ်လို့ရမရနဲ့ တကယ်စမ်းမစမ်းကို Tether က ဆုံးဖြတ်ပါတယ်။
• Tether က recovery amount ရဲ့ 10% အထိ သို့မဟုတ် $1,000 ထဲက ပိုများတဲ့ amount ကို fee အဖြစ် ထုတ်ပြန်ထားပါတယ်။ Fee ကို recovered funds ထဲက ဖြတ်ပါတယ်။ မစခင် တကယ့် quote ကို အတည်ပြုပါ။
• Request တစ်ခုက လများစွာ ကြာနိုင်ပြီး အောင်မြင်မယ်လို့ သို့မဟုတ် deadline ရှိမယ်လို့ အာမခံမရှိပါဘူး။

Token အတိအကျကို ဘယ်သူထုတ်ထားလဲ စစ်ပါ။ USDT နာမည်ပါတဲ့ bridged သို့မဟုတ် pegged version တစ်ခုက အခြား service ကို မူတည်ထားနိုင်လို့ Tether process မသက်ဆိုင်နိုင်ပါဘူး။

Transaction ID, destination, amount, မှားယွင်းမှုအကြောင်း ရှင်းပြချက်နဲ့ အရင် recovery attempt record တွေကို သိမ်းထားပါ။ Screenshot တွေ ပါစေလည်း address နဲ့ transaction ID ကို text အနေနဲ့ပါ ပေးပါ။

Access ရပြီးသား funds ကို ရည်ရွယ်ထားတဲ့ network ဆီ ဘယ်လိုရွှေ့မလဲ

ငွေကို spend လုပ်နိုင်ပြီဆိုရင် နောက်ထပ် recovery service မလိုတော့တာ ဖြစ်နိုင်ပါတယ်။ လိုအပ်ချက်နဲ့ ကိုက်ရင် current network ပေါ်မှာပဲ ထားနိုင်ပါတယ်။ အခြား network ဆီရွှေ့တာက သီးခြားဆုံးဖြတ်ချက်ပါ။

Network မတူတာ လိုရင် ဖြစ်နိုင်တဲ့ route နှစ်ခုက:

• Current network ပေါ်က token အတိအကျကို လက်ခံတဲ့ exchange: အဲဒီ network အတွက် ပြထားတဲ့ receiving details ကိုသုံးပြီး deposit လုပ်ပါ၊ account credit ဝင်တာစောင့်ပြီးတော့ intended network သုံးပြီး withdraw လုပ်ပါ။ မပို့ခင် deposit နဲ့ withdrawal နှစ်ခုစလုံး available ဖြစ်မဖြစ် စစ်ပါ။
• Transfer အတိအကျကို support လုပ်တဲ့ bridge: Official bridge interface ထဲမှာ starting token, destination token, network နှစ်ဖက်, fee နဲ့ receiving address ကို အတည်ပြုပါ။

Bridge က ပို့မယ့် funds ကို access ရဖို့ လိုပါတယ်။ သင် authorize မလုပ်နိုင်တဲ့ exchange address သို့မဟုတ် contract ထဲက balance ကို bridge က recover မလုပ်နိုင်ပါဘူး။

Bridge output က final recipient လက်ခံတဲ့ version နဲ့ မတူတဲ့ token version ဖြစ်နိုင်ပါတယ်။ မဆက်ခင် destination contract ကို စစ်ပါ။ Bridge ရဲ့ actual transfer process ကို လိုက်နာပါ။ Token ကို contract address ဆီ တိုက်ရိုက်ပို့လိုက်တာနဲ့ bridge transfer စတာ မဟုတ်နိုင်ပါဘူး။

လက်တွေ့ကျရင် အရင်ဆုံး amount သေးသေးနဲ့ test လုပ်ပါ၊ ဒါပေမယ့် deposit/transfer minimum အောက် မကျစေပါနဲ့။ Final destination မှာ test amount ကို တကယ်သုံးလို့ရတဲ့အထိ စောင့်ပါ။ Blockchain confirmation တစ်ခုတည်းနဲ့ exchange က လက်ခံပြီးပြီလို့ မဆိုနိုင်ပါဘူး။

Recovery request အတွက် ပြင်ဆင်ရမယ့် evidence

Ticket မဖွင့်ခင် အောက်ပါတို့ကို စုထားပါ:

• Blockchain transaction ID ကို text အနေနဲ့ copy လုပ်ထားပါ။
• တကယ်သုံးခဲ့တဲ့ network နဲ့ ရည်ရွယ်ထားတဲ့ network။
• Actual network ပေါ်က token contract အတိအကျနဲ့ ပြထားတဲ့ token name။
• Address ဆီ တကယ်ရောက်တဲ့ amount။ Fee ဖြတ်ပြီးနောက် withdrawal amount နဲ့ မတူနိုင်ပါဘူး။
• Sending နဲ့ receiving address အပြည့်အစုံ။
• Transfer ရဲ့ date/time နဲ့ time zone။
• Sending wallet သို့မဟုတ် exchange နဲ့ receiving wallet သို့မဟုတ် platform။
• Recipient account ရဲ့ deposit instructions နဲ့ လိုအပ်တဲ့ memo/tag ရှိရင် အဲဒါပါ။
• Originating wallet သို့မဟုတ် exchange ရဲ့ withdrawal record။
• အရင် ticket number, စမ်းကြည့်ထားတဲ့ fix နဲ့ refund transaction ID ရှိရင် အဲဒါပါ။

Public explorer record က transaction ရှိတယ်ဆိုတာ သက်သေပြပါတယ်။ အဲဒါကိုတင်ပြတဲ့သူက funds ပိုင်ရှင်လို့ မသက်သေပြပါဘူး။ Platform က account record, identity check သို့မဟုတ် withdrawal history ပြတဲ့ video တောင်းနိုင်ပါတယ်။

Private account evidence ကို official support channel ကတစ်ဆင့်ပဲ ပေးပါ။ Password, recovery phrase, private key နဲ့ authentication code တွေကို screenshot သို့မဟုတ် recording ထဲ မထည့်ပါနဲ့။

ဒီ support-request template ကို copy လုပ်ပါ

Subject: Wrong-network deposit recovery request: [token], [actual network], [transaction ID]

ကျွန်တော်/ကျွန်မက [amount and token] ကို [receiving address] ဆီ [actual network] ပေါ်မှာ [date, time, and time zone] တုန်းက ပို့ခဲ့ပါတယ်။ [intended network] ကို သုံးဖို့ ရည်ရွယ်ခဲ့ပါတယ်။ Blockchain မှာ [status] လို့ ပြပေမယ့် [deposit ကို credit မလုပ်ရသေး / receiving wallet က access မရ] ဖြစ်နေပါတယ်။

• Transaction ID: [blockchain transaction ID အပြည့်အစုံကို ထည့်ပါ]
• Actual network ပေါ်က token contract: [contract address အပြည့်အစုံ ထည့်ပါ၊ သို့မဟုတ် native coin ဖြစ်ခဲ့ရင် အဲဒီလို ရေးပါ]
• Sending address and service: [address နဲ့ wallet သို့မဟုတ် exchange]
• Receiving address and account: [address နဲ့ သက်ဆိုင်ရာ account reference]
• Blockchain ပေါ်မှာ ရောက်ရှိတဲ့ amount: [amount]
• Memo or tag: [ဘာလိုအပ်ခဲ့လဲ၊ ဘာထည့်ခဲ့လဲ၊ သို့မဟုတ် not applicable]
• Evidence attached: [withdrawal record နဲ့ သက်ဆိုင်ရာ deposit instructions]
• Previous recovery attempts: [အတိုချုံးဖော်ပြချက်နဲ့ ticket number တွေ]

ကျေးဇူးပြုပြီး အသုံးပြုခဲ့တဲ့ network ပေါ်က ဒီ address ကို သင်တို့က ထိန်းချုပ်ထားသလား၊ ဒီ token အတိအကျက recovery eligible ဖြစ်သလား အတည်ပြုပေးပါ။ Eligible ဖြစ်ရင် account ကို credit လုပ်ပေးမလား၊ refund ပြန်ပေးမလား? Refund ရှိရင် fee, ခန့်မှန်း processing time နဲ့ token, network, address, memo requirement တွေကိုလည်း အတည်ပြုပေးပါ။

Funds ကို original sending address ဆီပဲ ပြန်ပို့ရမယ်ဆိုရင် မလုပ်ခင် အတည်ပြုပေးပါ၊ အဲဒါမှ sending platform နဲ့ ကျွန်တော်/ကျွန်မ ညှိနှိုင်းနိုင်ပါမယ်။ Recovery မရနိုင်ရင် evidence မလုံလောက်လို့လား၊ technical limitation ကြောင့်လား၊ current policy ကြောင့်လား ရှင်းပြပေးပါ။

Recovery မဖြစ်နိုင်တော့တဲ့အချိန်နဲ့ ဘယ်အချိန်မှာ ရပ်သင့်သလဲ

Transfer တစ်ခုက အမြဲမြင်နေရပေမယ့် အဲဒီ funds ကို လက်တွေ့သုံးနိုင်တဲ့နည်း ဘယ်သူ့မှာမှ မရှိတာ ဖြစ်နိုင်ပါတယ်။ Common barrier တွေက:

• Accessible controlling key မရှိ: သင်ဆက်သွယ်နိုင်တဲ့ ဘယ်သူကမှ actual destination ကနေ spending ကို authorize မလုပ်နိုင်တော့တာ၊ သို့မဟုတ် လိုအပ်တဲ့ key တွေ အပြီးတိုင် ပျောက်သွားတာ။
• Usable contract route မရှိ: Receiving contract က token ကို transfer မလုပ်နိုင်ဘဲ authorized upgrade, deployment သို့မဟုတ် issuer intervention လည်း မရှိတာ။
• Exchange recovery service မရှိ: Platform က အဲဒီ combination ကို recover မလုပ်နိုင်တာ သို့မဟုတ် မလုပ်ပေးတာ။ ဒါက service limitation ဖြစ်ပြီး သင်္ချာအရ မဖြစ်နိုင်ဘူးဆိုတဲ့ အထောက်အထား မဟုတ် necessarily ပါ။
• Funds ကို ယူသွား သို့မဟုတ် သုံးပြီးပြီ: Original address မှာ မရှိတော့ပါဘူး။ Theft သို့မဟုတ် dispute က သီးခြားဖြေရှင်းရမယ့်ကိစ္စပါ။ အရင်ဆုံး later transfer တွေကို စစ်ပါ၊ exchange က internal လုပ်ငန်းစဉ်အဖြစ် ငွေရွှေ့တာက ပျောက်သွားတယ်လို့ တိုက်ရိုက်မဆိုလိုပါဘူး။
• Asset သို့မဟုတ် network က လိုအပ်သလို မအလုပ်လုပ်တော့: Address ကို access ရတာနဲ့ failed token ရဲ့ backing ကို ပြန်မရနိုင်သလို retired chain ကို ပြန်စမလုပ်နိုင်၊ ပျောက်နေတဲ့ redemption route ကိုလည်း မဖန်တီးနိုင်ပါဘူး။

Recovery မဖြစ်နိုင်ဘူးဆိုတဲ့ မရှင်းလင်းတဲ့ပြောချက်ကို လက်ခံမလုပ်ခင် အကြောင်းရင်းကို မေးပါ။ အလားတူပဲ ယုံကြည်လောက်တဲ့ recovery mechanism ကို မဖော်ပြနိုင်တဲ့ repeated attempt တွေအတွက် ပိုက်ဆံမပေးပါနဲ့။

Recovery လုပ်နေစဉ် ထပ်မဆုံးရှုံးအောင် ကာကွယ်ပါ

• Recovery phrase နဲ့ private key ကို လျှို့ဝှက်ထားပါ။ ဒီ key တွေက ထိန်းချုပ်ထားတဲ့ အခြား asset တွေ၊ အခြား network ပေါ်က asset တွေပါ အန္တရာယ်ရှိစေနိုင်ပါတယ်။ Recovery phrase တစ်ခုက အဲဒီကနေ derive လုပ်ထားတဲ့ အခြား account တွေကိုလည်း ဖော်ထုတ်နိုင်ပါတယ်။
• Platform ရဲ့ official app သို့မဟုတ် website ကနေ support ကို ဖွင့်ပါ။ မတောင်းဘဲရောက်လာတဲ့ message သို့မဟုတ် guaranteed recovery လို့ ကြော်ငြာတဲ့ search ad တွေက service တကယ်ဟုတ်တယ်ဆိုတဲ့ သက်သေမဟုတ်ပါဘူး။
• ဘာကို sign လုပ်နေလဲ နားလည်ပါ။ တရားဝင် process တစ်ခုက wallet ownership signature တောင်းနိုင်ပါတယ်။ Spending approval သို့မဟုတ် account permission က အများကြီးပိုတဲ့ အခွင့်အာဏာ ပေးနိုင်ပါတယ်။ Request ကို ဖတ်ပြီး service ကို verify လုပ်ပါ။
• Official recovery process ထဲမှာ fee ကို အတည်ပြုပါ။ တကယ့် service တွေ fee ကောက်နိုင်ပါတယ်။ မသိတဲ့လူတစ်ယောက်က tax, activation deposit သို့မဟုတ် repeated release payment တောင်းနေတာနဲ့ recovery route တကယ်ရှိတယ်လို့ မဆိုနိုင်ပါဘူး။
• Control ရှိတာ အတည်ပြုပြီးမှ gas ထည့်ပါ။ အသစ်ထည့်တဲ့ gas က wallet ထဲကနေ ချက်ချင်း မမျှော်လင့်ဘဲ ထွက်သွားရင် ထပ်မဖြည့်ဘဲ sweeper bot ရှိနိုင်မဖြစ်နိုင် စစ်ပါ။
• Final transfer plan ကို တိတိကျကျ ထားပါ။ မပို့ခင် သို့မဟုတ် refund approve မလုပ်ခင် token, network, address နဲ့ memo ရှိရင် အဲဒါကို ထပ်စစ်ပါ။

နောင် transfer တစ်ခုမလုပ်ခင် recipient ရဲ့ လက်ရှိ deposit instructions ကနေ စတင်ပါ၊ network နဲ့ token အတိအကျကို တိုက်စစ်ပြီး address အပြည့်အစုံကို verify လုပ်ပါ။ Test လုပ်မယ်ဆိုရင် ကျန်တာမပို့ခင် recipient က funds ကို တကယ်သုံးလို့ရပြီလို့ အတည်ပြုတဲ့အထိ စောင့်ပါ။