---
title: "Risiko tanda tangan Permit2"
description: "Permit2 memisahkan allowance yang dapat digunakan berulang kali dari transfer tanda tangan sekali pakai; penandatanganan yang aman memerlukan verifikasi deployment, domain, spender, penerima, jumlah, nonce, tenggat, witness, dan calldata eksekusi secara tepat."
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.
# Risiko tanda tangan Permit2
> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.
## Jawaban langsung
Permit2 menggabungkan dua sistem otorisasi yang berbeda. `AllowanceTransfer` menyimpan allowance yang dapat digunakan kembali untuk owner-token-spender beserta jumlah, masa berlaku, dan nonce berurutan. `SignatureTransfer` menghabiskan maksimum yang ditandatangani untuk satu kali penggunaan dengan nonce bitmap tak berurutan dan tidak membuat allowance downstream yang persisten. Keduanya tetap bergantung pada allowance ERC-20 dari pemilik token kepada Permit2.
Tanda tangan tanpa gas dapat memindahkan aset ketika spender atau relayer membayar eksekusi. Verifikasi chain yang tepat, kode Permit2 yang diterapkan, domain EIP-712, modul, token, spender, maksimum bertanda tangan, calldata penerima, nonce, dan seluruh tenggat. Kontrak Permit2 yang sah tidak membuat spender, penerima, router, atau witness berbahaya menjadi aman.
## Cara kerjanya
1. Tetapkan `chainId`, jaringan, `verifyingContract` Permit2, runtime code yang diterapkan, alamat dan decimals token, jenis wallet pemilik, serta aplikasi yang dimaksud. Gunakan catatan deployment resmi; alamat atau label yang dikenal tidak cukup.
2. Baca allowance ERC-20 upstream dari pemilik ke Permit2 dan saldonya. Identifikasi approval terbatas atau tak terbatas serta perilaku transfer khusus token; ledger ini tetap ada setelah tanda tangan Permit2 atau allowance downstream tersimpan berakhir.
3. Identifikasi jalur dan primary type yang ditandatangani secara tepat: `PermitSingle` atau `PermitBatch` pada AllowanceTransfer, atau `PermitTransferFrom` maupun varian batch dan witness pada SignatureTransfer. Jangan perlakukan `transferFrom` sebagai signed type.
4. Dekode domain EIP-712 dan setiap entri pesan. Untuk AllowanceTransfer, periksa token, `uint160 amount`, `expiration`, nonce berurutan, spender, dan `sigDeadline`. Untuk SignatureTransfer, periksa token dan jumlah yang diizinkan, nonce tak berurutan, deadline, dan spender yang terikat dari konteks pemanggil.
5. Dekode calldata eksekusi secara terpisah. Dalam SignatureTransfer dasar, `SignatureTransferDetails.to` dan `requestedAmount` adalah parameter eksekusi, bukan field di dalam permit dasar yang ditandatangani; jumlah yang diminta hanya perlu berada dalam maksimum bertanda tangan. Verifikasi setiap indeks batch dan hash witness serta type string yang tepat.
6. Kueri nonce allowance berurutan saat ini atau word dan bit bitmap tak berurutan, lalu simulasikan pemanggil, calldata, chain, dan state yang tepat. Rekonsiliasi penerima, tindakan router, karakteristik token, saldo, serta kedua ledger allowance; simulasi dapat berubah akibat state, pengurutan, atau reorganisasi.
7. Minimalkan jumlah dan masa berlaku. Jika mencurigakan, simpan typed data dan kirim revoke approval upstream, revoke allowance downstream, atau invalidasi nonce yang benar melalui jalur tepercaya sebagai perlombaan mempool; tunggu konfirmasi lalu rekonsiliasi transfer, saldo, allowance, dan bit bitmap.
Pada AllowanceTransfer, `sigDeadline` membatasi kapan permit bertanda tangan boleh menetapkan atau memperbarui otoritas tersimpan; `expiration` membatasi berapa lama otoritas itu dapat digunakan. Deadline SignatureTransfer membatasi eksekusi sekali pakainya. EIP-712 menyediakan hashing bertipe dan pemisahan domain, bukan perlindungan replay atau keamanan intensi; aturan nonce dan deadline Permit2 menyediakan batas tersebut.
Untuk wallet kontrak, validitas ERC-1271 bergantung pada kebijakan `isValidSignature`, modul, threshold, dan kode wallet saat ini. Label wallet, layar hardware wallet yang terpotong, dan simulasi berhasil merupakan masukan bukti, bukan jaminan. Memutus koneksi frontend tidak mencabut approval atau tanda tangan.
## Contoh
- **Dua ledger allowance.** Allowance token terbatas kepada Permit2 bermula pada `1,000 USDC`; sebuah `PermitSingle` menyimpan `600 USDC` untuk spender S. Setelah S mentransfer `225 USDC`, jumlah tersimpan menjadi `600 - 225 = 375 USDC`, sementara allowance token upstream terbatas standar menjadi `1,000 - 225 = 775 USDC`. Berakhir atau dicabutnya 375 tidak otomatis menghapus 775; token nonstandar dapat berbeda.
- **Penerima dan jumlah sekali pakai.** SignatureTransfer menandatangani maksimum `250 USDC`; calldata meminta `180 USDC` kepada merchant. Jika saldo dan allowance upstream mencukupi, eksekusi dapat mentransfer 180. Nonce telah dipakai sehingga sisa `70 USDC` tidak dapat digunakan kembali. Jika calldata menunjuk penyerang sebagai penerima, permit dasar sendiri tidak mencegah pengalihan oleh spender terikat tersebut.
- **Bitmap nonce tak berurutan.** Untuk nonce `513`, nilainya `wordPos = 513 >> 8 = 2`, `bitPos = 513 & 255 = 1`, dan `mask = 1 << 1 = 2`. Eksekusi menetapkan bit 1 pada word 2; replay 513 gagal, sedangkan nonce `512` pada bit 0 tetap independen.
- **Perlombaan pencabutan.** Allowance tersimpan adalah `400 USDC`. Pemilik menyiarkan pencabutan ke nol, tetapi transfer `300 USDC` dieksekusi lebih dulu sehingga tersisa `100 USDC`; pencabutan berikutnya menetapkan sisanya menjadi `0`. Allowance akhir nol tidak membatalkan kerugian terealisasi `300 USDC`, sehingga urutan transaksi dan saldo harus direkonsiliasi.
## Risiko
- ID chain, deployment, atau runtime code yang salah
- Verifying contract palsu atau tidak diharapkan
- Kebingungan antara AllowanceTransfer dan SignatureTransfer
- Spender atau pemanggil berbahaya maupun keliru
- Penerima dipilih melalui calldata eksekusi
- Jumlah yang diminta mendekati maksimum bertanda tangan
- Alamat, simbol, decimals, atau unit mentah token yang salah
- Approval ERC-20 upstream yang persisten atau tak terbatas
- Jumlah downstream atau masa berlaku yang berlebihan
- Kebingungan deadline, sigDeadline, dan expiration
- Nonce berurutan yang usang atau terlibat perlombaan
- Bit bitmap digunakan ulang atau mask invalidasi terlalu luas
- Hash witness atau type string tepat tidak cocok
- Entri batch tersembunyi, duplikat, atau salah indeks
- Tampilan frontend atau calldata berbeda dari intensi
- Revoke kalah dalam perlombaan mempool atau MEV
- Perubahan modul, penanda tangan, threshold, atau upgrade ERC-1271
- Token fee-on-transfer, rebasing, paused, blocked, atau callback
- State simulasi bergeser, gagal, atau mengalami reorganisasi
- Konfirmasi hardware wallet atau pemutusan koneksi disalahartikan sebagai aman
## Kesalahpahaman umum
- **Tanda tangan tanpa permintaan gas tidak dapat memindahkan token.** Pihak lain dapat membayar gas eksekusi.
- **Alamat Permit2 resmi membuktikan spender dan penerima aman.** Permit2 dapat menjalankan otoritas berbahaya dengan tepat.
- **SignatureTransfer dan AllowanceTransfer membuat izin persisten yang sama.** Yang pertama sekali pakai; yang kedua menyimpan allowance yang dapat digunakan berulang kali.
- **Memutus koneksi atau mencabut satu lapisan membatalkan semua jalur dan tanda tangan tertunda.** State upstream, downstream, dan nonce terpisah serta perlombaan tetap ada.
- **EIP-712, hardware wallet, atau simulasi berhasil membuktikan intensi dan finality.** Masing-masing meningkatkan visibilitas atau pengujian, tetapi tidak menggantikan verifikasi field, calldata, dan state terkonfirmasi.
## Topik terkait
- [Tanda tangan bertipe EIP-712](/id/crypto/eip712-typed-signature/)
- [Approval wallet](/id/crypto/wallet-approval/)
- [Tanda tangan wallet](/id/crypto/wallet-signature/)
## Sumber
- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers (diakses: 2026-08-13)
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers (diakses: 2026-08-13)
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers (diakses: 2026-08-13)
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers (diakses: 2026-08-13)
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2 (diakses: 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (diakses: 2026-08-13)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (diakses: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (diakses: 2026-08-13)
Source: https://wiki.fcontext.com/id/crypto/permit2-signature-risk/index.mdx