---
title: "การอนุญาตกระเป๋าเงิน"
description: "การอนุญาตกระเป๋าเงินคือสิทธิ์บนเชนที่ให้ spender เรียก transferFrom กับโทเคนของผู้ใช้ อธิบายความต่างจากลายเซ็น การอนุญาตไม่จำกัด และการตรวจสอบหรือเพิกถอน"
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.

# การอนุญาตกระเป๋าเงิน

> เพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้ขาดทุนได้

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

## คำตอบโดยตรง

การอนุญาตกระเป๋าเงินหรือการอนุมัติโทเคนคือ allowance บนเชนจากเจ้าของไปยัง spender หนึ่งราย approve(spender, amount) บันทึกสิทธิ์ ERC-20 และ transferFrom ใช้ได้ภายในยอดเหลือ ไม่ได้ให้คีย์ส่วนตัวหรือโทเคนอื่น การอนุมัติเปลี่ยนสถานะ ส่วนลายเซ็นเข้าสู่ระบบมักอยู่นอกเชน permit ของ ERC-2612 เป็นข้อมูลลงนามที่สร้าง allowance โดยไม่ให้เจ้าของจ่ายแก๊ส แต่ยังเป็นสิทธิ์อนุญาต ETH ไม่ใช้ ERC-20 allowance ตรวจโทเคน spender จำนวน ระยะเวลา และเชน; การเชื่อมเว็บไซต์ไม่ใช่สิทธิ์ใช้จ่าย

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

## วิธีการทำงาน

1. ผู้ใช้ส่ง approve; 0 หมายถึงไม่เหลือสิทธิ์ และค่ามากจะแสดงว่าไม่จำกัด
2. Spender ใช้ transferFrom ภายหลัง สัญญาตรวจยอดและ allowance โอนโทเคน และลด allowance ตามที่ใช้
3. การเปลี่ยน allowance เป็นสถานะบนเชน ค่าบวกสองค่าจะแข่งขันใน mempool ได้ จึงใช้ศูนย์ก่อนหลังยืนยันเมื่อจำเป็น
4. permit ของ ERC-2612 เป็นข้อความลงนาม ตรวจ token, chain ID, nonce, deadline, spender และจำนวน เพราะผู้อื่นส่งได้
5. อนุมัติเฉพาะ spender ที่ตรวจแล้วและจำนวนจำเป็น จำลองการเรียก ตรวจ receipt เหตุการณ์ ยอด และ allowance; เพิกถอนด้วย 0 บนเครือข่ายถูกต้อง และไม่ย้อนการโอนที่ยืนยันแล้ว

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

## ตัวอย่าง

Alice มี 100 USDC และอนุมัติเราเตอร์ที่ตรวจสอบแล้ว 40 ใช้ได้สูงสุด 40 ไม่รวม ETH หรือโทเคนอื่น หลังใช้ 15 เหลือ 25 การอนุมัติไม่จำกัดครอบคลุมเงินฝากอนาคต จึงตรวจสัญญา ใช้จำนวนจำกัด และส่ง approve(router, 0) เมื่อเลิกใช้

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

## ความเสี่ยง

- Spender ที่เป็นอันตรายหรืออัปเกรดใช้โทเคนทั้งหมดได้
- การอนุมัติไม่จำกัดครอบคลุมเงินฝากอนาคต
- เชน สัญญา ที่อยู่ ทศนิยม หรือ calldata ผิดทำให้คำขออันตรายดูปกติ
- การเปลี่ยนหรือเพิกถอนที่ค้างแข่งกับ transferFrom ได้ ศูนย์ที่ยืนยันไม่ย้อนการโอน
- ลายเซ็น permit ส่งภายหลังได้ และตัดการเชื่อมต่อไม่ทำให้เป็นโมฆะ
- โทเคนไม่มาตรฐาน มีค่าธรรมเนียม rebasing หยุด หรือ callback อาจต่างกัน ต้องตรวจสถานะสุดท้าย

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

## ความเข้าใจผิดที่พบบ่อย

- **“เชื่อมกระเป๋าแล้วให้สิทธิ์ใช้เงิน” สิทธิ์เกิดจาก approval, permit หรือธุรกรรมยืนยันแล้ว**
- **“ลายเซ็นไม่แสดงแก๊สปลอดภัย” relayer ส่งภายหลังได้**
- **“ตัดการเชื่อมต่อเพิกถอน approval” สถานะเชื่อมต่อแยกจาก allowance**
- **“ไม่จำกัดคือถอนทั้งหมดทันที” ยังต้องมีการเรียก ยอดพอ และโค้ดเข้ากันได้ แต่ไม่มีขีดจำกัด**
- **“จำลองสำเร็จพิสูจน์ความปลอดภัย” ตรวจเชน calldata ผู้รับ โค้ด receipt และยอดด้วย**

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

## หัวข้อที่เกี่ยวข้อง

- [โทเคน ERC-20](/th/crypto/erc20/)
- [การแข่งขันการอนุมัติ ERC-20](/th/crypto/erc20-approval-race-condition/)
- [Nonce และ deadline ของ ERC-2612](/th/crypto/erc2612-permit-nonce-deadline/)
- [ความเสี่ยงลายเซ็น Permit2](/th/crypto/permit2-signature-risk/)
- [การจำลองธุรกรรม](/th/crypto/transaction-simulation/)

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

## แหล่งที่มา

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-22)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-22)
- [Ethereum security and scam prevention](https://ethereum.org/security/) - Ethereum.org (เข้าถึง: 2026-08-22)

Source: https://wiki.fcontext.com/th/crypto/wallet-approval/index.mdx