Token Onayları, Allowance ve Permit: Gerçekte Neyi İmzalıyorsunuz

Token onayı, bir ERC-20 token sözleşmesinin içinde tutulan zincir üstü bir izindir — bir allowance — ve belirli bir sözleşmenin, sonraki herhangi bir anda, size tekrar sormadan, tokenlarınızın belirli bir miktarına kadarını harcayabileceğini kaydeder. Bir approve() işlemiyle oluşur ve onu verdiğiniz etkileşimden daha uzun yaşar: web sitesi ortadan kaybolabilir, allowance kalır. Permit (EIP-2612) bu ayrı işlemin yerine, dApp'in kendi eylemiyle birlikte gönderdiği zincir dışı bir imza koyar; Permit2 ise aynı süreli ve miktarı sınırlı modeli EIP-2612'yi hiç uygulamamış tokenlara genişletir — yani artık bir imza harcama yetkisi devredebilir, dolayısıyla imza istekleri eskiden onaylara gösterilen dikkati hak eder. Savunma gösterişsizdir: sınırsız yerine sınırlı miktarlar onaylayın ve artık kullanmadığınız allowance'ları iptal edin. WATS gibi tamamen non-custodial bir cüzdanda — anahtarları kullanıcı tutar, WATS asla bir anahtar tutmaz — hiçbir onay, Permit imzası ya da iptal, kendi anahtarınız imzalamadan gerçekleşemez; EVM ağlarında WATS ağ ücretlerini tek bir tokenle, ATS ile aldığı için de oralarda bir temizlik işlemi, o zincirin yerel gas tokeni yok diye asla ertelenmez.

dApp'ler neden onay istiyor

ERC-20 tokenlarının Web3 kullanıcı deneyiminin yarısını şekillendiren bir tuhaflığı vardır: bir akıllı sözleşme, siz istesenizde bile, adresinizden tokenları öylece alamaz. USDC'nizi takas eden bir DEX'in önce açık izninize ihtiyacı vardır. Bu yüzden pek çok etkileşim iki adımlıdır — önce bir approve işlemi, sonra asıl takas ya da yatırma. Onay bir formalite değildir; süregelen bir harcama yetkisidir ve verildiği işlemden daha uzun yaşar.

approve() gerçekte ne verir

Bir onay imzaladığınızda token sözleşmesi bir allowance kaydeder: X adresi (dApp'in sözleşmesi), tokenlarınızın en fazla N kadarını, harcanana, düşürülene ya da iptal edilene dek, dilediği zaman harcayabilir. İki özellik önemlidir. Birincisi, allowance token sözleşmesinde durur ve ziyaret ettiğiniz web sitesine değil, onayladığınız sözleşmeye verilir — arayüz ortadan kalkabilir, izin kalır. İkincisi, harcama anında sizin katılımınız gerekmez: yetki bir kez verildikten sonra onaylı sözleşme, sizden yeni bir imza almadan, sonraki herhangi bir işlemde tokenları çekebilir. Onayları kullanışlı yapan da tam olarak budur — saldırı yüzeyi yapan da.

Sınırsız onaylar: pratik ve kalıcı bir risk

Her onay gas'e mal olduğundan, birçok dApp bir daha onay istememek için fiilen sınırsız bir allowance ister. Kolaylık gerçektir, ama takas da öyle: bir sözleşmeye sınırsız allowance, o tokendeki tüm bakiyenizin sonsuza dek o sözleşmenin güvenliğine bağlı olması demektir. Sözleşme yıllar sonra istismar edilirse — ya da baştan beri kötü niyetliyse — saldırganın anahtarınıza ya da imzanıza ihtiyacı yoktur; verdiğiniz allowance yeterlidir. En büyük cüzdan boşaltma vakalarının birçoğu anahtar hırsızlığı değildi; sadece eski onayların paraya çevrilmesiydi.

Permit ve Permit2: imzayla onay

Modern iyileştirme Permit'tir (EIP-2612): zincir üstü bir approve işlemi yerine, dApp'in kendi eylemiyle birlikte gönderdiği zincir dışı bir mesaj imzalarsınız — iki işlem yerine bir, ayrı onay gas'i yok ve izin bir son kullanma tarihiyle sınırlandırılabilir. Permit2, fikri EIP-2612'yi hiç uygulamamış tokenlara genelleştirir ve ortak bir onay merkezi gibi çalışır: Permit2 sözleşmesinin kendisine bir kez sıradan bir zincir üstü onay verirsiniz, ondan sonra her dApp kendi miktarını ve süresini taşıyan bir imzayla yetkilendirilir. Bu takasta net olmakta fayda var — Permit2 onayları ortadan kaldırmaz, onları tek bir noktada toplar; dolayısıyla Permit2'ye verdiğiniz o süregelen allowance da takip etmeniz gereken bir onaydır. Bunlar gerçek iyileştirmelerdir, ama neyi değiştirdiklerine dikkat edin: eskiden işlemlerin yaptığı işi artık imzalar yapıyor. Sizi yanlış Permit mesajını imzalamaya ikna eden bir oltalama sitesi, kötü niyetli bir onayla aynı sonuca ulaşır — dolayısıyla imzaladığınızı okumak eskisinden daha da önemlidir.

Saldırı yüzeyi: drainer'lar ve bayat allowance'lar

Onay istismarı iki tatta gelir. Aktif: drainer siteleri gerçek dApp'leri taklit eder ve "claim" ya da "cüzdan doğrula" gibi zararsız görünen eylemler kılığında onaylar (veya Permit imzaları) ister. Pasif: yıllar önce meşru sözleşmelere verdiğiniz allowance'lar, sözleşme, yönetici anahtarları ya da yükseltme yolu ele geçirilene dek uykuda bekler. İkisi de bağlan-ve-onayla akışını Web3'ün güvenlik açısından kritik anı olarak görmek için birer nedendir; güvenli yolunu cüzdanınızı bir dApp'e bağlama rehberimizde anlatıyoruz.

Gerçekten işe yarayan onay hijyeni

Üç alışkanlık riskin çoğunu kapatır. dApp izin veriyorsa, özellikle büyük bakiyeler için sınırlı miktarlar onaylayın — sonraki ek onay, ucuz bir sigortadır. Allowance'ları saygın bir onay denetleyicisiyle düzenli inceleyip iptal edin; artık kullanmadığınız her şeyi atılacak ölü ağırlık sayın — iptalin kendisi de allowance'ı sıfıra çeken bir zincir üstü işlemdir, yani gas'e mal olur ve diğer her işlem gibi sizin imzanızı gerektirir. Ve ciddi varlıkları, aktif dApp cüzdanınızdan ayrı, onay imzalamayan bir adreste tutun. Daha katmanlı alışkanlıklar cüzdan güvenliği en iyi uygulamalarımızda. Bir imza isteği göründüğünde, imzalamadan önce türüne göre okuyun:

• Token onayı (approve veya setApprovalForAll): harcayan adresi ve tutarı kontrol edin; tanımadığınız bir harcayana verilen sınırsız tutar bir kırmızı bayraktır.
• EIP-2612 Permit veya Permit2 typed data: harcayanı, tutarı ve son tarihi kontrol edin; tanımadığınız bir harcayanlı ya da uzun son tarihli bir imza, görünür hiçbir işlem olmadan harcama yetkisini devreder.
• EIP-7702 yetkilendirmesi: delege adresini kontrol edin, çünkü onu imzalamak hesabınızın kodunu o sözleşmeye yönlendirir; delegeyi tanımıyorsanız reddedin ve bir EIP-7702 delegasyonunu nasıl kontrol edip iptal edeceğinize bakın.
• Düz personal_sign mesajı: metnin okunabilir olduğundan ve yaptığınız işlemle örtüştüğünden emin olun, örneğin tanıdığınız bir sitenin giriş mesajı gibi, ve zararsız bir doğrulama gibi sunulan okunamaz hex verisine karşı temkinli olun.

WATS bu tabloda nerede

Onaylar imzadır ve imzalar cüzdanın alanıdır. WATS tamamen non-custodial'dir — anahtarlarınızı siz tutarsınız, WATS asla bir anahtar tutmaz — dolayısıyla her onay, Permit imzası ve iptal, yalnızca sizin anahtarınız imzaladığında gerçekleşir; Chrome uzantısından, mobil uygulamadan ya da WATS'tan, Ethereum, BNB Smart Chain, Arbitrum One, Optimism, Base, Polygon, Gnosis, Celo, Mantle, Cronos, Solana ve TON genelinde. Bu aynı zamanda herhangi bir cüzdanın sizin için yapabileceğinin dürüst sınırını da çizer: cüzdan isteği size gösterebilir, ama harcayanın ve miktarın kastettiğiniz şey olduğuna yalnızca siz karar verebilirsiniz.

Ücret tarafı, eski allowance'ları yerinde bırakmanın diğer yaygın bahanesini ortadan kaldırır. WATS'ta, EVM ağlarında onay ve iptal işlemleri dahil her eylem, zincirin yerel gas tokeni yerine tek bir tokenle, ATS ile ücretlendirilir — bir ERC-4337 paymaster aracılığıyla; bu model Chrome uzantısında ve mobil uygulamada aynıdır. Solana ve TON, WATS'ta tam desteklenen zincirlerdir; Solana işlemleri kendi yerel ücretini SOL ile öder, TON'daki ücretler de ATS ile ödenir. Bu bir indirim değildir: ağ hak ettiğini yine alır ve temeldeki maliyet değişmez — değişen, ödemeyi hangi tokenin yaptığıdır. ATS'nin kendisi BSC (BNB Chain) ağında durur; zincir başına ayrı ATS bakiyesi tutmazsın, her EVM ağının ücreti bu tek bakiyeden düşülür. Toplanan ATS yakılır ve arz 100M'den 30M'lik tabana doğru iner. WATS Wallet bu birleşimi sunar.

Yani bu yazının pratik özeti kısa bir rutindir: sınırlı onayları tercih edin, bir Permit imzasının gerçekte neye yetki verdiğini imzalamadan önce okuyun ve üç ayda bir onay denetleyicisi açıp artık kullanmadığınız harcayanları temizleyin. Somut adım, bu rutini sizinle anahtarınızın arasına asla girmeyen bir cüzdandan yürütmektir: WATS'ta, Chrome uzantısında ya da mobil uygulamada her onay ve her iptal, yalnızca kendi anahtarınız imzaladığı için vardır — WATS asla bir anahtar tutmaz — ve EVM ağlarında iptalin bedeli, o zincirin talep ettiği yerel gas tokeni yerine ATS ile ödenir.