“Approve” nedir? Bir kere onayladın diye cüzdanda neler değişir?

DeFi’de swap, staking, lending, airdrop claim… hangi dApp’e girsen “Approve” ekranı karşına çıkıyor. Çoğu kullanıcı bu adımı “devam etmek için şart” diye geçiyor; sonra da “approve verdim ne yapmalıyım?”, “approve sonrası hack olur mu?” gibi sorularla panikliyor. Aslında burada olan şey basit bir “onay” değil; token’larını kimlerin, hangi limitlerle ve hangi koşullarda harcayabileceğine dair bir izin.

Bu rehberde “kriptoda approve ne demek?”, “token onayı nedir?”, “token izinleri (allowance) nasıl çalışır?” gibi temel soruları netleştirip işin risk tarafına gireceğiz: unlimited approval (sınırsız izin / unlimited allowance) ne zaman tehlikeli olur, “approve ile sign farkı” nedir, “approve scam” nasıl işler, token izinleri nasıl kontrol edilir ve iptal edilir, “revoke nedir kripto?” gibi pratik konuları adım adım ele alacağız. Yatırım tavsiyesi yok; tamamen güvenlik ve işlem mantığı.

Okumayı bitirdiğinde hedef şu: dApp’e izin vermenin (akıllı sözleşme izni) ne anlama geldiğini anlayacaksın, hangi durumlarda limitli izin vereceğini bileceksin ve cüzdan izinlerini nereden görüp nasıl temizleyeceğine dair bir rutin oluşturacaksın.

1) “Approve” tam olarak ne yapar: token’ı değil, harcama yetkisini tanımlar

ERC-20 token’larda (ve benzeri standartlarda) “approve” işlemi, token’larını doğrudan bir yere göndermek değildir. “Approve”, bir spender (genellikle dApp’in akıllı sözleşmesi) için “senin adına şu token’dan şu kadar harcayabilirsin” demektir. Yani token bakiyen cüzdanında durur; ama belirlediğin izin limitine kadar “transferFrom” mekanizmasıyla harcanabilir hale gelir. Bu yüzden “token onayı nedir?” sorusunun en net cevabı: bakiyeyi değil, harcama iznini ayarlayan bir yetki kaydıdır.

Bu kayıt zincir üstünde saklanır. O yüzden dApp kapanmış olsa bile, o sözleşmeye daha önce verdiğin izin teoride durmaya devam eder. Eğer sözleşmede bir açık oluşursa, ya da sen fark etmeden kötü niyetli bir adrese izin verdiysen, o izin “sahipsiz bir anahtar” gibi bekler. Birçok kullanıcı burada yanılır: “Ben o siteye girmiyorum artık, sorun kalmadı” sanır. Oysa allowance (token izinleri) dediğimiz şey, sen iptal edene kadar veya limit sıfırlanana kadar kalabilir.

Bir benzetme: Approve, kartını kasaya bırakmak değil; “şu mağaza, kartımdan aylık şu limite kadar çekebilir” demek gibi. Limit “unlimited approval” ise, mağazaya pratikte “limit yok” demiş olursun. Bu yüzden “approve verdim” ifadesi çoğu zaman “bir sözleşmeye harcama kapısı açtım” anlamına gelir.

2) Allowance nedir kripto: izin limiti nasıl tutulur ve neden “unlimited allowance” yaygın?

Allowance, bir token için belirli bir spender adresinin harcayabileceği maksimum miktardır. “Token izinleri nedir?” sorusu pratikte “cüzdanımın hangi token’ları hangi sözleşmeler tarafından hangi limitlerle harcanabilir?” sorusudur. Teknik olarak bu, token kontratının içinde tutulan bir tablodur: owner (senin adresin) → spender (izin verdiğin adres) → amount (izin limiti). Bu amount bazen “0”, bazen “100”, bazen de çok büyük bir sayı olur.

“Unlimited approval” (sınırsız izin) genellikle kullanıcı deneyimi için seçilir: dApp, her swap’ta tekrar approve istemesin diye “maksimum” limit ister. Kullanıcı da “bir daha sormasın” diye kabul eder. Burada ince detay: Sınırsız izin, her zaman kötü değildir; ama risk taşıyan yüzey alanını büyütür. İzin verdiğin sözleşme güvenliyse sorun çıkmayabilir; fakat sözleşme güncellenebilir yapıda ise, yönetişim ele geçirilirse, bir entegrasyon hatası olursa ya da sen yanlış adrese onay verdiysen, sınırsız izin “hasar tavanını” yükseltir.

DeFi’de görülen büyük kayıpların bir kısmı, tek seferlik bir “imza/izin zinciri”yle başlar: kullanıcı yanlış yere approve verir, saldırgan daha sonra uygun zamanda allowance’ı kullanıp cüzdandan token çeker. Tek bir olayda kayıpların 6–7 haneli dolar bandına çıktığı örnekler yaşandı; ortak nokta çoğu zaman şu: kullanıcı, “sadece bir onay verdim” sanıyordu ama aslında “harcama yetkisi” veriyordu.

3) Approve ile Sign farkı: gaz ödemesi, zincir kaydı ve risk profili

Yeni başlayanların en çok karıştırdığı konu “approve ile sign farkı”. Basit ayrım: Approve bir işlemdir (transaction); blok zincirine yazılır, genellikle gas ücreti ödersin ve allowance kaydı değişir. Sign ise bir imzadır; çoğu zaman zincire yazılmaz, gas ödemezsin, ama bir mesajı “ben onaylıyorum” diye kriptografik olarak imzalarsın. Bu imzanın kendisi zararsız olabilir; fakat bazı imza türleri, cüzdan kontrolünü kolaylaştıran yetkiler verebilir veya belirli aksiyonlara kapı aralayabilir.

Approve ekranında tipik olarak “Spender: 0x…” ve “Amount” gibi detaylar görürsün. Sign ekranında ise “Sign message” veya “Permit” benzeri ifadeler çıkar. Özellikle bazı protokoller “permit” (EIP-2612 gibi) kullanarak approve’u imzayla birleştirebilir. Bu, kullanıcı deneyimini iyileştirir; ama kullanıcı “gas yok, risk yok” diye düşünüp daha rahat tıklar. Oysa risk, gas ödemekten bağımsız: neye yetki verdiğin belirleyici.

Pratik kural: Approve gördüğünde “token izinleri”ne dokunuyorsun; Sign gördüğünde “kimliğinle” bir mesajı onaylıyorsun. İkisi de masum olabilir; ikisi de suistimal edilebilir. Cüzdan ekranında “Bu işlem token’larına erişim izni verir” benzeri uyarıları ciddiye almak, “onay ver geç” alışkanlığını kırar.

4) Akıllı sözleşme izni nedir: dApp’e izin vermek güvenli mi?

“Akıllı sözleşme izni nedir?” sorusu, DeFi’nin çekirdeğidir. Non-custodial cüzdanlarda (MetaMask, Rabby vb.) varlıklar sende kalır; dApp’in senin yerine işlem yapabilmesi için “yetki” gerekir. Bu yetki genellikle approve ile verilir. dApp’e izin vermek, doğru protokollerle çalışıyorsan işin doğal parçasıdır; fakat güvenliği “site güzel görünüyor” seviyesinde değerlendirmek riskli olur.

Güvenlikte iki ayrı katman var: (1) Arayüz güvenliği (girdiğin site gerçek mi, domain sahte mi, phishing var mı?) ve (2) Sözleşme güvenliği (izin verdiğin spender adresi gerçekten protokolün sözleşmesi mi, güncellenebilir mi, audit geçmişi var mı, bilinen açıklar var mı?). Kullanıcıların büyük kısmı birinci katmana odaklanır; ama izin, ikinci katmanda suistimal edilir. Çünkü allowance, arayüzden bağımsız çalışır: saldırgan aynı spender’ı farklı yerden tetikleyebilir.

İşin can alıcı kısmı: “Bu dApp güvenli mi?” sorusunu tek cümleyle yanıtlamak zor. Daha iyi soru: Ben bu dApp’e ne kadar yetki vermeliyim ve ne kadar süreyle? Limitli approve, ayrı “işlem cüzdanı” kullanımı, düzenli revoke rutini gibi önlemler, dApp’in güvenilirliğinden bağımsız olarak riski düşürür.

5) ERC20 approve nasıl çalışır: transferFrom, spender ve “çekme” mantığı

ERC20 approve mekanizması iki adımdan oluşur: önce approve(spender, amount) ile izin verirsin, sonra spender (veya spender’ı çağıran bir sözleşme) transferFrom(owner, to, amount) ile token’ı çekebilir. Bu “çekme” mantığı, DEX’lerin swap yapabilmesi için şarttır: Uniswap gibi bir router sözleşmesi, senin token’ını alıp havuza verir, karşılığında diğer token’ı sana gönderir.

Buradaki risk, spender’ın “niyeti” değil; spender’ın çağrılabilirliği. Eğer spender adresi gerçekten protokolün router’ıysa, normal koşullarda sadece senin swap isteğinle çalışır. Ama bazı senaryolarda saldırgan, izin verdiğin sözleşmede bir fonksiyon zinciri bulup transferFrom’u tetikleyebilir. Ayrıca bazı phishing senaryolarında spender “router gibi görünen” ama aslında saldırgana ait bir sözleşme olur. Sen approve verince, saldırgan uygun zamanda allowance’ı kullanır.

Önemli bir detay: Bazı token’lar approve güncellemelerinde “önce 0’a çek, sonra yeni limite ayarla” gibi eski güvenlik pratiklerini gerektirebilir. Güncel token’ların çoğu bu sorunları azaltmış olsa da, kullanıcı açısından değişen bir şey yok: allowance her zaman hesaplanabilir ve takip edilebilir bir kayıt; dolayısıyla kontrol edilebilir bir risk.

6) Unlimited approval ne zaman mantıklı, ne zaman gereksiz risk?

Sınırsız izin (unlimited allowance), iki durumda pratik avantaj sağlar: (1) çok sık aynı token’la aynı protokolü kullanıyorsan (ör. stablecoin ile tekrar tekrar swap), (2) gas maliyetleri yüzünden her seferinde approve’a para ödemek istemiyorsan. Özellikle yoğun kullanımda “bir defa approve, sonra rahat” yaklaşımı zaman kazandırır. Fakat bu, güvenlik borcu biriktirir: izinler biriktiğinde cüzdanın “yetki haritası” karmaşıklaşır.

Gereksiz riskin tipik örnekleri: tek seferlik airdrop claim, deneme amaçlı girilen yeni bir dApp, küçük bir swap, kısa süreli kampanya sayfaları. Bu tür işlemlerde “unlimited approval” yerine işlem kadar izin vermek genellikle daha sağlıklıdır. Mesela 150 USDC swap edeceksen, 150–170 bandında (slippage payı gibi) bir limit, hasarı sınırlar. Bu yaklaşım “approve sonrası hack olur mu?” sorusuna da somut cevap verir: hack olursa bile çekilebilecek miktarı sen belirlemiş olursun.

Pratik bir karar kuralı:
- Yüksek frekans + yerleşik protokol → sınırsız izin düşünülebilir, ama düzenli kontrol şart.
- Tek seferlik işlem + yeni/şüpheli arayüz → limitli izin veya ayrı cüzdan.
- Büyük bakiye tutulan token → mümkünse limitli izin + sık revoke.

7) Approve scam nedir: “cüzdanımdan para nasıl çekilir scam” mantığı savunma perspektifiyle

“Approve scam nedir?” sorusu, çoğu zaman “neden token’larım benden habersiz gitti?” sorusuna bağlanır. Saldırganların favori yöntemi, kullanıcıyı yanlış spender’a approve vermeye ikna etmektir. Sen token izinlerini verdiğinde, saldırgan tarafı daha sonra allowance’ı kullanarak transferFrom çağrısıyla token’larını çekebilir. Bu, “cüzdanımdan para nasıl çekilir scam” diye aranan şeyin arka planıdır; burada amaç, kötü niyetli kişilerin yöntemlerini öğretmek değil, hangi işaretleri görüp durman gerektiğini netleştirmektir.

Yaygın senaryolar:
- Sahte airdrop/claim sayfası: “Ödülünü almak için onay ver” der, ama spender saldırgandır.
- Discord/Telegram bot linki: “Resmi duyuru” gibi görünür, domain benzer yazılır.
- Sahte DEX arayüzü: Gerçek protokolün görselini kopyalar; onay verdiğin adres farklıdır. Bu senaryolarda saldırgan çoğu zaman acele ettirir: “kampanya bitiyor”, “son 10 dakika” gibi. Acele, güvenlikte en pahalı duygudur.

Korunma kontrol listesi:

• Domain’i karakter karakter kontrol et: 1 harf farkı en yaygın tuzak.
• Approve ekranında spender adresini sorgula: Tanıdık router mı, yoksa rastgele bir 0x… mi?
• Yeni dApp’lerde küçük bakiye ile test et: Büyük bakiyeyi riske atma.
• “Sadece sign” dense bile temkinli ol: Bazı imzalar da yetki doğurabilir.
• İş bittiğinde revoke yap: Tek seferlik sayfalarda standart refleks olsun.

8) Token izinleri nasıl kontrol edilir: token allowance nasıl kontrol edilir, cüzdan izinleri nereden görülür?

“Token allowance nasıl kontrol edilir?” sorusunun cevabı zincire bakmaktır. Birçok kullanıcı sadece cüzdan uygulamasındaki “aktif bağlantılar” ekranına bakıp rahatlar; ama bu her zaman allowance’ı göstermez. Doğru yaklaşım: kullandığın ağda (Ethereum, Arbitrum, BSC vb.) token onaylarını gösteren “token approval checker” araçlarıyla cüzdan adresini taramak. Bu araçlar, hangi token için hangi spender’a ne kadar izin verdiğini listeler. Bazı cüzdanlar (ör. Rabby gibi) bunu daha görünür hale getirir; MetaMask tarafında ise çoğu zaman dış araçlarla görmek daha kolaydır.

Kontrol ederken şu alanlara odaklan:
- Token adı ve kontrat adresi: Aynı isimli sahte token’lar olabilir.
- Spender adresi: “Router” gibi etiketli mi, yoksa etiketsiz mi?
- Allowance miktarı: 0 mı, limitli mi, yoksa “unlimited” mı? Bir izin “unlimited” ise, o token’ın bakiyesini cüzdanda tutmaya devam etmek, risk yüzeyini büyütür. Bu yüzden büyük bakiyeleri sakladığın cüzdanda izinleri minimal tutmak mantıklıdır.

Pratik ipucu: İzin kontrolünü sadece “hack şüphesi” olduğunda değil, rutin bakım gibi yapmak gerekir. Ayda bir kez 10 dakikalık tarama, yıllar içinde birikmiş onayları temizler. Birçok kullanıcı, ilk taramada onlarca spender görür ve şaşırır; çünkü swap, bridge, staking, NFT mint… hepsi izin bırakır.

9) Token izinleri nasıl iptal edilir: revoke nedir kripto, revoke.cash nedir?

“Revoke nedir kripto?” en pratik tanımıyla allowance’ı sıfırlamak demektir. İptal işlemi (revoke), token kontratında spender için kayıtlı “amount” değerini 0’a çekerek yapılır. Bu da zincir üstü bir işlemdir; yani genellikle gas ödersin. “Revoke.cash nedir?” sorusuna gelince: popüler bir arayüz olarak, farklı ağlarda token izinlerini listeleyip tek tıkla sıfırlamaya yarar. Benzer şekilde bazı explorer’lar ve cüzdan içi araçlar da revoke imkanı sunar.

Revoke yaparken dikkat edilmesi gereken şey şu: İzni iptal etmek, dApp’teki pozisyonunu kapatmak anlamına gelmez. Örneğin bir lending protokolünde borcun varsa, izinleri kapatman bazı işlemleri zorlaştırabilir; ama bu, risk yönetiminde kontrol edilebilir bir tercihtir. Genellikle şu yaklaşım iyi çalışır: aktif kullandığın 1–2 protokol dışında kalan her şeyi temizle, aktif protokollerde ise limitli izin kullan veya periyodik kontrol et.

Revoke adımları, araçtan araca değişse de mantık aynı:

• Cüzdan adresini gir → ağ seç → izin listesine bak.
• Şüpheli veya kullanılmayan spender’ları seç.
• Allowance’ı 0’a çek (revoke) işlemini imzala ve onayla.
• İşlem sonrası tekrar tarayıp izin gerçekten 0 olmuş mu doğrula.

10) “Approve verdim ne yapmalıyım?”: hasar sınırlama ve hızlı kontrol rutini

Yanlışlıkla approve verdiğini düşünüyorsan, paniği işe çevirecek en hızlı plan şöyle: önce izin verdiğin token ve spender adresini tespit et, sonra allowance’ı hemen sıfırla. Burada zamanlama önemlidir; çünkü saldırganlar bazen otomasyonla tarama yapar ve yeni allowance’ları hızlıca sömürmeye çalışır. Yine de “hemen boşalır” gibi bir kesinlik yok; bazı saldırılar fırsat kollayabilir. En doğru refleks, “şüphe varsa revoke”tur.

Hızlı kontrol listesi:

• Hangi ağda işlem yaptın? Ethereum mu, Arbitrum mu, BSC mi? Doğru ağı seçmeden revoke doğru çalışmaz.
• Hangi token? USDT/USDC gibi yaygın token’larda izinler daha değerli hedef olur.
• Allowance unlimited mi? Unlimited ise öncelik en yüksek.
• Cüzdanda büyük bakiye var mı? Varsa geçici olarak başka adrese taşıma düşünülebilir (işlem ücreti ve riskleri hesaba katarak).
• İşlem geçmişinde başka şüpheli imza var mı? Sadece approve değil, farklı izin veren imzalar da olabilir.

Bir adım ileri: Cüzdanını “çalışma cüzdanı” ve “kasa cüzdanı” diye ayırmak bu stresin çoğunu bitirir. Swap ve deneme işleri çalışma cüzdanında, uzun vadeli bakiyeler kasa cüzdanında kalır. Böylece yanlış approve versen bile, “kasa” doğrudan etkilenmez.

11) Risk yönetimi: limitli approve, süreli kullanım ve cüzdan mimarisi

Token izinleri riskini yönetmenin en iyi yolu, “tek hamleyle her şeyi güvenli yapmak” değil; birkaç basit kuralı standartlaştırmaktır. Birincisi limitli approve: İşlem miktarı kadar, biraz pay bırakarak izin vermek. Örneğin 0.5 ETH karşılığı token satacaksan, izin limitini 0.55’e çekmek, “unlimited approval”a göre hasarı dramatik biçimde sınırlar. İkincisi izinleri kısa ömürlü tutmak: işlem biter bitmez revoke yapmak, özellikle tek seferlik airdrop/claim sayfalarında altın kuraldır.

Üçüncü katman cüzdan mimarisi. Non-custodial dünyada güvenlik, “anahtar yönetimi” ve “yetki yönetimi” üzerinden kurulur:

• Kasa cüzdanı: Büyük bakiyeler, minimum izin, nadir işlem.
• DeFi cüzdanı: Günlük kullanım, limitli izin, düzenli revoke.
• Deneme cüzdanı: Yeni dApp’ler, küçük bakiye, sık temizlik.

Bu ayrım, “approve sonrası hack olur mu?” korkusunu “hangi cüzdanda, ne kadar risk aldım?” gibi yönetilebilir bir soruya çevirir.

Dördüncü katman ise işlem disiplini: acele etme, ekranları oku, spender adresini kontrol et, “kampanya bitiyor” baskısına diren. Güvenlik, çoğu zaman teknik değil davranışsal bir problemdir. Kötü niyetli kampanyalar, senin merakını ve FOMO’nu hedefler; disiplinli rutin bu tuzağı bozar.

12) Güvenli rutin: token izinlerini yönet ve kontrolü elinde tut

Bu rehberin ana fikri şu: approve, “devam etmek için tıkla” butonu değil; kalıcı bir izin kaydı. Token izinleri (allowance) biriktikçe cüzdanın saldırı yüzeyi büyür. Bu yüzden en iyi pratik, izinleri aktif bir varlık gibi yönetmek: hangi token’larda unlimited allowance var, hangi spender’lar unutulmuş, hangileri gerçekten gerekli?

Günlük kullanım için uygulanabilir bir rutin:

• Her yeni dApp’te: önce küçük miktarla dene, unlimited verme.
• Her claim/airdrop sonrası: anında revoke yap.
• Haftalık mini bakım: 5 dakika allowance taraması, kullanılmayanları sıfırla.
• Büyük bakiye taşıyorsan: kasa cüzdanında izinleri sıfıra yakın tut.
• Şüpheli bir şey hissedersen: “önce revoke, sonra analiz” yaklaşımını seç.

Bir sonraki adımın net: bugün cüzdan adresini bir token approval checker üzerinden tara, kullanmadığın her spender için allowance’ı 0’a çek ve yalnızca gerçekten düzenli kullandığın protokollere kontrollü izin bırak. Bu tek alışkanlık, “bir kere onayladın diye neler olabilir?” sorusunun riskli kısmını ciddi ölçüde küçültür.

SSS

Approve verdim, cüzdanımdaki tüm coin’ler gider mi?
Approve, sadece belirli bir token için belirli bir spender’a izin verir. Yani “her şey gider” gibi bir kural yok; ama unlimited approval verdiysen ve spender kötü niyetliyse, o token bakiyen hedef olabilir. Bu yüzden hangi token’a, hangi adrese ve ne kadar limit verdiğini kontrol etmek gerekir.

Approve sonrası hack olur mu?
Tek başına approve “hack” değildir; ama yanlış veya sonradan suistimal edilebilecek bir sözleşmeye izin verdiysen, allowance kullanılarak token’ların çekilmesi mümkün hale gelir. Risk, izin verdiğin spender’ın güvenilirliği ve verdiğin limit (unlimited allowance vs limitli) ile doğrudan ilişkilidir.

Approve ile sign farkı nedir, hangisi daha tehlikeli?
Approve zincir üstü işlemdir, allowance kaydını değiştirir ve genellikle gas ödersin. Sign çoğu zaman zincire yazılmaz ve gas ödemezsin; fakat bazı imzalar yetki doğurabilir veya farklı mekanizmaları tetikleyebilir. “Tehlike” gas’a değil, onayladığın içeriğe bağlıdır.

Token izinleri nasıl iptal edilir (revoke)?
Revoke, ilgili token için spender’a verdiğin allowance’ı 0’a çekmektir. Token approval checker araçları üzerinden cüzdanını tarayıp kullanılmayan veya şüpheli izinleri seçerek “revoke” işlemi yapabilirsin. Bu işlem zincir üstüdür ve ağ ücretine tabi olabilir.

revoke.cash nedir, kullanmak zorunda mıyım?
revoke.cash, farklı ağlarda token izinlerini görüntüleyip sıfırlamayı kolaylaştıran bir arayüzdür. Zorunlu değildir; benzer işlevi sunan başka araçlar ve bazı explorer/cüzdan özellikleri de vardır. Önemli olan, hangi aracı kullanırsan kullan, allowance’ları düzenli kontrol edip gereksiz izinleri kapatmaktır.

İç Linkler

• Bitcoin Nedir (2025)
• Halving
• Bitcoin Kaç TL
• Stablecoin
• Altcoin
• İngiltere Kripto Düzenlemesi 2027
• HashKey IPO
• Hot vs Cold Wallet
• Seed Phrase
• Dolandırıcılıklar Sözlüğü