Proxy Contract: Siapa yang Sebenarnya Bisa Mengubah Logic?

Address yang lo lihat belum tentu logic yang berjalan

Proxy contract berguna karena logic aplikasi bisa di-upgrade tanpa memindahkan address dan state. Buat tim, ini praktis. Buat pengguna, ini berarti satu hal penting: kode yang sedang lo baca hari ini bisa bukan kode yang berjalan besok.

Makanya pertanyaan “contract ini verified?” belum cukup. Untuk proxy, pertanyaan yang lebih penting adalah: siapa yang bisa mengganti implementation?

---

Cara kerja sederhananya

Proxy menyimpan state dan menerima call. Ia meneruskan call ke implementation menggunakan delegatecall. Logic dijalankan seolah-olah berada di proxy, tetapi storage yang dipakai adalah storage proxy.

Secara kasar:

wallet -> proxy address -> implementation address
state logic

Kalau implementation diganti, address dan saldo bisa tetap sama, tetapi aturan yang mengontrolnya berubah.

---

Empat address yang harus dibedakan

Proxy address adalah address yang biasa dipakai pengguna.

Implementation address berisi logic yang dipanggil proxy.

Proxy admin biasanya punya hak untuk mengganti implementation atau mengubah konfigurasi upgrade.

Timelock atau multisig adalah lapisan pengendali tambahan. Ini bisa membuat upgrade lebih dapat ditinjau, tetapi bukan berarti otomatis aman.

Jangan menganggap address deployer sebagai satu-satunya pihak penting. Setelah deployment, kekuasaan bisa berpindah ke role atau contract lain.

---

Checklist yang gue pakai

1. Pastikan contract memang proxy, bukan hanya contract biasa dengan fungsi upgrade.
2. Catat implementation address saat ini.
3. Buka source implementation, bukan hanya source proxy.
4. Cari fungsi upgradeTo, upgradeToAndCall, atau pola upgrade lain.
5. Identifikasi admin, owner, atau role yang bisa meng-upgrade.
6. Periksa event upgrade dan riwayat perubahan implementation.
7. Cari timelock, multisig, pause, dan emergency path.
8. Bandingkan storage layout sebelum dan sesudah upgrade.

Upgradeability bukan bug. Banyak protocol membutuhkan perbaikan keamanan. Risikonya muncul ketika upgrade bisa dilakukan oleh satu key tanpa batas waktu, tanpa transparansi, atau tanpa cara pengguna memahami perubahan.

---

Apa arti “renounced ownership” di proxy?

Kalimat ini sering disalahpahami. Owner pada implementation bisa renounced, sementara proxy admin masih punya hak upgrade. Atau kontrak menggunakan admin address berbeda. Selalu periksa jalur upgrade yang benar-benar digunakan oleh proxy.

Kesimpulan gue: immutable address tidak berarti immutable logic. Untuk contract upgradeable, audit harus mencakup mekanisme upgrade dan siapa yang mengendalikannya.

---

Sumber

• OpenZeppelin: Proxy upgrade patterns
• Ethereum: Smart contract security
• EIP-1967: Proxy Storage Slots

*Ditulis setelah sadar bahwa melihat address yang sama tidak berarti melihat logic yang sama.*