---
title: "Kondisi balapan persetujuan ERC-20"
description: "Pihak pembelanja ERC-20 dapat menggunakan allowance lama sebelum persetujuan penggantinya dikonfirmasi, lalu menggunakan allowance baru. Pelajari cara kerja balapan ini dan cara mengubah atau mencabut persetujuan dengan lebih aman."
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.

# Kondisi balapan persetujuan ERC-20

> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

<a id="answer"></a>

## Jawaban langsung

Kondisi balapan persetujuan ERC-20 dapat terjadi ketika pemilik mengganti satu allowance bukan nol dengan allowance bukan nol lainnya melalui pemanggilan `approve(spender, newAmount)`. Pihak pembelanja dapat melihat perubahan yang masih tertunda, menggunakan allowance lama terlebih dahulu dengan `transferFrom`, lalu menggunakan allowance pengganti setelah perubahan tersebut dikonfirmasi.

Karena itu, spesifikasi ERC-20 menyarankan agar antarmuka klien terlebih dahulu menetapkan allowance ke `0` sebelum menetapkan nilai baru untuk pihak pembelanja yang sama. Setiap transaksi harus dikonfirmasi secara berurutan. Jika suatu token mendukungnya, pemanggilan atomik `increaseAllowance` atau `decreaseAllowance` menghindari penggantian langsung atas allowance bukan nol.

<a id="mechanism"></a>

## Cara kerjanya

ERC-20 mendefinisikan `approve` sebagai penimpaan nilai: `approve(spender, amount)` yang berhasil akan menetapkan allowance pihak pembelanja menjadi `amount`. Secara terpisah, `transferFrom(owner, recipient, amount)` memungkinkan pihak pembelanja tersebut memindahkan token milik pemilik dan biasanya mengurangi allowance yang tersisa. Transaksi yang tertunda tidak menetapkan urutan eksekusi, sehingga pihak pembelanja dapat mengirim transfer yang dieksekusi sebelum perubahan persetujuan milik pemilik.

Transisi yang berisiko adalah `N -> M`, dengan `N > 0` dan `M > 0`. Jika pihak pembelanja menghabiskan `N` sebelum persetujuan pengganti dieksekusi, persetujuan yang dieksekusi kemudian akan memasang allowance baru sebesar `M`. Karena itu, jumlah maksimum yang dibelanjakan dalam rangkaian tersebut dapat mencapai `N + M`, bergantung pada saldo token pemilik dan implementasi token.

<a id="example"></a>

## Contoh

Alice telah menyetujui sebuah protokol untuk membelanjakan `100` token. Ia mengirim `approve(protocol, 50)` dengan tujuan menurunkan allowance yang tersisa menjadi `50`. Sebelum transaksi itu dikonfirmasi, pihak pembelanja protokol mengirim `transferFrom(Alice, recipient, 100)` dan membuatnya dieksekusi lebih dahulu. Persetujuan Alice kemudian menetapkan allowance menjadi `50`, yang dapat digunakan pihak pembelanja dalam transfer lain. Kedua transfer tersebut berjumlah `150` token.

Alur penggantian yang lebih aman adalah `approve(protocol, 0)`, menunggu konfirmasi, memeriksa allowance dan saldo yang dihasilkan, lalu hanya mengirim `approve(protocol, 50)` jika persetujuan baru masih sesuai. Jika pihak pembelanja menggunakan allowance lama sebelum transaksi pengosongan dikonfirmasi, Alice dapat melihat perubahan saldo tersebut dan berhenti sebelum memberikan allowance baru sebesar `50`.

<a id="risks"></a>

## Risiko

- Menetapkan allowance ke `0` tidak membatalkan pembelanjaan yang sudah dieksekusi dan tidak mencegah penggunaan allowance lama sebelum transaksi pengosongan dikonfirmasi.
- Mengirim persetujuan pengosongan dan penggantian secara bersamaan tanpa menunggu konfirmasi pertama akan menimbulkan kembali risiko urutan transaksi.
- `increaseAllowance` dan `decreaseAllowance` bukan bagian dari standar dasar ERC-20; gunakan hanya jika kontrak token terverifikasi mendukungnya.
- Allowance tanpa batas dapat mengekspos seluruh saldo token pemilik selama masih aktif. Verifikasi jaringan, kontrak token, pihak pembelanja, dan jumlah sebelum menandatangani.
- Beberapa token memiliki perilaku persetujuan yang tidak standar. Baca simulasi dompet dan calldata transaksi, lalu konfirmasikan allowance on-chain setelah setiap langkah.

<a id="misconceptions"></a>

## Kesalahpahaman umum

- "Transaksi persetujuan terbaru langsung menggantikan yang lama." Transaksi tersebut baru mengubah status ketika dieksekusi on-chain.
- "Menurunkan allowance membatasi total pembelanjaan mendatang sebesar nilai baru." Pihak pembelanja dapat menggunakan allowance lama sebelum perubahan dieksekusi.
- "Mengosongkan terlebih dahulu menjamin tidak ada lagi token yang dapat keluar." Allowance lama tetap dapat digunakan sampai transaksi pengosongan dikonfirmasi.
- "Setiap ERC-20 memiliki `increaseAllowance` dan `decreaseAllowance`." Keduanya merupakan ekstensi opsional, bukan persyaratan ERC-20.
- "Mencabut koneksi situs web berarti mencabut persetujuan token." Status koneksi dompet dan allowance on-chain dalam kontrak token merupakan hal yang terpisah.

<a id="related"></a>

## Topik terkait

- [Cara membedakan token kanonis dan wrapped](/id/crypto/canonical-vs-wrapped-token/)
- [Mempool](/id/crypto/mempool/)
- [Risiko tanda tangan Permit2](/id/crypto/permit2-signature-risk/)
- [Order reduce-only](/id/crypto/reduce-only-order/)
- [Persetujuan dompet](/id/crypto/wallet-approval/)

<a id="sources"></a>

## Sumber

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (diakses: 2026-08-20)
- [ERC20 | OpenZeppelin Docs](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20) - OpenZeppelin (diakses: 2026-08-20)

Source: https://wiki.fcontext.com/id/crypto/erc20-approval-race-condition/index.mdx