Persetujuan token: izin yang terus Anda berikan

Setiap kali Anda berinteraksi dengan aplikasi DeFi — swap di DEX, deposit ke pasar lending, bridging ERC-20 — hampir pasti Anda telah memberikan sebuah persetujuan token. Sebagian besar pengguna menandatanganinya dalam hitungan detik lalu melupakannya. Padahal satu transaksi approve itu adalah salah satu hal paling berdampak yang Anda lakukan di Ethereum: ia menyerahkan kepada sebuah smart contract izin permanen untuk memindahkan token Anda, sering kali tanpa konfirmasi tambahan. Panduan ini menjelaskan apa itu persetujuan token, mengapa dApp memintanya, risiko dari allowance tak terbatas, dan apa arti semua ini ketika Anda menandatangani persetujuan melalui SSP.

Mengapa persetujuan ada

Token ERC-20 tidak disimpan "di dalam" dompet Anda seperti ETH. Sebuah kontrak token ERC-20 adalah buku besar: pemetaan dari alamat ke saldo. Ketika Anda memegang 1.000 USDC, yang benar-benar ada di on-chain adalah sebuah baris di dalam kontrak USDC yang mengatakan alamat Anda memiliki 1.000 unit.

Karena saldo berada di dalam kontrak token, hanya kontrak itu yang bisa memindahkannya. Saat Anda mengirim USDC ke teman, dompet Anda memanggil langsung fungsi transfer dari token tersebut.

Tetapi sebuah DEX, di mana kontrak lain (router) perlu menarik USDC dari alamat Anda untuk mengeksekusi swap, tidak bisa langsung masuk ke kontrak token dan mengambil saldo Anda. ERC-20 menyelesaikan ini dengan pola delegasi dua langkah:

1. Anda memanggil approve(spender, amount) di kontrak token. Ini menetapkan allowance: catatan bahwa spender berwenang memindahkan hingga sebesar amount token Anda.
2. Spender kemudian memanggil transferFrom(yourAddress, destination, amount) di kontrak token. Kontrak memeriksa allowance, menguranginya, dan memindahkan token.

Persetujuan adalah kunci. Tanpanya, router sama sekali tidak bisa menyentuh USDC Anda.

Apa yang sebenarnya Anda berikan

Bacalah approve(spender, amount) secara harfiah. Anda sedang mengatakan kepada kontrak ERC-20: "alamat ini boleh menarik hingga sekian token saya, kapan pun, dalam berapa pun transaksi, sampai saya mengubahnya."

Dari sini muncul beberapa hal:

• Izin permanen, bukan tindakan sekali pakai. Setelah diberikan, spender tidak butuh tanda tangan Anda lagi untuk menarik token sampai allowance habis atau dicabut.
• Per token. Menyetujui router DEX untuk USDC tidak membuatnya bisa menyentuh DAI Anda; Anda perlu persetujuan terpisah untuk DAI.
• Per spender. Kontrak yang berbeda — meski dari dApp yang sama — memiliki allowance-nya sendiri.
• Tidak ada masa berlaku. ERC-20 tidak memiliki tenggat bawaan. Sebuah allowance yang diatur pada 2023 masih aktif di 2026 kecuali sudah terpakai atau dicabut.

Anda bisa memeriksa allowance apa pun di block explorer seperti etherscan dengan membaca fungsi view allowance(owner, spender) dari kontrak token.

Pola allowance tak terbatas

Jika persetujuan bersifat per jumlah, kenapa hampir setiap DEX memintanya dalam angka raksasa — biasanya 2^256 - 1, ditampilkan sebagai "unlimited" atau MaxUint256 — alih-alih hanya sebesar yang sedang Anda swap?

Jawabannya UX dan gas. Jika sebuah DEX meminta allowance baru sebesar ukuran trade setiap kali swap, Anda akan membayar transaksi persetujuan setiap kali dan harus mengkonfirmasi dua transaksi untuk apa yang terasa seperti satu aksi. Meminta allowance tak terbatas sekali membuat Anda kemudian bisa swap bebas dengan satu transaksi per trade.

Memang nyaman secara nyata. Juga benar-benar lebih berisiko. Allowance tak terbatas berarti kontrak spender diizinkan menguras seluruh saldo Anda saat ini untuk token tersebut — dan saldo masa depan apa pun — kapan saja, tanpa Anda menandatangani apa pun lagi.

Untuk kontrak yang sudah dikenal, telah diaudit, dan tidak dapat diubah, risiko praktisnya biasanya rendah. Untuk dApp yang baru saja di-deploy, proxy yang dapat di-upgrade, atau kontrak yang tidak Anda kenal, allowance tak terbatas adalah permukaan yang jauh lebih luas daripada trade yang Anda maksudkan.

Risiko sebenarnya: kunci permanen ke token Anda

Bahayanya bukan pada transaksi persetujuan itu sendiri. Tetapi pada apa yang terjadi sesudahnya. Pertimbangkan beberapa skenario:

• Kontrak spender memiliki bug. Penyerang mengeksploitasi logika transferFrom-nya, dan setiap dompet dengan allowance bukan nol terkuras.
• Kontrak spender bersifat upgradeable. Pemegang kunci upgrade men-deploy logika baru yang menarik token dari siapa pun yang memiliki allowance aktif.
• Anda menyetujui kloning berbahaya. Sebuah situs phishing meniru URL dApp asli, dan kontrak yang Anda setujui sejak awal berada di bawah kendali penyerang.
• Kunci penandatangan spender bocor. Kontrak resminya baik-baik saja; dompet operatornya tidak, dan allowance dijalankan oleh penyusup.

Dalam semua kasus, Anda tidak menandatangani apa pun ketika pengurasan terjadi. Persetujuan yang Anda berikan beberapa minggu sebelumnya adalah satu-satunya otorisasi yang dibutuhkan penyerang. "Setujui hanya yang Anda butuhkan, dan cabut yang sudah tidak Anda pakai" bukan paranoia; ini prinsip yang sama dengan tidak menitipkan kunci cadangan rumah ke setiap tukang yang pernah Anda pekerjakan.

Bagaimana persetujuan diam-diam menumpuk

Sebuah dompet yang aktif satu-dua tahun di DeFi telah menumpuk puluhan persetujuan: setiap DEX, setiap aggregator, setiap deposit ke pasar lending, setiap marketplace NFT, setiap jembatan. Pengguna hampir tidak pernah kembali untuk mencabut. Hasilnya adalah ekor panjang izin permanen, banyak di antaranya tak terbatas, banyak diberikan ke kontrak yang sudah tidak digunakan pengguna lagi.

Itulah permukaan serangan yang senyap. Ia tidak muncul di transaksi tunggal mana pun; ia adalah endapan kumulatif dari pemakaian normal. Mengaudit dan memangkas daftar itu adalah salah satu kebiasaan keamanan paling efektif dalam self-custody — artikel berikutnya menunjukkan caranya tepat di mencabut persetujuan token dari SSP.

Pola yang lebih baru: EIP-2612 permit

ERC-20 mendahului sebagian besar DeFi modern, dan tarian dua transaksi approve-lalu-swap sudah lama dianggap kikuk. EIP-2612 memperkenalkan alternatif untuk token yang ikut serta: alih-alih mengirim transaksi approve di on-chain, pengguna menandatangani pesan off-chain (sebuah permit) yang mengotorisasi spender, jumlah, dan deadline tertentu. dApp lalu mengirim tanda tangan itu bersama swap dalam satu transaksi.

permit hemat gas, terbatas cakupannya (membawa jumlah dan kadaluwarsa eksplisit), dan lebih sulit dibiarkan menggantung karena deadline memaksanya kedaluwarsa. Tidak semua ERC-20 mendukungnya — USDC dan DAI mendukung, banyak token lama tidak — tetapi di mana ia tersedia, biasanya lebih aman daripada allowance approve jangka panjang. Yang itu pun, tanda tangan permit sendiri bisa di-phishing: sebuah situs jahat yang memintanya Anda "login" bisa menyelipkan permit di baliknya. Bacalah apa yang Anda tandatangani.

Apa artinya di dalam SSP

SSP adalah dompet multisig 2-dari-2 self-custodial: setiap transaksi on-chain ditandatangani bersama oleh ekstensi browser SSP dan aplikasi mobile SSP Key. Di Ethereum dan jaringan EVM yang didukung SSP (Polygon, Base, BNB Smart Chain, Avalanche), ini diimplementasikan sebagai smart account ERC-4337 dengan tanda tangan Schnorr teragregasi — tetapi di lapisan aplikasi, sebuah persetujuan terlihat seperti transaksi lain.

Beberapa hal yang perlu diingat:

• Persetujuan adalah transaksi yang harus ditandatangani bersama oleh 2-dari-2 Anda. Saat sebuah dApp meminta approve, SSP menampilkannya seperti tx lainnya. Anda melihat alamat spender dan jumlah yang diminta di kedua perangkat sebelum mengonfirmasi.
• Setelah diberikan, spender tidak butuh SSP lagi untuk bertindak. Multisig melindungi saat persetujuan, bukan izin permanen sesudahnya. Jika Anda memberikan allowance tak terbatas ke kontrak berbahaya, multisig tidak akan menyelamatkan Anda dari penggurasan yang menyusul.
• Perhatikan alamat spender. dApp kadang memperbarui router; jika spender di layar persetujuan tidak cocok dengan kontrak yang Anda harapkan, berhentilah dan verifikasi.
• Persetujuan yang diinisiasi via WalletConnect terlihat sama. Apakah dApp meminta di dalam halamannya atau via WalletConnect, alur dan risikonya identik.

Kebiasaan yang patut dibangun

Beberapa praktik konkret membuat permukaan persetujuan tetap terkelola:

• Pilih allowance terkecil yang masih bisa dipakai. Saat sebuah dApp menawarkan pilihan "jumlah persis" vs "unlimited", yang persis adalah default lebih aman untuk kontrak yang tidak Anda pakai rutin.
• Perlakukan persetujuan tak terbatas sebagai komitmen. Cadangkan untuk sekumpulan kecil kontrak yang Anda percayai dan sering pakai. Untuk lainnya, batasi cakupannya.
• Audit secara berkala. Sekali per kuartal, daftarkan persetujuan aktif Anda di tiap chain dan cabut apa pun yang tidak Anda pakai lagi. Alat seperti revoke.cash membuat ini menjadi rutinitas.
• Berhati-hatilah dengan dApp asing. Protokol baru tanpa rekam jejak audit yang meminta allowance tak terbatas adalah kombinasi paling berisiko di DeFi.
• Lindungi kunci yang memberikan persetujuan. Multisig SSP menaikkan standar, tetapi higiene standar tetap berlaku — lihat praktik terbaik frasa benih.

Model mental untuk dibawa pulang

Persetujuan token bukanlah sebuah klik; ia adalah sebuah kunci. Setiapnya tetap berada di kunci sampai Anda mencabutnya, dan masing-masing memberi pemegangnya kemampuan memindahkan token yang bahkan belum Anda hasilkan. Digunakan dengan hati-hati, allowance adalah pipa-pipa yang membuat DeFi bisa berjalan. Diperlakukan seperti klik sekali pakai, mereka adalah akumulasi risiko yang Anda lupa pernah ambil.

Pahami izin yang Anda berikan, utamakan pemberian dengan cakupan terbatas ketika dApp memperbolehkannya, dan pangkas persetujuan permanen Anda sesuai jadwal. Untuk detail protokol yang lebih dalam, dokumentasi standar ERC-20 di ethereum.org adalah rujukan kanonis. Baru menggunakan SSP di Ethereum? Panduan Ethereum di SSP kami mencakup dasar-dasarnya.