---
title: "Mengapa sebagian persetujuan token harus diatur ke nol terlebih dahulu?"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Mengapa sebagian persetujuan token harus diatur ke nol terlebih dahulu?
> 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.
## Cara kerja
1. Verifikasi jaringan, kontrak token, pemilik, spender, dan jumlah yang dimaksud. Baca `allowance(owner, spender)` dari kontrak token, bukan hanya mengandalkan label dompet.
2. 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.
3. 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`.
4. Periksa kembali saldo token, spender, dan tujuannya. Baru setelah itu kirim `approve(spender, newAmount)` dan tunggu konfirmasi sebelum menganggap allowance baru aktif.
5. 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
- [Race persetujuan ERC-20](/id/crypto/erc20-approval-race-condition/)
- [Persetujuan dompet](/id/crypto/wallet-approval/)
- [Nonce dan deadline Permit ERC-2612](/id/crypto/erc2612-permit-nonce-deadline/)
- [Risiko tanda tangan Permit2](/id/crypto/permit2-signature-risk/)
## Sumber
- [ERC-20: Standar Token](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (diakses: 2026-08-21)
- [ERC20 | Dokumentasi OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20) - OpenZeppelin (diakses: 2026-08-21)
- [SafeERC20.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol) - OpenZeppelin (diakses: 2026-08-21)
Source: https://wiki.fcontext.com/id/crypto/token-approval-zero-first/index.mdx