Mengapa sebagian persetujuan token harus diatur ke nol terlebih dahulu?

Sebagian token ERC-20 menolak perubahan langsung dari allowance bukan nol ke nilai bukan nol lainnya. Pelajari kapan langkah nol-dahulu diperlukan, mengapa dua transaksi harus dikonfirmasi berurutan, dan risiko yang masih ada.

Hanya untuk tujuan edukasi; bukan nasihat investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Sebagian implementasi ERC-20 menolak approve(spender, newAmount) ketika allowance yang ada dan newAmount sama-sama bukan nol. Untuk token tersebut, kirim dahulu approve(spender, 0), tunggu konfirmasinya, lalu kirim persetujuan baru yang bukan nol.

Batasan ini tidak diwajibkan untuk semua token ERC-20. ERC-20 mendefinisikan approve sebagai penggantian allowance saat ini dan menyarankan antarmuka klien mengaturnya ke nol terlebih dahulu untuk mengurangi race saat persetujuan diubah; standar juga menyatakan kontrak token sebaiknya tidak memaksakannya demi kompatibilitas. Meski demikian, sebagian token yang telah diterapkan memang memaksakannya. Jadi, nol-dahulu merupakan prosedur kompatibilitas sekaligus titik pemeriksaan yang berguna, bukan jaminan bahwa allowance lama tidak dapat digunakan sebelum transaksi pengaturan nol dikonfirmasi.

ID Rantai dan kontrak verifikasi cocok dengan aplikasi yang dimaksudkanFungsi, pembelanja, token, jumlah, nonce, dan tenggat waktu didekodekanSemantik penyisihan dan penggantian yang ada diperiksaPerubahan saldo dan persetujuan disimulasikanPanggilan tak terduga, delegasi, atau transfer nilai menyebabkan penolakan

0 / 5

0 item yang ditinjau; 5 item yang masih belum terselesaikan

Menyelesaikan tinjauan ini tidak membuktikan suatu aset, transaksi, atau sistem aman.

Cara kerja

Verifikasi jaringan, kontrak token, pemilik, spender, dan jumlah yang dimaksud. Baca allowance(owner, spender) dari kontrak token, bukan hanya mengandalkan label dompet.
Jika allowance sudah 0, kirim persetujuan yang diinginkan satu kali. Jika bukan nol, penggantian langsung ke nilai bukan nol lain dapat berhasil pada implementasi standar atau revert pada token yang mewajibkan nol-dahulu.
Untuk alur nol-dahulu, kirim approve(spender, 0) dan tunggu receipt yang berhasil. Lalu baca kembali allowance untuk pasangan pemilik-spender yang sama dan pastikan nilainya 0.
Periksa kembali saldo token, spender, dan tujuannya. Baru setelah itu kirim approve(spender, newAmount) dan tunggu konfirmasi sebelum menganggap allowance baru aktif.
Verifikasi allowance akhir dan tinjau event Transfer serta Approval yang terjadi di antaranya. Receipt yang berhasil membuktikan eksekusi, sedangkan status kontrak saat ini menunjukkan izin yang tersisa.

SafeERC20.forceApprove dari OpenZeppelin menyediakan fallback kompatibilitas bagi kontrak: fungsi ini mencoba nilai yang diinginkan dan, jika panggilan gagal, mencoba 0 lalu nilai yang diinginkan. Utilitas ini mengubah allowance milik kontrak pemanggil. Fungsi tersebut tidak otomatis memperbaiki persetujuan dompet pengguna atau menghilangkan kebutuhan untuk memverifikasi urutan transaksi dan status akhir.

Contoh

Seorang pemilik memberi spender allowance sebesar 1000 token dan ingin menurunkannya menjadi 100. Pada token yang mewajibkan nol-dahulu, approve(spender, 100) mengalami revert sehingga allowance on-chain tetap 1000; panggilan yang revert tidak memperbarui status secara sebagian.

Pemilik kemudian mengirim approve(spender, 0). Sebelum transaksi dikonfirmasi, spender menggunakan 400 sehingga tersisa 600; transaksi pengaturan nol yang kemudian dikonfirmasi mengganti sisanya menjadi 0. Setelah memeriksa saldo token yang berkurang, pemilik dapat memutuskan apakah akan memberi allowance baru sebesar 100. Jika diberikan, spender sudah menggunakan 400 dan kelak dapat menggunakan hingga 100 lagi. Nol-dahulu menampakkan pengeluaran di tengah proses sebelum izin baru diberikan, tetapi tidak membatalkan pengeluaran tersebut.

Risiko

Allowance lama tetap dapat digunakan hingga transaksi pengaturan nol dieksekusi. Spender dapat mendahului pencabutan atau pengurangan yang masih tertunda.
Mengirim transaksi pengaturan nol dan penggantian tanpa menunggu konfirmasi pertama menghapus titik pemeriksaan yang dimaksud dan dapat menyembunyikan pengeluaran di tengah proses.
Jaringan, alamat token, atau alamat spender yang salah dapat membuat atau mencabut izin yang berbeda dari maksud pengguna. Simbol token bukan pengenal unik.
Alur dua langkah memerlukan biaya dua transaksi ketika keduanya dibutuhkan; masing-masing dapat gagal, diganti, atau terus tertunda. Jangan menyimpulkan status hanya dari tanda tangan yang telah dikirim.
Persetujuan tanpa batas serta spender yang dapat ditingkatkan atau telah disusupi dapat mengekspos setoran mendatang. Gunakan jumlah praktis terkecil dan periksa allowance tersisa setelah penggunaan.
Integrasi kontrak harus menangani nilai kembalian serta perilaku persetujuan nonstandar secara sengaja. Wrapper kompatibilitas tidak membuat spender yang tidak tepercaya menjadi aman.

Kesalahpahaman umum

Semua ERC-20 mewajibkan nol-dahulu. Standar menyarankan urutan di sisi klien, tetapi menyatakan kontrak token sebaiknya tidak memaksakannya; hanya sebagian implementasi yang menolak perubahan antara dua nilai bukan nol.
Nol-dahulu sepenuhnya menyelesaikan race persetujuan. Spender masih dapat memakai allowance lama sebelum transaksi pengaturan nol dikonfirmasi.
Penggantian yang revert telah menghapus allowance lama. Revert membatalkan perubahan status yang dicoba, sehingga allowance sebelumnya biasanya tetap ada.
Mengirim kedua transaksi sekaligus sama dengan menunggu. Titik pemeriksaan keamanan berasal dari konfirmasi dan pemeriksaan status nol sebelum memutuskan penggantian.
Memutus koneksi situs web mencabut persetujuannya. Status koneksi dompet dan allowance on-chain dalam kontrak token merupakan hal terpisah.

Topik terkait

Sumber

ERC-20: Standar Token - Ethereum Improvement Proposals (diakses: 2026-08-21)
ERC20 | Dokumentasi OpenZeppelin - OpenZeppelin (diakses: 2026-08-21)
SafeERC20.sol - OpenZeppelin (diakses: 2026-08-21)