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?

Tidak ada daftar periksa yang dapat membuktikan bahwa suatu proyek aman. Tujuannya adalah mengungkap hal yang belum diketahui, membandingkan pernyataan dengan bukti yang dapat diverifikasi, dan membatasi potensi kerugian.

Artikel ini hanya untuk tujuan edukasi dan bukan nasihat keuangan, investasi, atau hukum. Transaksi Web3 dapat mengakibatkan hilangnya seluruh aset yang ditransfer.

1. Verifikasi kode sumber

• Gunakan bookmark tersimpan atau URL dari saluran resmi yang telah dikonfirmasi.
• Periksa setiap karakter pada nama domain.
• Hindari menghubungkan dompet melalui iklan, pesan yang tidak diminta, atau hasil pencarian acak.
• Bandingkan alamat kontrak di berbagai materi resmi proyek.
• Jangan pernah mengungkapkan seed phrase atau kunci privat.

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

2. Konfirmasikan jaringan dan aset

Sebelum mentransfer apa pun, catat:

• jaringan;
• alamat kontrak token;
• alamat penerima atau kontrak yang dipanggil;
• jumlah;
• aset untuk biaya;
• tindakan yang dimaksud.

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. Periksa kode yang diterapkan

Di penjelajah blok:

• temukan kontrak menggunakan alamat resmi;
• periksa verifikasi kode sumber;
• tentukan apakah alamat tersebut merupakan proxy;
• buka implementasi saat ini;
• bandingkan semua alamat dengan dokumentasi proyek.

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. Pahami kewenangan administratif

Cari peran dan fungsi seperti:

• pemilik, administrator, operator, dan upgrader;
• menjeda dan melanjutkan;
• perubahan biaya atau batas;
• perubahan alamat tertaut;
• pencetakan token;
• penarikan aset;
• peningkatan implementasi;
• pemblokiran alamat.

Tanyakan siapa yang mengendalikan kunci tersebut, apakah multisig digunakan, apakah perubahan dilindungi timelock, dan bagaimana pengguna diberi tahu. Kendali terpusat tidak otomatis berarti penipuan, tetapi menciptakan ketergantungan pada pengendali tertentu.

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

5. Baca audit dengan benar

Periksa apakah:

• laporan diterbitkan oleh auditor;
• repositori dan hash commit dicantumkan;
• kontrak aktif termasuk dalam cakupan;
• laporan mencakup implementasi saat ini;
• masih ada temuan yang belum diselesaikan;
• perbaikan telah diuji ulang;
• komponen penting dikecualikan.

Audit adalah pemeriksaan independen tambahan. Audit tidak dapat menemukan setiap kelemahan dan tidak otomatis mencakup situs web, pengelolaan kunci, model bisnis, atau pembaruan di masa mendatang.

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

6. Bandingkan permintaan bantuan dengan aktivitas on-chain

Periksa beberapa transaksi untuk melihat:

• status;
• Dari dan To / Interacted With;
• pergerakan BEP-20;
• panggilan internal;
• log;
• biaya;
• perubahan saldo dan status kontrak.

Compare the actual path of funds with the published architecture. Do not draw a system-wide conclusion from one demonstration transaction. Keberhasilan 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. Bedakan aset dari kewajiban

Saldo alamat yang terlihat hanyalah satu fakta. Tanyakan:

• apakah semua alamat terkait diungkapkan;
• siapa yang mengendalikan aset;
• apakah aset dapat ditarik;
• kewajiban yang ada kepada pengguna lain;
• cara harga eksternal ditentukan;
• apakah akses bergantung pada bridge, DEX, oracle, atau pihak lawan.

Saldo token yang besar tidak membuktikan adanya likuiditas. Jumlah unit yang besar dapat memiliki nilai riil yang sangat kecil.

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

8. Jelaskan model ekonomi dengan bahasa yang mudah dipahami

Temukan jawaban yang jelas untuk:

• asal setiap pembayaran;
• siapa yang membayar biaya;
• hal yang terjadi jika tidak ada pengguna baru;
• ketentuan keluar dan penguncian;
• tempat kerugian dapat terjadi;
• parameter mana yang dapat diubah administrator;
• faktor yang menggerakkan harga token.

Jika hasil bergantung pada pasar, peserta baru, likuiditas, atau keputusan tim, ketergantungan tersebut harus dinyatakan secara jelas.

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

9. Kendalikan tanda tangan dan izin penggunaan token

Sebelum mengonfirmasi, periksa apa yang ditampilkan dompet:

• jaringan;
• alamat yang dipanggil;
• fungsi atau tindakan yang dapat dibaca;
• nilai token native;
• token dan jumlah allowance;
• perubahan aset yang diharapkan.

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.

Tolak tanda tangan jika datanya tidak jelas atau alamatnya berbeda dari yang telah Anda periksa. Setelah digunakan, tinjau dan cabut izin yang tidak lagi diperlukan melalui alat tepercaya.

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

10. Sertakan risiko off-chain

Bahkan kode yang telah ditinjau dengan baik tidak dapat mencegah semua:

• penyusupan situs web atau DNS;
• ekstensi browser berbahaya;
• pencurian kunci;
• akun proyek yang disusupi;
• kegagalan backend;
• serangan rekayasa sosial;
• pembatasan hukum;
• kegagalan dukungan atau operasional.

Periksa dokumentasi, prosedur insiden, saluran notifikasi, dan riwayat perubahan. Nilai pernyataan hukum berdasarkan dokumen yang sebenarnya dan yurisdiksi Anda sendiri.

11. Batasi potensi kerugian

Bahkan setelah peninjauan selesai:

• mulai dengan jumlah pengujian praktis yang paling kecil;
• gunakan dompet terpisah untuk dApp yang belum dikenal;
• jangan menyimpan seluruh aset di dompet yang terhubung;
• jangan pernah menandatangani dalam tekanan waktu;
• simpan hash dan alamat transaksi;
• tinjau allowance token secara berkala;
• tetapkan batas eksposur maksimum yang masih dapat ditanggung jika seluruhnya hilang.

Panduan keamanan resmi Solidity menyarankan pembatasan jumlah aset yang disimpan dalam kontrak: jika terdapat bug pada kode, compiler, atau platform, membatasi eksposur dapat membatasi kerugian.

Daftar periksa sebelum transaksi

Answer yes, no, or unknown:

• Saya telah memverifikasi domain.
• Saya mengetahui jaringan yang tepat.
• Saya telah memeriksa alamat kontrak token.
• Saya telah memeriksa alamat kontrak yang dipanggil.
• Saya mengetahui status verifikasi kode sumber.
• Saya telah memeriksa proxy dan implementasinya.
• Saya memahami kewenangan administrator.
• Audit sesuai dengan versi aktif.
• Saya telah memeriksa transaksi nyata.
• Saya memahami sumber pembayaran dan skenario kerugian.
• Saya memahami permintaan tanda tangan.
• Allowance dibatasi secara wajar.
• Saya telah mempertimbangkan risiko frontend, kunci, dan hukum.
• Jumlah pengujian tidak dapat menimbulkan kerugian kritis.

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.

Pertanyaan yang perlu diajukan pengguna yang berhati-hati

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.

Sumber dan Bacaan Lebih Lanjut

1. Solidity Documentation — Pertimbangan Keamanan
2. Ethereum.org — Keamanan Smart Contract
3. Ethereum.org — Pengujian Smart Contract
4. BscScan Information Center — Melihat Transaksi
5. BscScan Information Center — Jenis Verifikasi Kontrak
6. BscScan Information Center — Apa Itu Alamat?
7. OpenZeppelin Docs — Pola Peningkatan Proxy