Bir gün, bir kullanıcı rabbit.io desteğiyle iletişime geçerek, bir takas işleminden sonra 1.000 USDC yerine 1 XLM aldığını iddia etti.
Bu ciddi bir kayıp gibi görünüyordu. Bir lümen, bir dolardan çok daha az değerdedir: Şu anda XLM yaklaşık 0,22 dolar civarında işlem görüyor. Neredeyse tüm miktarı bu şekilde kaybetmek herkes için endişe verici olurdu.
Doğal olarak durumu hemen araştırmaya başladık. Eğer bizim hatamız nedeniyle yanlış miktar veya yanlış varlık gönderilmiş olsaydı, hemen harekete geçer ve kullanıcının doğru fonları aldığından emin olurduk.
Ancak hikaye çok daha ilginç çıktı.
Sistemlerimiz tam olarak amaçlandığı gibi çalıştı. Bizim tarafımızda herhangi bir hata veya aksaklık olmaksızın, kullanıcının verdiği adrese 1.000 USDC gönderilmişti. Yine de, Stellar ağında, gözden kaçırdığınızda 1.000 USDC'yi kelimenin tam anlamıyla 1 XLM'e dönüştürebilecek ince bir mimari detay var.
Bunun nasıl olduğunu açıklamama izin verin.
Bir Ethereum Alışkanlığı
rabbit.io müşterisi yeni başlayan biri değildi. Aksine, fonlarını borsalar yerine kasıtlı olarak gözetimsiz (non-custodial) cüzdanlarda saklayan deneyimli bir kripto kullanıcısıydı. Ancak deneyiminin çoğu EVM tabanlı ağlardan geliyordu.
Ethereum dünyasında kullanıcılar basit bir modele alışırlar: Adresinize gönderilen herhangi bir token başarıyla ulaşacaktır. En kötü ihtimalle, token'ı cüzdan arayüzünüze manuel olarak eklemeniz gerekir. Cüzdan uygulaması belirli bir token'ı hiç desteklemese bile, kurtarma ifadenizi (seed phrase) destekleyen başka bir cüzdana aktarabilirsiniz.
Stellar çok daha farklı çalışır.
Mimarisi temel olarak Ethereum, Binance Smart Chain veya Polygon'dan farklıdır. Adres kavramı bile farklıdır. EVM ağlarında adresler aslında ücretsizdir. Stellar'da, defterde (ledger) bir adres oluşturmanın maliyeti 1 XLM'dir.
Ve takastan sonra müşterimizin cüzdanında gördüğü miktar tam olarak buydu: 1 XLM.
Stellar'ın Farkı
Stellar ile EVM tabanlı ağlar arasındaki en önemli fark, varlıkların nasıl alındığında yatar.
Stellar'da, bir cüzdanın herhangi bir yeni token'ın hesaba geçebilmesi için onu açıkça onaylaması gerekir. Örneğin, ilk kez USDC alabilmek için bir Stellar hesabının USDC ihraççısına bir trustline (güven hattı) oluşturması gerekir. Bir güven hattı oluşturmak, ilgili defter kaydını güvence altına alan 0,5 XLM'nin rezerv olarak kilitlenmesini gerektirir.
Başlangıçta, bir token mevcut bir güven hattı olmayan bir adrese gönderilirse işlem başarısız olurdu. Miktarın tamamı göndericide kalırdı.
Stellar Protocol 15 ile birlikte, bu davranış claimable balances (talep edilebilir bakiyeler) özelliğinin getirilmesiyle değiştirildi. Amaç, kullanılabilirliği artırmak ve token'ların "hazırlıksız" hesaplara bile gönderilmesine olanak tanımaktı.
Müşterimizin USDC için güven hattı olmayan Stellar adresine USDC gönderdiğimizde, protokol işlemi şu şekilde gerçekleştirdi:
- fonlar cüzdanımızdan düşüldü;
- fonlar alıcının bakiyesine geçmedi;
- 1.000 USDC, Claimable Balance Entry (Talep Edilebilir Bakiye Kaydı) adı verilen özel bir defter nesnesine yerleştirildi.
Başka bir deyişle, fonlar deftere kaydedildi ve birinin onları açıkça talep etmesini beklemek üzere orada kaldı. Buna kimin yetkili olduğu işlemin koşullarıyla belirlenir. Varsayılan olarak hem gönderici hem de alıcı hak sahibi adaylarıdır.
Peki alıcının hesabındaki 1 XLM nereden geldi? Cevap: Bizden — her ne kadar bunu bilerek göndermemiş olsak da.
Bu tür işlemlerin gerçekte nasıl işlendiği aşağıdadır.
Adım 1. Gönderici bir USDC transferi başlatır ve şu parametrelerle bir işlemi imzalar:
- İşlem: payment (ödeme)
- Varlık: USDC
- Hedef: Stellar ağında henüz mevcut olmayan bir adres
- Miktar: 1.000 USDC
Bu aşamada gönderici, işlemi işlemek için gereken XLM miktarını ödemeyi zımnen kabul eder. Uygulamada, kullanıcılar bu detaya nadiren dikkat ederler çünkü Stellar'daki işlem ücretleri genellikle ihmal edilebilir düzeydedir.
Adım 2. Stellar, işlemin yürütülüp yürütülemeyeceğini kontrol etmek için bir dizi temel doğrulama gerçekleştirir:
- Alıcı hesabı mevcut mu? Hayır
- Aktarılan varlık yerel token XLM mi? Hayır
- Alıcının gönderilen varlık için bir güven hattı var mı? Hayır
Bunlar bir araya geldiğinde, doğrudan bir ödemenin mümkün olmadığı anlamına gelir.
Adım 3. Stellar işlemi doğrudan reddetmek yerine talep edilebilir bakiye mekanizmasını etkinleştirir.
Bunun için ağ:
- 1.000 USDC için talep edilebilir bir bakiye oluşturur,
- bunu kimlerin talep edebileceğini belirtir (hem gönderici hem de alıcı).
Ancak alıcının potansiyel bir talep sahibi olarak listelenebilmesi için alıcı hesabının ağda mevcut olması gerekir. İşlem anında hesap sadece alıcının cüzdan uygulamasında mevcuttu. Henüz Stellar defterinde oluşturulmamıştı.
Bu koşullar altında, hesap aynı işlemin bir parçası olarak oluşturulur.
Daha önce belirtildiği gibi, Stellar'da hesap oluşturmak ücretsiz değildir. Hesabı oluşturmak için gereken 1 XLM, işlemin kaynağından, yani göndericinin bakiyesinden alınır:
- Göndericiden 1 XLM düşülür,
- bu 1 XLM yeni oluşturulan hesaba aktarılır,
- hesap artık aktif kabul edilir.
Bu 1 XLM, işlemi yürütme maliyetinin bir parçasıdır; işlemi imzalarken zımnen kabul ettiğimiz bir maliyet. Teknik olarak alıcının bakiyesine geçer ancak alıcı bunu aslında kullanamaz. Özellikle alıcı, USDC için bir güven hattı oluşturup fonları talep etmek için bu miktarın yarısını alamaz.
Alıcının hesabı ağda zaten mevcut olsaydı ancak sadece USDC'ye güven hattı olmasaydı, ek 1 XLM gerekmeyecekti. Bu durumda alıcı cüzdanında hiçbir görünür değişiklik görmeyecekti.
Sorunu Nasıl Çözdük
İlk adım, alıcının USDC varlığı için bir changeTrust işlemi imzalamasıydı. Bu işlemin başarılı olması için cüzdanın en az 0,5 XLM serbest bakiyeye sahip olması gerekir; bu bakiye güven hattı oluşturulduğunda rezerv olarak kilitlenir.
Müşterimizin hiç serbest XLM'i yoktu. Daha doğrusu, hesaptaki tek XLM, takas sonucunda orada görünen 1 XLM idi — ancak bu miktar temel rezerv olarak tamamen kilitliydi ve kullanılamıyordu.
Bu yüzden basit bir çözüm önerdik: Mevcut herhangi bir kripto paranın küçük bir miktarını lümenle takas edin. Bunu yaptıktan sonra müşterimiz sonunda cüzdanında bir güven hattı oluşturmak için yeterli serbest XLM'e sahip oldu.
USDC güven hattı kurulduğunda, kullanıcı 1.000 USDC'yi talep edebildi. Bu durumda her şey dahil olan tüm taraflar için iyi bitti.
Bu Münferit Bir Durum mu?
Müşterimizin karşılaştığı durum benzersiz değil. Ve tamamen kendi kontrolü altındaki gözetimsiz cüzdanlar kullandığı için gerçekten şanslıydı. Sorunun nispeten kolay çözülmesini sağlayan tam da buydu.
Bu hikaye aklıma geldi çünkü sadece birkaç gün önce başka bir kullanıcının başına gelen çok benzer bir vakayı okudum. Miktar tamamen aynıydı — 1.000 USDC — ancak koşullar sorunun düzeltilmesini çok daha zor hale getiriyordu.
Üç gün önce, Uphold CEO'su Simon McLoughlin'in en son paylaşımının altında, bir Uphold kullanıcısının şu durumu tarif ettiği bir yorum belirdi:
- Stellar ağı üzerinden Uphold borsasına USDC yatırmaya çalışmış.
- Yanlışlıkla Uphold arayüzünde USDC yatırma adresi yerine XLM yatırma adresi seçmiş.
- Tıpkı bizim vakamızda olduğu gibi, 1.000 USDC yerine bakiyesine 1 XLM geçtiğini görmüş.
- Kıdemli bir uzman da dahil olmak üzere Uphold desteği kategorik olarak yanıt vermiş: “Token'larınız bizde değil. Onları göremiyoruz. İade edemeyiz.”
- Fonların gönderildiği cüzdan bu tür senaryolar için bir Talep (Claim) işlevi sağlamıyordu. Büyük olasılıkla kısıtlı işlevselliğe sahip bir gözetimli cüzdandı, muhtemelen başka bir CEX.
- Tüm standart kanalları tükettikten sonra kullanıcı konuyu doğrudan CEO'ya iletmeye çalıştı.
Semptomların ne kadar benzer olduğu göz önüne alındığında, temel sorunun tamamen aynı olduğuna inanıyorum.
Büyük olasılıkla Uphold, adresleri talep üzerine oluşturuyor ve kullanıcının fonları gönderdiği XLM adresi henüz Stellar defterinde oluşturulmamıştı. Bu, işlem sonucunda hesapta neden 1 XLM göründüğünü açıklar. Ancak 1.000 USDC görünmedi ve durumu çözmek, Uphold'un o adres için manuel olarak USDC'ye bir güven hattı oluşturmasını gerektirecektir.
Destek neden yardım etmeyi reddetti?
Tahminim güvenlik mimarisi. Kripto paralarla uğraşan her işletme, cüzdan güvenliğine yoğun yatırım yapar. Görünüşe göre Uphold, beklenen standart yatırma akışı dışında güven hattı oluşturmak için bir süreç uygulamamıştı. Tüm dahili güvenlik gereksinimlerini karşılarken geriye dönük olarak böyle bir işlevsellik eklemek, borsaya kullanıcının kaybettiği 1.000 USDC'den çok daha pahalıya mal olabilir.
Bugün itibariyle CEO'nun paylaşımının altındaki yorum kaldırılmış. Kullanıcının kendisi tarafından mı yoksa borsa tarafından mı silindiğini bilmiyorum. Umarım sorun çözülmüştür ve kullanıcı yorumu kendi isteğiyle kaldırmayı seçmiştir. Ancak yorum Uphold tarafından kaldırıldıysa bu rahatsız edici bir sinyal olurdu.
Bu sorunlar sessizce gömülmemeli. Aksine, diğer kullanıcıların aynı hatayı tekrarlamaması için ilgiyi hak ediyorlar. Bu yüzden hem bizim hikayemizi hem de Uphold kullanıcısının hikayesini burada paylaşmaya karar verdim.
Talep Edilebilir Bakiye Tuzağına Düşerseniz Ne Yapmalısınız?
Dahil olan cüzdanlardan en az biri — göndericinin veya alıcınınki — tamamen fon sahibinin kontrolündeyse durum nispeten basittir:
- Alıcı, cüzdanına küçük bir miktar XLM ekleyebilir, gerekli güven hattını oluşturabilir ve ardından talep edilebilir bakiyeyi talep edebilir.
- Gönderici, talep edilebilir bakiyeyi tek bir işlemle geri alabilir (reclaim) ve ardından fonları, token'ı almaya uygun şekilde hazırlanmış farklı bir alıcı adresine yeniden gönderebilir.
Ancak gözetimli cüzdanlar — örneğin CEX cüzdanları — söz konusu olduğunda işler çok daha karmaşık hale gelir.
Gözetim hizmetleri, özellikle ek operasyonel veya güvenlik riskleri oluşturuyorsa, bir kullanıcının hatasını düzeltmek için cüzdan altyapılarına manuel olarak müdahale etmek zorunda değildir. Sonuç olarak, fonlar teknik olarak defterde hala mevcut olsa bile size yardım reddedilebilir.
Yine de denemeye değer. Borsa özel anahtarları kontrol ettiği sürece, fonların kurtarılma şansı vardır.
Kendinizi bu durumda bulursanız:
- Durumu mümkün olduğunca görünür kılın. X, LinkedIn veya Medium'da yazın. Resmi hesapları etiketleyin. İtibar 1.000 dolardan daha değerlidir.
- Mühendislerin dilini konuşun. Talebiniz şuna benzer bir şey olmalı: “İşlemim [...] ID'li bir Claimable Balance Entry ile sonuçlandı. Fonlar deftere kaydedildi ve cüzdanınızın özel anahtarı tarafından kontrol ediliyor. Sahipliği doğrulamaları ve bir claim_claimable_balance işlemi gerçekleştirmeleri için lütfen bu bileti mühendislik veya DevOps ekibine iletin. Bir kurtarma ücreti ödemeye hazırım.”
- Topluluğa ulaşın. Stellar ekosistemi sıkı bir geliştirici topluluğuna sahiptir. Bazen Discord veya diğer platformlardaki halka açık tartışmalar, büyük borsaların arkasındaki teknik ekipleri şahsen tanıyan kişilerin dikkatini çeker.
Nihayetinde, en iyi çözüm hala önlemdir. Kendi gözetiminizde olmak birçok avantaja sahiptir ancak aynı zamanda yüksek düzeyde sorumluluk getirir. Kripto para gönderirken detaylara dikkat etmek önemlidir, çünkü bazı hataları yapmak düzeltmekten çok daha kolaydır.
