On-Chain Transparency: What Blockchain Data Can—and Cannot—Prove

Herkese açık blok zinciri, herkesin bağımsız olarak inceleyebileceği açık bir kayıttır. Bu, ekran görüntülerine, özel kontrol panellerine ve platformun kendi iddialarına bağımlılığı azaltır. Ancak bir projeyle ilgili her soruyu yanıtlamaz.

Transparency is useful only when we separate on-chain facts, interpretations, and information that exists outside the blockchain.

Bu makale yalnızca eğitim amaçlıdır. Açık zincir üstü veriler bir projenin güvenliğini, bütünlüğünü veya getirisini garanti etmez.

"Zincir üstü" ne anlama gelir?

Zincir üstü veriler blokzincir geçmişine veya mevcut durumuna kaydedilir ve bir ağ düğümünden sorgulanabilir. BNB Smart Chain üzerinde şunları içerir:

• işlem hash'i, durumu, bloğu ve zaman damgası;
• sender and recipient addresses;
• aktarılan yerel BNB ve ödenen gas;
• sözleşme çağrısı verileri;
• yürütme sırasında yayımlanan olaylar veya loglar;
• dağıtılmış bytecode;
• açıkça okunabilir sözleşme durumu;
• yerel varlık ve token bakiyeleri;
• işlem ve transfer geçmişi.

Addresses are normally pseudonymous. A string beginning with 0x does not, by itself, reveal the legal identity of its controller.

Zincir üstü verilerin yanıtlamaya yardımcı olabileceği beş soru

1. Belirli bir işlem gerçekleşti mi?

İşlem hash’i; işlemin bir bloğa dâhil edilip edilmediğini, başarılı olup olmadığını, hangi adresin başlattığını, hangi adresin çağrıldığını ve hangi günlüklerin yayımlandığını doğrulamanızı sağlar.

This is stronger evidence than a screenshot. But Başarı confirms technical execution, not the truth of a marketing claim or the economic value of the result.

2. Şu anda bir adreste hangi varlıklar bulunuyor?

An explorer can show native BNB and balances of specific BEP-20 tokens. A standard token balance can also be queried with balanceOf(address).

Görünen bir bakiye otomatik olarak projenin “rezervi” sayılmaz. Böyle bir iddiada bulunmadan önce şunları belirlemek gerekir:

• adresin projeye ait veya proje tarafından kontrol edildiğini;
• ilgili tüm adreslerin açıklandığını;
• varlıkların hâlihazırda başka yükümlülüklere tabi olmadığını;
• tokenlerin kullanılabilir likiditeye sahip olduğunu;
• çekim ve yönetim yetkilerinin anlaşıldığını.

3. Fonlar nasıl hareket etti?

İşlemler, token transferi olayları ve iç çağrılar adresler arasındaki hareketleri izleyebilir. Bunlar platformun yayımladığı süreçle karşılaştırılabilir.

Olay, sözleşme kodunun oluşturduğu bir günlük kaydıdır. Kaydın başarılı bir işlemde oluştuğunu kanıtlar; ancak geliştiricinin seçtiği ad, iddia edilen ekonomik anlamı garanti etmez. Olayları durum değişiklikleri, kod ve gerçek token hareketleriyle birlikte değerlendirin.

4. Hangi kod dağıtıldı?

Deployed bytecode is always public. If source code has been verified, BscScan can match it to the bytecode and expose Sözleşmeyi Oku ve Sözleşme Yaz interfaces.

Kaynak doğrulaması incelenebilirliği artırır. Denetim değildir: Doğrulanmış kod yine de hatalar veya bilerek güçlü tasarlanmış işlevler içerebilir.

5. Parametreleri kim değiştirebilir?

Kaynak kod ve okuma işlevleri owner, admin, operatör, duraklatıcı veya yükseltici gibi rolleri gösterebilir. Bu rollerin şunları yapıp yapamadığını kontrol edin:

• işlemleri duraklatmak;
• ücretleri veya limitleri değiştirmek;
• token basmak;
• varlıkları transfer etmek;
• proxy uygulamasını değiştirmek;
• yeni roller vermek.

İdari bir rol kötüye kullanımın kanıtı değildir. Kullanıcıların anlaması gereken bir güven bağımlılığıdır.

Zincir dışında kalanlar

Bir blok zinciri genellikle şu hususları doğrudan belirleyemez:

• ekibin kimliği ve hukuki statüsü;
• zincir dışı sözleşmeler veya yükümlülükler;
• müşteri desteği kalitesi;
• web sitelerinin, DNS'in, sunucuların veya ekip cihazlarının güvenliği;
• pazarlama ifadelerinin doğruluğu;
• haricî token fiyatının kaynağı ve güvenilirliği;
• gerçek dünya varlıklarının mülkiyeti;
• gelecekteki yönetici kararları;
• kullanıcının yargı bölgesindeki hukuki uyumluluk.

Bir blok gezgininde gösterilen bazı bilgiler zincir dışıdır: Adlar, logolar, web siteleri, sahiplik etiketleri ve fiyat grafikleri gönderilmiş üst verilerden veya haricî sağlayıcılardan gelebilir. BscScan de token sayfalarının hem zincir üstü hem zincir dışı bilgiler içerdiğini belirtir. Kritik kontrolleri görsel markaya değil, tam adreslere ve ham kayıtlara dayandırın.

Gözlem, yorum ve varsayım

Bu seviyeleri birbirinden ayırın:

Observation:
“In block N, address A sent 100 units of token T to address B.”

Interpretation:
“According to the published architecture, B is the distribution contract.”

Assumption:
“Therefore every participant will certainly receive a future payment.”

İlk ifade doğrudan zincir üzerinde kontrol edilebilir. İkinci ifade, bir adresi role bağlayan belge ve kod gerektirir. Üçüncü ifade geleceğe ilişkindir ve geçmiş işlemden çıkarılamaz.

Uygulamalı şeffaflık incelemesi

Adım 1: Kesin adresleri belirleyin

Resmî belgelerden aşağıdakilerin ağını ve adreslerini alın:

• ana sözleşme;
• kullanılıyorsa proxy ve uygulama sözleşmeleri;
• ilgili token;
• açıklanmışsa Treasury ve destekleyici bileşenler.

Tam adresleri saklayın. Adlar ve kısaltılmış dizeler yeterli değildir.

Adım 2: Kodu inceleyin

On BscScan’s Sözleşme tab:

• doğrulama türünü not edin;
• sözleşmenin proxy olup olmadığını kontrol edin;
• güncel uygulamayı izleyin;
• rolleri ve parametre değiştiren işlevleri belirleyin;
• derleyici ve dağıtım bilgilerini not edin.

Kaynak kod doğrulanmamışsa sıradan bir kullanıcının davranışı inceleme imkânı önemli ölçüde azalır.

Adım 3: Mevcut durumu okuyun

Kullan Sözleşmeyi Oku for read-only queries such as:

• owner ve rol adresleri;
• duraklatma durumu;
• güncel ücretler ve limitler;
• sayaçlar ve döngü durumları;
• bağlantılı sözleşme adresleri.

Okuma işlemi imza veya gas gerektirmez. Yalnızca açık durumu incelemek için cüzdan bağlamaya gerek yoktur.

Adım 4: Birden fazla işlemi karşılaştırın

Farklı senaryolarda şunları inceleyin:

• çağrılan işlev ve parametreler;
• token hareketleri;
• iç çağrılar;
• loglar;
• önceki ve sonraki durum.

Tek bir işlem yalnızca bir yürütme yolunu gösterir; olası tüm davranışları değil.

Adım 5: Değişiklik geçmişini inceleyin

Şunlarla ilgili yönetim işlemlerini ve olaylarını arayın:

• sahiplik transferleri;
• rol verme ve iptalleri;
• duraklatmalar;
• uygulama yükseltmeleri;
• parametre değişiklikleri;
• varlık çekimleri.

Mevcut yapılandırma önemlidir; geçmiş, yetkilerin gerçekte nasıl kullanıldığını gösterir.

Yaygın hatalar

“The address is public, so its owner is known.”
No. Ownership requires separate evidence.

“Funds are visible in a contract, so they are permanently locked.”
No. Code or an administrator may allow them to move.

“The source is verified, so the contract is safe.”
No. Verification matches source to bytecode; it does not assess security.

“An event is named RewardPaid, so returns are guaranteed.”
No. Developers choose event names. Verify actual state and asset movements.

“Transparency removes risk.”
No. It makes some risks observable while technical, administrative, market, and legal risks remain.

Kontrol listesi

• Kesin ağ ve adresler yayımlanır.
• Kaynak doğrulama türü bilinmektedir.
• Proxy ve güncel uygulama kontrol edilmiştir.
• Owner, admin ve yükseltici yetkileri anlaşılmıştır.
• Bakiyeler tam token adresleri kullanılarak kontrol edilir.
• İşlem geçmişi yayımlanan süreçle tutarlıdır.
• Zincir üstü gerçekler etiketlerden ve yorumlardan ayrılır.
• Blokzincirin yanıtlayamayacağı sorular ayrıca listelenmiştir.

Kaynaklar ve İleri Okuma

1. BscScan Information Center — İşlemleri Görüntüleme
2. BscScan Information Center — Token Sayfasını Anlamak
3. BscScan Information Center — Sözleşme Doğrulama Türleri
4. BscScan Information Center — Adres Nedir?
5. Solidity Documentation — Güvenlik Değerlendirmeleri
6. OpenZeppelin Docs — Proxy Yükseltme Modeli