How to Assess Web3 Project Risks: A Practical User Checklist

In Web3, users often hold their own keys and sign transactions directly. A useful review therefore starts not with “How much can I earn?” but with: What am I signing, which code will gain access to my assets, and who can change the rules?

Hiçbir kontrol listesi bir projenin güvenli olduğunu kanıtlayamaz. Amacı bilinmeyenleri ortaya çıkarmak, iddiaları doğrulanabilir kanıtlarla karşılaştırmak ve olası zararı sınırlamaktır.

Bu makale yalnızca eğitim amaçlıdır; finansal, yatırım veya hukuki tavsiye değildir. Web3 işlemleri, aktarılan varlıkların tamamen kaybedilmesine yol açabilir.

1. Kaynağı doğrulayın

  • Kaydedilmiş bir yer imini veya doğrulanmış resmî kanaldan alınan URL'yi kullanın.
  • Alan adındaki her karakteri kontrol edin.
  • Cüzdanınızı reklamlar, istenmeyen mesajlar veya rastgele arama sonuçları üzerinden bağlamayın.
  • Sözleşme adreslerini projenin resmî materyalleri arasında karşılaştırın.
  • Kurtarma ifadesini veya özel anahtarı asla açıklamayın.

Stop signal: a site asks you to “synchronize,” “validate,” or “restore” a wallet by entering secret words.

2. Ağı ve varlığı doğrulayın

Herhangi bir transfer yapmadan önce şunları kaydedin:

  • ağ;
  • token sözleşmesi adresi;
  • alıcı veya çağrılan sözleşme adresi;
  • tutar;
  • ücret varlığı;
  • amaçlanan işlem.

A name such as USDT does not uniquely identify a token. Verify the full token contract address. The same 0x… address format can be used on different EVM networks, but assets and state remain network-specific.

Stop signal: the project gives a ticker but does not publish the network and token address.

3. Dağıtılmış kodu inceleyin

Bir blok gezgininde:

  • resmî adresi kullanarak sözleşmeyi bulun;
  • kaynak doğrulamasını kontrol edin;
  • proxy olup olmadığını belirleyin;
  • güncel uygulamayı açın;
  • tüm adresleri proje belgeleriyle karşılaştırın.

On BscScan, Exact Match means published source and constructor parameters were matched to deployed bytecode. This improves transparency but is not a security assessment.

Stop signal: no address is published, source is unverified, and the project still claims “full transparency” without explanation.

4. İdari yetkileri anlayın

Şu tür rolleri ve işlevleri arayın:

  • owner, admin, operatör ve yükseltici;
  • duraklatma ve devam ettirme;
  • ücret veya limit değişiklikleri;
  • bağlantılı adres değişiklikleri;
  • token basımı;
  • varlık çekimi;
  • uygulama yükseltmeleri;
  • adres engelleme.

Bu anahtarları kimin kontrol ettiğini, çoklu imza kullanılıp kullanılmadığını, değişikliklerde zaman kilidi bulunup bulunmadığını ve kullanıcıların nasıl bilgilendirildiğini sorun. Merkezi kontrol otomatik olarak dolandırıcılık anlamına gelmez; ancak belirli kontrol sahiplerine bağımlılık oluşturur.

Stop signal: one address holds critical powers while the project claims that nobody can change anything.

5. Denetimi doğru okuyun

Şunları kontrol edin:

  • raporun denetçi tarafından yayımlandığını;
  • depo ve commit hash'i belirtilmiştir;
  • canlı sözleşmenin kapsamda olduğunu;
  • raporun güncel uygulamayı kapsadığını;
  • çözülmemiş bulguların devam ettiğini;
  • düzeltmeler yeniden test edildi;
  • önemli bileşenler kapsam dışında bırakıldı.

Denetim ek ve bağımsız bir incelemedir. Her kusuru bulamaz ve web sitesini, anahtar yönetimini, iş modelini veya gelecekteki yükseltmeleri otomatik olarak kapsamaz.

Stop signal: there is an “Audited” badge but no report or reviewed code version.

6. Yardım taleplerini zincir üzerindeki davranışla karşılaştırın

Birkaç işlemde şunları inceleyin:

  • durum;
  • İtibaren ve To / Interacted With;
  • BEP-20 hareketleri;
  • iç çağrılar;
  • loglar;
  • ücretler;
  • bakiyelerdeki ve sözleşme durumundaki değişiklikler.

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Başarı means the code executed without reverting; it does not mean the operation was safe or beneficial.

Stop signal: observable fund flows differ from the stated process and no clear explanation is provided.

7. Varlıkları yükümlülüklerden ayırın

Görünen adres bakiyesi yalnızca tek bir veridir. Şunları sorun:

  • ilgili tüm adresler açıklanmış mı;
  • varlıkları kimin kontrol ettiği;
  • çekilebilirler mi;
  • diğer kullanıcılara karşı hangi yükümlülüklerin bulunduğu;
  • haricî fiyatın nasıl belirlendiği;
  • erişimin köprüye, DEX'e, oracle'a veya karşı tarafa bağlı olup olmadığı.

Yüksek token bakiyesi likiditeyi kanıtlamaz. Çok sayıda birimin gerçekleştirilebilir değeri düşük olabilir.

Stop signal: one address balance is presented as proof of solvency without disclosing obligations or control rights.

8. Ekonomik modeli sade bir dille açıklayın

Şu sorulara net yanıtlar bulun:

  • ödemelerin nereden geldiği;
  • ücretleri kimin ödediği;
  • yeni kullanıcı gelmezse ne olacağı;
  • çıkış koşulları ve kilitlemeler;
  • kayıpların nerede oluşabileceği;
  • yöneticilerin hangi parametreleri değiştirebildiği;
  • tokenin fiyatını neyin belirlediği.

Sonuç piyasalara, yeni katılımcılara, likiditeye veya ekip kararlarına bağlıysa bu bağımlılıklar açıkça belirtilmelidir.

Stop signal: a fixed outcome is promised without a verifiable source of funds or loss scenario.

9. İmzaları ve token harcama izinlerini kontrol edin

Onaylamadan önce cüzdanın gösterdiği bilgileri doğrulayın:

  • ağ;
  • çağrılan adres;
  • işlev veya okunabilir eylem;
  • yerel token değeri;
  • token ve izin tutarı;
  • beklenen varlık değişiklikleri.

An approve call does not immediately transfer a token. It may authorize a spender contract to call transferFrom up to an allowance. An unlimited allowance increases potential loss if the spender is compromised or flawed.

Veriler anlaşılır değilse veya adres kontrol ettiğiniz adresten farklıysa imza isteğini reddedin. Kullanımdan sonra artık gerekmeyen izinleri güvenilir bir araçla inceleyip iptal edin.

Stop signal: you are pressured to sign unreadable data or told that a signature “does nothing.”

10. Zincir dışı riskleri dâhil edin

İyi incelenmiş kod bile aşağıdaki durumların tümünü önleyemez:

  • web sitesi veya DNS'in ele geçirilmesi;
  • kötü amaçlı tarayıcı eklentisi;
  • anahtar hırsızlığı;
  • ele geçirilmiş proje hesabı;
  • arka uç arızası;
  • sosyal mühendislik saldırısı;
  • hukuki kısıtlama;
  • destek veya operasyonel arıza.

Belgeleri, olay müdahale prosedürlerini, bildirim kanallarını ve değişiklik geçmişini kontrol edin. Hukuki iddiaları gerçek belgelere ve kendi yargı bölgenize göre değerlendirin.

11. Olası zararı sınırlayın

İnceleme tamamlandıktan sonra bile:

  • uygulanabilir en küçük test tutarıyla başlayın;
  • tanımadığınız dApp'ler için ayrı cüzdan kullanın;
  • tüm varlıkları bağlı cüzdanda tutmayın;
  • zaman baskısı altında asla imzalamayın;
  • işlem hash'lerini ve adresleri kaydedin;
  • token harcama izinlerini düzenli olarak inceleyin;
  • tamamı kaybedildiğinde yönetilebilir olacak bir azami maruziyet belirleyin.

Solidity'nin resmî güvenlik rehberi, bir sözleşmede tutulan varlık miktarının sınırlandırılmasını önerir: Kodda, derleyicide veya platformda hata varsa maruziyeti sınırlamak kaybı azaltabilir.

İşlem öncesi kontrol listesi

Answer yes, no, or unknown:

  • Alan adını doğruladım.
  • Kesin ağı biliyorum.
  • Token sözleşmesi adresini kontrol ettim.
  • Çağrılan sözleşme adresini kontrol ettim.
  • Kaynak doğrulama durumunu biliyorum.
  • Proxy'yi ve uygulamayı kontrol ettim.
  • Yönetici yetkilerini anlıyorum.
  • Denetim canlı sürümle eşleşir.
  • Gerçek işlemleri inceledim.
  • Ödemelerin kaynağını ve kayıp senaryolarını anlıyorum.
  • İmza isteğini anlıyorum.
  • Harcama izni makul ölçüde sınırlandırılmıştır.
  • Arayüz, anahtar ve hukuki riskleri değerlendirdim.
  • Test tutarı kritik zarara yol açamayacak düzeydedir.

For a critical question, unknown is not a neutral answer—it is an unassessed risk. Pausing for verification is usually cheaper than an irreversible transaction.

Dikkatli bir kullanıcının sorması gereken sorular

Is a project safe if its code is open and audited?
No. Those are useful signals, but unknown bugs and administrative, operational, economic, and external risks remain.

If assets are visible on-chain, can they definitely be returned?
No. Return depends on code, current state, control rights, and external dependencies.

Does a small successful test prove a larger transaction will work?
No. It tests one path at one moment. Limits, liquidity, state, and implementation may later differ.

What if I do not understand the signature?
Reject it. Identify the function, called address, asset changes, and permissions before trying again.


Kaynaklar ve İleri Okuma

  1. Solidity Documentation — Güvenlik Değerlendirmeleri
  2. Ethereum.org — Akıllı Sözleşme Güvenliği
  3. Ethereum.org — Akıllı Sözleşmelerin Test Edilmesi
  4. BscScan Information Center — İşlemleri Görüntüleme
  5. BscScan Information Center — Sözleşme Doğrulama Türleri
  6. BscScan Information Center — Adres Nedir?
  7. OpenZeppelin Docs — Proxy Yükseltme Modeli