Domain, contract address, function və asset nəticəsinin dörd mərhələli yoxlaması
Düymə mətninə yox, chain, contract, method və parameter-lərə əsaslanın.

Web səhifə request yaradır, wallet onu göstərib imzalayır, smart contract isə chain-də icra edir. Bu üç səviyyədən hər biri ayrıca yoxlanmalıdır.

Front-end və smart contract necə fərqlənir?

Front-end məlumat göstərir və transaction qurur; contract isə wallet-in imzaladığı to, data və value əsasında icra edir.

Saxta sayt real balansı oxuya və orijinal dizaynı kopyalaya bilər. Onun qurduğu transaction hücum edən contract-a gedə bilər.

Rəsmi sayt da compromise ola bilər. Ona görə domain düzgün olsa belə wallet request-də contract address ayrıca yoxlanmalıdır.

Contract address haradan götürülməlidir?

Project-in rəsmi deployment sənədi, verified repository və public governance record bir-biri ilə uyğun olmalıdır.

Eyni protocol müxtəlif network və version üçün başqa address istifadə edir. Köhnə version yalnız exit üçün qala bilər.

Explorer label köməkçi məlumatdır. Verified source code bytecode uyğunluğunu göstərir, gələcək təhlükəsizliyə zəmanət vermir.

Proxy və admin səlahiyyəti niyə vacibdir?

Proxy implementation sonradan dəyişdirilə bilər; admin, multi-signature və timelock gələcək code davranışına təsir edir.

Kim upgrade, pause və parameter change edə bilər sualını cavablandırın. Multi-signature tək key riskini azalda bilər, amma signer-lərin real müstəqilliyini sübut etmir.

Audit report-un version və deployed implementation ilə uyğunluğunu yoxlayın. Logo yerləşdirilməsi audit scope demək deyil.

Wallet request-də hansı sahələr oxunmalıdır?

Network, account, to address, native value, method, token, amount, receiver və deadline sahələri oxunmalıdır.

Gas fee ilə transaction value fərqlidir. “Free mint” səhifəsi native value göndərirsə, wallet bunu ayrıca göstərə bilər.

approve, setApprovalForAll, transfer və deposit fərqli nəticələrdir. Wallet data-nı decode edə bilmirsə kor təsdiq etməyin.

Simulation nəyi göstərə bilər?

O, cari state-də ehtimal olunan balance change, event və revert-i göstərə bilər, lakin domain və admin riskini həll etmir.

Real inclusion zamanı state və transaction sırası dəyişə bilər. Risk tool-un “safe” label-i öz decoder və məlumat bazasına bağlıdır.

Gözlənilməz token transfer, operator approval və receiver görünürsə əməliyyatı dayandırın. Warning-i keçmək üçün slippage-i kor artırmayın.

External dependency hansı risk yaradır?

Oracle, bridge, token, liquidity pool və başqa protocol problemi əsas contract-a ötürülə bilər.

Asset qiyməti, liquidation və withdrawal bir external oracle və ya pool-dan asılı ola bilər. Core contract dəyişməsə də dependency upgrade ola bilər.

Dəstəklənməyən token-i contract-a birbaşa göndərmək normal UI ilə geri çıxmayan balans yarada bilər.

Deposit-dən əvvəl exit yolu niyə oxunmalıdır?

Normal withdrawal, waiting period, pause, emergency exit və front-end unavailable vəziyyətində nə baş verdiyi bilinməlidir.

Share price, debt, liquidity və admin approval çıxışa təsir edə bilər. “Anytime withdraw” mətni contract rule ilə uyğun olmalıdır.

Ən pis halda hansı address-də hansı asset və səlahiyyətin riskdə olduğunu deyə bilmirsinizsə, request-i hələ anlamamısınız.

Kod düzgün işləsə də iqtisadi zərər necə yarana bilər?

Oracle, liquidity, collateral, transaction ordering və incentive dizaynı code bug olmadan da gözlənilməyən nəticə yarada bilər.

Deposit etməzdən əvvəl share necə qiymətləndirilir, liquidation nə ilə başlayır, price source sıradan çıxanda hansı qayda işləyir və aşağı liquidity-də kim əvvəl çıxır suallarını oxuyun. UI-dəki estimate gələcək state üçün zəmanət deyil.

Public mempool-da transaction ordering swap nəticəsinə təsir edə bilər. Slippage və deadline müəyyən sərhəd yaradır, amma yanlış contract, manipulyasiya olunan asset və zəif admin modelini düzəltmir.

Tez-tez verilən suallar

Verified code contract-ı təhlükəsiz edir?

Xeyr. O, source və bytecode uyğunluğunu göstərə bilər; admin, dependency və economic risk qalır.

Simulation success imzalamaq üçün kifayətdir?

Xeyr. Domain, address və permission ayrıca yoxlanmalıdır.

Kiçik test bütün riski çıxarır?

Xeyr. Bəzi risklər məbləğ, vaxt və admin action ilə yaranır.

Front-end işləmirsə birbaşa contract çağırmaq olar?

Texniki olaraq mümkündür, amma ABI və parameter səhvi yüksək risk yaradır.

Rəsmi mənbələr və yoxlama girişləri

Bu stabil texniki anlayışlar üçün mənbələr 2026-08-04 tarixində yoxlanıb. Fee, platforma qaydası, contract ünvanı və sistem statusu əməliyyat anında yenidən yoxlanmalıdır.

  1. Introduction to smart contracts
  2. Smart contract security
  3. Transactions
  4. Ethereum accounts
  5. Gas and fees
  6. ERC-20
  7. EIP-712