· four exchange APIs · rebuilt daily
Kripto varlıkları yanlış ağ hedeflerine gönderdiğinizde, kurtarma işlemi ya standart bir key import adımıdır ya da platform müdahalesi olmadan imkansızdır. Temelde yatan mekanizma, adres türetimine ve private key custody durumuna bağlıdır.
Ethereum, Polygon, Arbitrum, Optimism ve BNB Chain gibi Ethereum Virtual Machine (EVM) ağları, adres oluşturmak için aynı secp256k1 eliptik eğri kriptografisini kullanır. Ethereum üzerindeki public key'iniz, Polygon veya Arbitrum üzerindeki public key'iniz ile matematiksel olarak aynıdır. Token'lar istenmeyen bir EVM zincirindeki bir adrese gönderildiğinde, varlıklar o ağda tam olarak aynı public adreste var olmaya devam eder.
Bu varlıklara erişmek ağ düzeyinde bir müdahale veya özel zincir reorganizasyonları gerektirmez. Private key'inizi barındıran bir cüzdan arayüzünü hedef Remote Procedure Call (RPC) endpoint'ine yönlendirmek yeterlidir.
Worth knowing
Bir private key, EVM uyumlu her zincirde aynı public adresi kontrol eder. Recovery phrase'inizi çoklu zincir destekleyen bir arayüze import etmek, istenmeyen EVM ağlarında gönderilen varlıklara anında erişim sağlar.
Varlık kurtarma protokolü, alıcı adresin bir self-custody cüzdanı mı yoksa bir borsa deposit hesabı mı olduğuna bağlı olarak farklılık gösterir.
İlk olarak, kaynak ağın block explorer'ı üzerinden transaction hash'i bulun. İşlem durumunun başarılı olarak işaretlendiğini doğrulayın ve transferi alan kontrat veya cüzdan adresini not edin.
İkinci olarak, alıcı hedefin seed phrase veya private key'ine sahip olduğunuz bir self-custody cüzdanı olup olmadığını kontrol edin. Yanıt evet ise, MetaMask veya Rabby gibi cüzdan arayüzünüze hedef zincirin RPC özel ağ ayarlarını ekleyin. Yeni eklenen ağı seçtiğinizde varlıklar adres bakiyeniz altında görüntülenecektir.
Üçüncü olarak, alıcı hedef bir borsa deposit adresi ise, borsanın kullandığınız ağı destekleyip desteklemediğini kontrol edin. Borsa, token ve ağ kombinasyonunu destekliyorsa deposit genellikle otomatik olarak veya otomatik bir self-service kurtarma aracı aracılığıyla hesaba tanımlanır. Ağ platform tarafından eşleştirilmemişse (unmapped), transaction hash, deposit adresi ve net token miktarını içeren bir müşteri destek bileti (ticket) açmanız gerekir.
Where this goes wrong
Destek ekibinin private key'leri manuel olarak çıkarmasını (extract) beklemek operasyonel risk yaratır. Token kurtarma hizmeti sunduğunu iddia eden harici servislere asla private key'lerinizi, seed phrase'lerinizi veya uzaktan oturum erişiminizi vermeyin.
Yanlış yönlendirilen fonlar merkezi bir platforma ulaştığında manuel müdahale gerekir; çünkü dahili veritabanı defterleri eşleştirilmemiş smart contract'ları veya desteklenmeyen RPC node'larını izlemez. Kurtarma işleminin gerçekleştirilmesi, mühendislerin ilgili private key'i güvenli bir çevrimdışı (offline) ortamda izole etmesini, fonları harici bir cüzdana geri aktarmak için özel bir işlem broadcast etmesini ve dahili bakiyeleri güncellemesini gerektirir.
Operasyonel güvenlik kısıtlamaları nedeniyle borsalar sıklıkla manuel kurtarma için minimum token değeri eşikleri belirler. İşlem ücretleri platforma göre değişir; ancak standart işlem ücreti esasları borsa operasyonel yapıları hakkında fikir verir:
| Venue | Spot Maker Fee | Spot Taker Fee | Futures Maker Fee | Futures Taker Fee |
|---|---|---|---|---|
| Bitget | 0.0010 | 0.0010 | 0.0002 | 0.0003 |
| Bybit | 0.0010 | 0.0010 | 0.0002 | 0.00055 |
| MEXC | 0.0000 | 0.0005 | 0.0000 | 0.0002 |
| OKX | 0.0008 | 0.0010 | 0.0002 | 0.0005 |
Yanlış yönlendirilen işlemin değeri manuel extraction işleminin operasyonel maliyetinden düşükse, borsalar kurtarma talebini reddedecek ve varlıklar süresiz olarak borsanın deposit adresinde kilitli kalacaktır.
What to do instead
Borsalar arasında veya yerel olmayan (non-native) köprü rotalarında tam bakiyeleri transfer etmeden önce küçük bir test işlemi gönderin.
Ağlar arası yanlış yönlendirmenin herhangi bir kurtarma olasılığı olmaksızın kalıcı sermaye kaybıyla sonuçlandığı iki farklı senaryo vardır.
Birincisi, token'ların uyumsuz kriptografik mimariler arasında gönderilmesidir. Örneğin, yerel bir Solana işlemini doğrudan bir Bitcoin taproot public adresine broadcast etmek, protokol konsensüs katmanında başarısız olur veya geçersiz wrapped bridge kontratları aracılığıyla gönderilirse yükü (payload) yakar (burn). Key derivation EVM dışı zincirlerde temelden farklı olduğu için hedef defterde eşleşen bir private key bulunmaz.
İkinci senaryo, fonların doğrudan transfer veya çekim fonksiyonlarından yoksun, unmanaged bir smart contract adresine gönderilmesidir. Token'lar bir bridge kontratı adresine veya varsayılan (fallback) yürütme mantığı eksik bir token kontratına yönlendirilirse, varlıklar kontrat bytecode'unda kalıcı olarak kilitlenir. Hiçbir varlık bir smart contract yürütme adresi için private key tutmaz; bu da teknik çıkarmayı imkansız kılar.
Hedef ağın özel RPC ağ ayarlarını cüzdan arayüzünüze ekleyin. EVM adresleri zincirler arasında birebir aynı private key'leri paylaştığından, doğru zincir tanımlayıcısına bağlandığınızda varlıklarınız otomatik olarak görünecektir.
Hayır, borsalar key derivation'ın başarısız olduğu uyumsuz kriptografik mimariler üzerinden gönderilen token'ları geri alamaz. Borsa o ağ için teknik altyapıyı veya private key erişimini sürdürmüyorsa, fonlar kalıcı olarak kaybolur.
Eşleştirilmemiş deposit adreslerinden fon çıkarmak, standart otomatik deposit taramalarının dışında manuel teknik müdahale ve hot wallet key yönetimi gerektirir. Platformlar, mühendislik giderlerini ve güvenlik risklerini karşılamak için operasyonel ücretler veya bakiye minimumları uygular.
Hayır, smart contract yürütme adreslerinin private key'leri yoktur. Fonlar doğrudan otomatik çekim mantığından yoksun bir token veya bridge kontratına gönderilirse, token'lar state bytecode'unda kalıcı olarak kilitli kalır.