Kripto Token İzinleri ve Harcama Limitleri: İnceleme ve İptal

Bir siteye bağlanmak genellikle uygulamanın herkese açık adresinizi görmesini ve cüzdandan imza istemesini sağlar. Tek başına bağlantı, uygulamaya bütün ERC-20 tokenlarınızı taşıma yetkisi vermez. Token allowance bilgisi token sözleşmesinde ayrı tutulur. MetaMask de dapp bağlantısını kesmekle token izinlerini iptal etmeyi ayrı işlemler olarak ele alır.

Bir ERC-20 allowance; token sözleşmesine, ağa, sahip adresine ve spender adresine bağlıdır. Ethereum'da bir spender'a token kullanma izni vermek, başka bir token veya Polygon'daki aynı token için aynı iznin verildiği anlamına gelmez. Yalnızca “bu siteye izin vermiştim” diye hatırlamak, başka bir token veya ağda hâlâ etkin olan limiti gözden kaçırabilir.

Bu rehber Ethereum ve uyumlu ağlarda ERC-20 approve, allowance ve transferFrom işlemlerine odaklanır. Yerel ETH transferleri, NFT setApprovalForAll izinleri, diğer token standartları ve cüzdanla oturum açma farklı yetki modelleri kullanır. Anahtar yedekleme ve kurtarma ayrı konulardır; cüzdan kurtarma kelimeleri ve kurtarma rehberine bakın.

Token sahibi, belirtilen spender'ın en fazla amount kadar token kullanmasına izin vermek için token sözleşmesinde approve(spender, amount) çağrısı yapabilir. Standart transferFrom işlevi spender'ın tokenları sahibinin adına taşımasını sağlar. Bu nedenle approve işlemi genellikle bakiyeyi tek başına hareket ettirmez; ancak sonraki bir sözleşme çağrısı allowance'ı kullanabilir. Bu akış ERC-20 standardında tanımlanır.

Örneğin cüzdanda 300 token varsa ve bir router'a 80 tokenlık allowance verilmişse, geleneksel bir ERC-20 spender kalan allowance ile sahibin bakiyesinden düşük olan miktarla sınırlıdır. Sözleşme transferFrom'ı birden çok kez çağırabileceğinden izin birden fazla işlemde kullanılabilir. Onaylanan sözleşme veya beklenen çağrı akışı kötüye kullanılırsa tokenlar kullanıcının beklemediği biçimde taşınabilir. Standart dışı token davranışları ve ek kısıtlamalar da önemlidir.

approve genellikle token sözleşmesine gönderilen zincir üstü bir işlemdir ve ağ ücreti gerektirebilir. Bazı uygulamalar izin verme ve takas işlemlerini ayrı işlemler olarak sunar; bazıları imzaya dayalı izni sonraki bir işlemle birleştirir. Düğmede “Approve” yazmasına bakarak tam olarak ne olacağını varsaymayın; cüzdanın imzalamanızı istediği içeriği ve ağı kontrol edin.

Cüzdandaki “Unlimited” etiketi çoğu zaman tokenın en yüksek tam sayı değerine yakın bir allowance anlamına gelir. Onay anında yeni token oluşturmaz veya mevcut bakiyeyi aktarmaz. Ancak spender, aynı ağda daha sonra cüzdana gelecek aynı tokenları da içerecek şekilde bu tokenın allowance'ını kullanabilir. Bazı uygulamalar en yüksek değeri azaltmadan korur; tokenın bu değeri nasıl işlediğini kontrol edin.

Uygulamalar tekrar tekrar izin istememek için geniş limit isteyebilir. Kolaylığı riskle birlikte değerlendirin. Spender sözleşmesinde bir açık varsa veya sözleşmenin kontrolü kötüye kullanılırsa eski izin daha sonra kullanılabilir. Ethereum.org'un izin iptali rehberi, kullanıcılar varlıklarını cüzdana geri taşıdıktan sonra bile geniş allowance'ın neden önemli olabileceğini açıklar.

Daha küçük allowance her riski ortadan kaldırmaz. Sahte tokene veya yanlış spender'a izin vermek yine zarara yol açabilir; sık sık izin vermek ücretleri ve hata fırsatlarını artırabilir. Planlanan miktarı, uygulamayı ne sıklıkta kullanacağınızı, spender'a ne kadar güvendiğinizi ve allowance'ı daha sonra kontrol edip edemeyeceğinizi değerlendirin.

İmzalamadan önce dört bilgiyi kontrol edin. İlk olarak seçili ağın uygulamanın belirttiği ağla eşleştiğinden emin olun. İkinci olarak token sözleşmesi adresini doğrulayın; yalnızca sembole veya logoya güvenmeyin. Üçüncü olarak spender adresini projenin resmî belgeleri veya doğrulanmış sözleşme bilgileriyle karşılaştırın. Son olarak istenen limitin planlanan işlemle uyumlu olup olmadığını ve geniş bir izni açık bırakıp bırakmadığını değerlendirin.

Doğrudan mesaj, QR kod, destek sohbeti veya doğrulanmamış reklam bağlantısıyla cüzdan bağlamayın. Kimlik avı sayfaları gerçek uygulamaları taklit edebilir. Kaydedilmiş resmî adresi veya projenin belgelerini kullanın; ekranda tanıdık bir ad görünmesine bakarak sözleşme adresine güvenmeyin. Blok gezginindeki doğrulama işareti sözleşmenin güvenli olduğunu kanıtlamaz.

Donanım imzalayıcı özel anahtarı normal tarayıcıdan uzakta tutmaya yardımcı olabilir; ancak spender'ın veya izin miktarının güvenli olup olmadığına sizin yerinize karar vermez. Cihaz isteği anlayabileceğiniz biçimde gösteremiyorsa durun ve cüzdan sağlayıcısının resmî açıklamasını inceleyin. Görünen işlem ayrıntıları azsa inceleyebileceğiniz bilgi de azalır.

Bazı ERC-20 tokenları ERC-2612 permit desteği sunar. Sahip, standart approve işlemi göndermek yerine türlendirilmiş veriyi imzalar; başka bir taraf bu imzayı göndererek token allowance'ını ayarlayabilir. Standart ileti sahip, spender, değer, nonce ve deadline bilgilerini içerir; domain alanı imzayı belirli bir ağ ve sözleşmeyle ilişkilendirmeye yardımcı olur.

ERC-2612 deadline, imzalı permit'in gönderilebileceği son zamandır. Başarıyla gönderilmiş permit ile oluşturulan allowance'ın o anda otomatik olarak sona ereceği anlamına gelmez. Allowance kullanılana, değiştirilene veya iptal edilene kadar kalabilir. Bazı tokenlar farklı permit tasarımları veya ek süre kuralları kullanır; cüzdandaki her “permit” isteğinin ERC-2612 olduğunu varsaymayın.

İmza, işlem ücretini başka bir hesabın ödemesini sağlayabilir; bu, her imzanın zararsız bir oturum açma kontrolü olduğu anlamına gelmez. Cüzdan tokenı, spender'ı, miktarı ve ilgili zamanı açıkça göstermiyorsa veya bilgiler uygulamanın açıklamasıyla uyuşmuyorsa imzalamayın ve projenin resmî belgelerine bakın. Henüz gönderilmemiş bir imza, deadline'dan önce başka biri tarafından gönderilebilir.

Oturumu kapatmak veya cüzdan bağlantısını kesmek tarayıcı oturumunu ya da bağlantı iznini değiştirir. Token sözleşmesinde kayıtlı ERC-20 allowance kalabilir. Tersine, allowance'ı iptal etmek sitenin herkese açık adresinizi veya geçmiş zincir üstü işlemleri bilmesini silmez. MetaMask'in dapp bağlantısını kesme rehberi bu ayrımı açıklar.

İptal genellikle o token ve spender için allowance'ı sıfıra ayarlayan zincir üstü bir işlem göndermek demektir. İşlem ağ ücreti gerektirir ve eski izin onaylanana kadar etkin kalabilir. Ardından izin listesini yenileyin veya token sözleşmesini yeniden sorgulayarak aynı cüzdan, ağ, token ve spender için değerin sıfır olduğunu doğrulayın. MetaMask'in izin rehberi ve Ethereum.org ağa özgü kontrol araçlarını açıklar; hangi aracı kullanırsanız kullanın, resmî alan adını ve seçili ağı doğrulayın.

Her ağ kendi durumunu saklar. Ethereum'daki allowance'ı sıfırlamak, başka bir ağdaki aynı tokenın iznini otomatik olarak değiştirmez. İlgili her hesabı, token sözleşmesini, spender'ı ve ağı kontrol edin, ardından işlemin nihai sonucunu doğrulayın. İzin iptal aracı seed phrase veya özel anahtar istememelidir.

Allowance sıfır olarak onaylandıktan sonra spender bu allowance'ı kullanarak yeni bir transferFrom gerçekleştiremez. İptal, tamamlanmış transferleri geri almaz, alıcıdan tokenları geri getirmez veya başka sözleşmelerdeki izinleri silmez. Şüpheli bir izin üzerinden tokenlar zaten taşındıysa allowance'ı sıfırlamak kurtarma yöntemi değildir.

Cüzdanın özel anahtarı açığa çıktıysa saldırgan başka yollarla da işlem imzalayabilir. Diğer spender veya tokenlar için ayrı izinler, NFT operatör yetkileri, permit imzaları ve sözleşmeye özgü yetkiler de kalmış olabilir. Sonucu yalnızca kontrol ettiğiniz tam cüzdan ve ağ için yorumlayın.

İptal edilen spender, bir sonraki takas, yatırma veya kullanma işleminizde yeni bir izin isteyebilir. İptal etmeden önce iznin tamamlanmamış bir işlemde veya açık protokol pozisyonunda kullanılıp kullanılmadığını kontrol edin; gerekirse protokolün resmî yardımına başvurun. Amaç, izin değiştiğinde hangi iş akışının değişeceğini bilmektir.

ERC-20 standardı, sıfır olmayan bir allowance'ı başka bir sıfır olmayan değerle değiştirmeden önce arayüzlerin allowance'ı sıfıra çekmesini önerir. Spender'ın işlemi eski ve yeni onayların arasına sıralanırsa spender kullanıcının beklediğinden fazlasını kullanabilir. Örneğin allowance'ı 100'den 25'e düşürürken spender önce eski 100'ü, ardından yeni 25'i kullanabilir.

Yeni bir miktar belirlemeden önce sıfır allowance'ın onaylanmasını beklemek eski ve yeni değerlerin art arda kullanılma olasılığını azaltır. Ancak sıfır işlemi onaylanmadan önce spender eski allowance'ı kullandıysa bu adım onu geri alamaz. Her iki adım da ücret gerektirebilir ve token davranışı farklılık gösterebilir. Cüzdanın veya tokenın belgelenmiş güvenli güncelleme adımlarını izleyin ve sonraki adımdan önce onay bekleyin.

Mevcut allowance'tan emin değilseniz değiştirmeden önce seçili ağdaki token sözleşmesini sorgulayın. Cüzdan allowance göstermiyorsa veya beklemediğiniz tokenı gösteriyorsa farklı bir ağ ya da adrese bakmadığınızdan emin olun. Sahip adresiyle token sözleşmesi adresi kontrol etmek istediğiniz izinle eşleşmelidir.

1. Projenin resmî alan adını ve seçili ağı doğrulayın.
2. Token sözleşmesini ve spender adresini kontrol edin; allowance'ı planlanan işlem için gereken miktarla karşılaştırın.
3. Cüzdandaki gerçek işlemi veya türlendirilmiş veri isteğini okuyun. Anlamadığınız bir isteği imzalamayın.
4. Artık güvenmediğiniz bir spender'ı kullandıktan sonra ilgili ağdaki allowance'ları kontrol edin; gerektiğinde kullanılmayan izinleri sıfırlayın ve sonucu doğrulayın.
5. Cüzdanları karşılaştırırken desteklenen ağları, izinlerin ne kadar açık gösterildiğini ve güncelleme ile kurtarma rehberlerinin anlaşılır olup olmadığını inceleyin.

Donanım cüzdanı anahtar saklama ve işlem inceleme seçeneklerinden biridir; bir sözleşmenin güvenli olduğunu veya kullanıcının geniş limit vermeyeceğini garanti etmez. İmzalama ekranının sizin yerinize karar vermesini beklemeyin. Spender'ı, tokenı, ağı ve miktarı kendiniz kontrol edin. Token allowance'larının uygulama bağlantılarından bağımsız olarak kalabileceğini anlamak, cüzdan güvenlik özelliklerini ve gerçek sınırlarını karşılaştırmaya da yardımcı olur.