Token Sudah Verified, Tapi Belum Tentu Aman

Verified itu awal pemeriksaan, bukan sertifikat aman

Gue sering lihat orang menulis “contract verified” seolah-olah itu sama dengan “contract aman”. Padahal verified source hanya menjawab satu pertanyaan: kode yang ditampilkan explorer cocok dengan bytecode yang ter-deploy atau tidak?

Itu penting. Tapi masih jauh dari audit keamanan.

Bayangkan lo mendapat source code aplikasi yang bisa dibaca semua orang. Kode itu bisa saja memang sesuai dengan binary yang berjalan, tetapi tetap punya fungsi yang mengizinkan owner mencetak token, membekukan wallet, menaikkan pajak, atau mengganti logic lewat proxy.

---

Yang dibuktikan oleh verified source

Verified source membantu kita:

• membaca fungsi publik dan internal;
• melihat role dan modifier;
• memahami event yang dipancarkan;
• menghubungkan address dengan source tertentu;
• menjalankan static analysis dengan konteks yang lebih baik.

Yang tidak otomatis dibuktikan:

• tidak ada bug logic;
• owner tidak punya kekuasaan berlebihan;
• token bisa dijual;
• liquidity aman;
• proxy tidak bisa di-upgrade;
• tim akan bertindak jujur.

Satu label tidak bisa menjawab semua pertanyaan itu.

---

Lima hal yang gue cek setelah source terbuka

1. Mint dan supply

Cari fungsi seperti mint, increaseSupply, atau role MINTER_ROLE. Catat siapa pemegang role-nya dan apakah ada batas maksimum. totalSupply besar bukan satu-satunya masalah; kemampuan mencetak supply baru juga menentukan risiko dilusi.

2. Transfer restriction

Cari blacklist, isExcluded, tradingEnabled, maxTx, dan maxWallet. Fitur ini bisa punya alasan legitimate, tetapi pengguna perlu tahu siapa yang dapat mengubahnya dan apakah aturan berlaku sama untuk semua address.

3. Tax dan fee

Cari setter seperti setTax, setFees, setBuyTax, atau setSellTax. Pajak yang bisa dinaikkan owner tanpa batas adalah permission penting, bukan detail kecil. Jangan hanya membaca angka saat ini; baca siapa yang bisa mengubah angka itu.

4. Ownership dan role

renounceOwnership tidak otomatis menghapus semua kekuasaan. Kontrak bisa memakai AccessControl, proxy admin, timelock, atau address lain yang memegang role. Periksa event OwnershipTransferred, RoleGranted, dan RoleRevoked di explorer.

5. Proxy dan implementation

Kalau address adalah proxy, source yang terlihat bisa hanya dispatcher. Logic sebenarnya berada di implementation address. Cari siapa yang bisa menjalankan upgrade dan apakah ada timelock atau multisig.

---

Audit bukan jaminan profit

Audit menemukan kelas risiko tertentu pada scope dan commit tertentu. Audit tidak menjamin market, liquidity, frontend, key management, atau perilaku tim. Contract tanpa audit juga belum tentu scam; contract yang diaudit juga belum tentu bebas risiko.

Kesimpulan gue sederhana: verified berarti bisa mulai membaca, bukan berhenti memeriksa.

---

Sumber

• Ethereum: Smart contract security
• OWASP Smart Contract Security Verification Standard
• EIP-1470: Smart Contract Weakness Classification

*Ditulis karena label “verified” sering dipakai seperti stempel halal, padahal baru berarti source-nya cocok dengan bytecode.*