Token Aldım Satamıyorum: Honeypot, Likidite ve Hukuki Başvuru

Satılamayan token incelemesinde işlem hatası, sözleşme kısıtları ve likiditenin ayrıldığı teşhis şeması.

6 Ekim 2026 · Av. Ahmet Karaca · PEGA Hukuk & Danışmanlık

Bir DEX üzerinden token aldınız, cüzdanda bakiye görünüyor fakat satış işlemi sürekli başarısız oluyor. Bu durum honeypot denilen bir satış tuzağından kaynaklanabilir; ancak tek bir başarısız işlem dolandırıcılık kanıtı değildir. Düşük likidite, eksik işlem izni, uyumsuz işlem yolu, fiyat kayması veya ağ ücreti yetersizliği de aynı görüntüyü yaratabilir.

İlk yapılacak şey, arka arkaya ücretli denemeler yapmak veya satışın açılması için bir kişiye para göndermek değildir. Ağ, token sözleşmesi, alış işlemi ve başarısız satışın hangi aşamada kaldığı belirlenmelidir. Sonra satışın teknik nedenle mi, tokena konulmuş bir kısıt yüzünden mi gerçekleşmediği; kısıtı kimin yönettiği ve satın alma sırasında neyin vaat edildiği birlikte incelenir.

Honeypot olayında kişi çoğu zaman kendi onayıyla bir token satın almıştır. Sonradan satamaması, cüzdandaki diğer varlıkların izinsiz çekildiği wallet drainer olayından farklıdır. Her iki mekanizma aynı olayda bulunabilir; fakat deliller ve zarar hesabı ayrı kurulmalıdır.

Kripto varlık uyuşmazlıklarında hukuki danışmanlık için:

WhatsApp E-posta

“Token satılmıyor” derken hangi işlem başarısız?

Cüzdandaki tokenı bir arayüzde görememek, satış rotası bulunamaması, izin işleminin başarısız olması ve imzalanmış satışın zincirde reddedilmesi farklı aşamalardır. İşlem hiç yayınlanmadıysa zincirde TxID olmaması olağandır. Zincire girdiği hâlde başarısız olduysa işlem kimliği, durum ve hata incelemesi mümkün olabilir.

Satış yapılamamasının başlıca açıklamaları
Gözlenen durumAraştırılacak ihtimalTek başına kanıtlamadığı şey
İşlem yolu bulunamıyorİlgili ağda havuz veya yeterli likidite bulunmaması; arayüzün desteklememesiToken yöneticisinin kesin olarak dolandırıcı olduğu
İzin verildi ama satış olmadıApproval ile satışın ayrı işlemler olması; izin verilen harcayıcı ve miktarAlım bedelinin iade edildiği veya satışın tamamlandığı
Satış işlemi zincirde başarısızFiyat kayması sınırı, süre sonu, sözleşme kısıtı veya başka yürütme hatasıHer başarısız denemenin aynı teknik nedene dayandığı
Satış yapılabiliyor, çok az karşılık geliyorYüksek satış kesintisi, düşük likidite, işlemin fiyat etkisiCüzdanda gösterilen toplam değerin gerçekten tahsil edilebilir olduğu
Bazı adresler satıyor, siz satamıyorsunuzAdres bazlı kısıt, izin listesi, değişen kurallar veya farklı işlem koşullarıSatabilen bütün adreslerin aynı kişiye ait olduğu
“Kilidi açmak” için yeni ödeme isteniyorSatış vaadiyle ek para alma veya ikinci dolandırıcılıkTalep edilen ödemenin gerçek ağ ücreti veya resmî vergi olduğu

Uniswap Labs’ın başarısız işlem açıklaması, fiyat kayması, süre sonu, ağ varlığının yetersizliği ve tokenın işlem yapısına ilişkin sorunları ayrı nedenler olarak ele alır. Dolayısıyla bir hata metninden doğrudan suç nitelendirmesine geçilmez. Kullanıcının gördüğü uyarı ile zincirdeki sonuç eşleştirilir.

Honeypot mekanizması nasıl ayırt edilir?

Honeypot, bu bağlamda satın almayı mümkün kılarken satış çıkışını engelleyen veya fiilen anlamsızlaştıran tuzak tokenlar için kullanılır. Sözleşme belirli adreslerin satışını engelleyebilir, sadece seçilmiş adreslere izin verebilir veya çok yüksek satış kesintisi uygulayabilir. Uniswap Labs’ın satılamayan tokenlara ilişkin açıklaması da bu mekanizmaları ve üçüncü taraf tarayıcıların hata yapabileceğini belirtir.

İnceleme, bugünkü ayarlarla sınırlanmamalıdır. Satın alma anında açık olan satış sonradan kapatılmış olabilir; ücret değiştirilmiş veya belirli bir adres listeye eklenmiş olabilir. Böyle bir olayda alışın yapıldığı blok, satış denemelerinin blokları ve aradaki yönetici işlemleri aynı zaman çizelgesinde gösterilir.

Yönetici yetkisi bulunması kendi başına kötü niyet ispatı değildir. Meşru projelerde de erişim ve güvenlik yetkileri bulunabilir. Sorulacak soru, hangi yetkinin kime verildiği ve olayda nasıl kullanıldığıdır. OpenZeppelin’in erişim kontrolü belgeleri, sahiplik ve rol tabanlı yetkilerin farklı yapılar olduğunu gösterir. Bir “owner” alanına bakarak bütün kontrol mekanizmasının çözüldüğü varsayılmamalıdır.

“Sahiplik bırakıldı, sözleşme güvenli” açıklaması yeterli mi?

Hayır. Belirli sahiplik yetkisinin bırakılması, başka rollerin veya sözleşmelerin etkisini ortadan kaldırmış olmayabilir. Yükseltilebilir bir yapıda görünen token adresi aynı kalırken kullanılan uygulama değişebilir. Bu ihtimalin teknik temeli proxy ve yükseltme mimarisidir. Somut tokenın böyle bir yapıya sahip olup olmadığı ayrıca doğrulanır.

Bu yüzden raporda “güvenli” damgası yerine, incelenen sözleşme adresi, ağ, blok, kod sürümü ve yetki kapsamı belirtilir. Bir denetim raporunun başka sözleşmeye ait olması veya satın alma tarihinden önceki sürümü incelemesi önemli olabilir. Denetçi logosu, kodun doğrulanmış görünmesi veya uzun süredir açık bir internet sitesi tek başına satışın her kullanıcı için serbest olduğunun kanıtı değildir.

Honeypot, likidite çekilmesi ve sahte token nasıl ayrılır?

Honeypot öncelikle satışın önündeki kısıtla ilgilidir. Rug pull diye anılan olayda likiditenin çekilmesi veya projenin değerinin kasıtlı biçimde boşaltılması ön plana çıkabilir. Aynı token önce satış kısıtıyla alıcı biriktirip daha sonra likiditesi çekilerek zarara yol açabilir. Bu durumda iki ayrı fiilin tarih ve rolü gösterilmelidir.

Likidite havuzu, takasta kullanılabilecek varlıkların bulunduğu sözleşme yapısıdır. Havuzun küçülmesiyle sizin işleminizin fiyat üzerindeki etkisi büyüyebilir; fiyat etkisi tokenın etiket fiyatıyla elde edilebilecek gerçek karşılığın neden ayrılabildiğini açıklar. Fakat likidite azlığı da tek başına dolandırıcılık iradesini ispat etmez.

Sahte token ise başka bir varlığın adını, sembolünü veya logosunu taklit ediyor olabilir. Bir token hem taklit hem satılamaz olabilir; ancak gerçek bir projeye ait tokenın geçici teknik sorunu da mümkündür. Özellikle USDT gibi tanınan isimlerde sembol yerine ağ ve sözleşme doğrulanmalıdır. Sahte USDT ve bakiye doğrulama bunun ayrı inceleme alanıdır.

Yeni kayıp yaratmadan hangi bilgileri koruyabilirsiniz?

Hatanın nedenini anlamadan satış denemelerini tekrarlamak ücret kaybını artırabilir. İncelenmemiş talimatlarla fiyat kayması sınırını aşırı yükseltmek, yabancı bir sözleşmeye sınırsız izin vermek veya “özel kurtarma” bağlantısında mesaj imzalamak da farklı riskler yaratır. Sırf teşhis amacıyla gerçek varlıklarla tekrar işlem yapmak zorunlu değildir.

  • Doğru ağın adını, token sözleşmesini ve kendi adresinizi tam biçimde kaydedin.
  • Satın alma işleminin TxID’sini, tarihini, kullanılan varlığı ve miktarını saklayın.
  • Başarısız denemeler varsa işlem kimliklerini; yayınlanmamışsa ekrandaki tam hatayı ve kullanılan gerçek URL’yi kaydedin.
  • Satış ve likidite hakkında size sunulan vaatleri, duyuruları, mesajları ve yönlendiren hesabı koruyun.
  • Tarayıcı sonucunu aldıysanız sorgulanan ağ/sözleşme, kontrol tarihi ve rapor kapsamını kaydedin.
  • Yeni bir ücret veya kimlik/anahtar talebi geldiyse önceki alım işlemiyle bağını ayrıca gösterin.

Cüzdanın başka varlıkları da izinsiz hareket ediyorsa olay yalnız satılamayan token sorunu olmayabilir. Token izinlerinin incelenmesi ve iptali ayrıca değerlendirilir. Bir tokena verilen iznin kaldırılması, daha önce o tokenı almak için harcanan varlığı geri getirmez ve tokenın kendi satış kısıtını değiştirmez.

Savunulabilir teknik inceleme hangi bağlantıları kurar?

İnceleme üç kayıt kümesini birleştirir: kullanıcının satın alma ve satış denemeleri; tokenın sözleşme ve likidite durumu; kullanıcıya yapılan açıklamalar. Bunlardan yalnız biriyle yetinmek yanıltabilir. Kodda kısıt görmek, kullanıcının o kısıttan etkilendiğini tek başına kanıtlamaz; kullanıcı şikâyeti de kodun o tarihte nasıl çalıştığını göstermez.

Teknik uzman önce aynı sözleşme ve ağın incelendiğini doğrular. Ardından alışta hangi varlığın ne kadar çıktığını, hangi tokenın ne kadar geldiğini, satış çağrısının hangi sözleşmeye ve yöntemle yöneldiğini belirler. Gerekirse olay tarihindeki duruma dayanan simülasyon veya iz analizi yapılır. Kullanılan yöntem, veri kaynağı, zaman ve sınırları yazılır; bugünkü başarılı simülasyon geçmişteki satışın da mümkün olduğunu otomatik olarak ispat etmez.

Yönetici işlemleri ve likidite hareketleri varsa bunların bağlantısı ayrıca incelenir. Tokenı oluşturan adres, havuzu açan adres, ücret toplayan adres ve proje adına konuşan kişi aynı olmayabilir. Ortak finansman veya zaman yakınlığı bir araştırma hipotezi oluşturabilir; kişi kimliği ve suç ortaklığı için ilave kayıtlar gerekir.

Bir DEX takası doğrudan tek bir saldırgan cüzdanına para gönderilmesi biçiminde görünmeyebilir. Kullanıcının verdiği ETH veya başka varlık önce havuza girebilir; sonrasında ücret, likidite çekimi veya başka işlemle farklı adreslere ulaşabilir. Fon takibi bu geçişleri göstermeli, havuzun bütün bakiyesini tek mağdurun parası gibi yazmamalıdır. Yöntem ayrıntıları kripto adli bilişim ve fon takibi kapsamında ele alınır.

Cüzdanda görünen yüksek değer zarar tutarı sayılır mı?

Her zaman değil. Satılamayan token için ekranda 50.000 dolar değer görünmesi, kullanıcının 50.000 dolar harcadığını veya bu tutarı tahsil edebileceğini göstermez. Fiyatın hangi havuzdan alındığı, likidite derinliği ve satışın mümkün olup olmadığı önemlidir. Hukuki zarar hesabı bir arayüz rakamına indirgenemez.

Başlangıçta şu kalemler ayrı çıkarılır: token satın almak için fiilen verilen varlık; tahakkuk eden işlem ücretleri; aynı olayla ilgili ek ödemeler; gerçekleşmiş satış veya iadeler; elde kalan varlığın durumu. Her tutarın tarihi ve değerlendirme para birimi belirtilir. Alışın havuza girişiyle sonraki likidite çekimini toplayıp iki kez zarar yazmak hatalıdır.

Temsili olayda kullanıcı 1 ETH karşılığında token almış, iki başarısız satış denemesinde ağ ücreti ödemiş ve sonra 0,1 ETH iade almış olsun. Dosyada 1 ETH başlangıç çıkışı, iki ücret ve 0,1 ETH iade ayrı gösterilir. Sonraki token ekranının 10 ETH göstermesi kendiliğinden 10 ETH’lik kesin zarar doğurmaz. Talep edilecek zararın kapsamı ve değerleme tarihi hukuki ilişkinin niteliğine göre ayrıca belirlenir.

Türkiye’de şikâyet ve iade talebi nasıl kurulur?

Hileli açıklamalarla alıma yönlendirme, gizlenen satış kısıtı, faile veya başkasına sağlanan yarar ve mağdur zararı birlikte değerlendirildiğinde dolandırıcılık hükümleri gündeme gelebilir. Bilişim sisteminin araç olarak kullanıldığı olayda nitelikli hâl de araştırılır. Ancak sırf token fiyatının düşmesi veya yazılımın hatalı olması otomatik olarak TCK m.157-158 kapsamındaki suçu kurmaz; kast ve her kişinin fiili delillendirilmelidir.

CMK m.158 uyarınca başsavcılığa veya kolluğa yapılacak başvuruda, bilinmeyen kişilerin adını tahmin etmek yerine bilinen roller ve araştırılacak bağlantılar gösterilir. Proje hesabı, reklamı yapan profil, sözleşme yöneticisi ve fonun son doğrulanan noktası ayrı yazılır. “Bütün adreslere el konulsun” yerine olayla bağlantılı varlık ve kurumlar somutlaştırılır; tedbirin şartlarını yetkili makam değerlendirir.

Özel hukuk bakımından sözleşmesel talep veya şartları varsa TBK m.49 kapsamında haksız fiil tazminatı değerlendirilir. Muhatabın belirlenmesi, fiille zarar arasındaki bağ ve tahsil imkânı önemlidir. Ceza başvurusu yapılması otomatik geri ödeme oluşturmaz; zincirdeki işlemi geri çevirmekle hukuken iade veya tazminat elde etmek farklı süreçlerdir.

DEX veya tokenı tanıtan kişi mutlaka sorumlu mudur?

Hayır; herkesin rolü ayrı incelenir. Protokol, internet arayüzünü işleten şirket, tokenı çıkaran kişiler, likiditeyi yönetenler ve tanıtımı yapan hesaplar birbirine eşitlenmez. Teknik olarak izinsiz token oluşturulabilmesi, belirli bir şirketin o tokenı onayladığını göstermez. Aynı şekilde “merkeziyetsiz” ifadesi de somut kişinin aldatıcı vaadini veya zarar verici davranışını hukuki inceleme dışında bırakmaz.

Tanıtım yapan kişi bakımından paylaşımın içeriği, bilinen veya saklanan menfaat, olayla bağlantı ve alım kararına etkisi araştırılır. Sadece gönderiyi beğenen kişiye, yalnız kod katkısı yapan geliştiriciye veya herhangi bir havuz kullanıcısına otomatik sorumluluk yüklenmez. Yurt dışı bağlantısı varsa uygulanacak hukuk, yetki ve bilgi edinme imkânları ayrıca değerlendirilir.

“Honeypot kilidini ücretle açarım” denilirse

Bir sözleşmenin satış kuralını değiştirmek için gerekli yetki kullanıcıda veya yardım teklif eden kişide bulunmayabilir. Rastgele bir adrese para göndermek teknik yetki yaratmaz. Yeni ödeme karşılığında satışın kesin açılacağı vaadi bu nedenle bağımsız doğrulanmalıdır. Cüzdan kelimeleri, özel anahtar veya anlamı bilinmeyen imza talebi kabul edilmemelidir.

Token tarayıcısının olumlu sonucu da kurtarma garantisi değildir. Bazı kontroller yalnız belirli anı ve işlem koşullarını test eder. Teknik raporun değeri kullanılan aracın adından çok, olay tarihine ait kayıtlarla kurulmuş ve başka kişi tarafından denetlenebilir açıklamasındadır. Satış sorununun sebebi, alımın nasıl teşvik edildiği ve bedelin nereye gittiği birlikte gösterildiğinde hukuki başvuru somut bir inceleme konusuna dönüşür.

Av. Ahmet Karaca · PEGA Hukuk & Danışmanlık · Kripto varlık hukuku ve blockchain adli bilişim.

About the Author

Ahmet Karaca

Avukat Ahmet Karaca, PEGA Hukuk & Danışmanlık bünyesinde özellikle kripto varlık hukuku, bilişim hukuku ve ceza hukuku alanlarında çalışmaktadır.

Kripto P2P işlemleri, kripto varlık hizmet sağlayıcılığı, SPK ve MASAK mevzuatı, banka blokesi, üçüncü kişi ödemesi ve kripto dolandırıcılığı soruşturmaları konularında makaleler yazmakta ve hukuki danışmanlık vermektedir. pegahukuk.com üzerindeki Kripto Varlık Hukuku içerik kümesinin yazarlığını yürütmektedir.

Bunlar da ilginizi çekebilir.