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

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

สำหรับโทเค็น ERC-20 ฟังก์ชัน `decimals()` คือข้อมูลเมตาที่ไม่บังคับ ซึ่งบอกอินเทอร์เฟซว่าจะแสดงหน่วยโทเค็นจำนวนเต็มอย่างไร หากคืนค่า `d` จำนวนที่แสดงตามธรรมเนียมคือ `raw / 10^d` ค่านี้ไม่เปลี่ยนการคำนวณของสัญญาและไม่รับรองตัวตนโทเค็น ก่อนเชื่อผลลัพธ์ ให้ตรวจสอบเชน ที่อยู่สัญญาที่แน่นอน โค้ดหรือ implementation ของ proxy และบล็อก

อ่าน `decimals()` โดยตรงผ่าน RPC อิสระที่บล็อกที่ระบุ ถอดรหัสผล ABI เป็น `uint8` แล้วเทียบกับทะเบียนสัญญาทางการของผู้ออกและ explorer ที่เชื่อถือได้ จากนั้นทดสอบสเกลกับค่า `balanceOf` ดิบ การโอน การอนุมัติ receipt และ event อย่าสมมติ `18` โดยอัตโนมัติเมื่อไม่มีฟังก์ชัน การเรียก revert ข้อมูลผิดรูป หรือขัดกับหลักฐานอื่น

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

## กลไกการทำงาน

ERC-20 จัดเก็บและโอนจำนวนเป็นเลขจำนวนเต็มไม่มีเครื่องหมาย ชั้นแสดงผลเป็นผู้ใส่จุดทศนิยม ส่วนสัญญายังรับเลขจำนวนเต็ม แปลงอินพุตด้วยสตริงทศนิยมหรือจำนวนเต็มความแม่นยำไม่จำกัด ห้ามใช้ floating-point ฐานสอง จำนวนจะใช้ได้ก็ต่อเมื่อคูณด้วย `10^d` แล้วได้จำนวนเต็ม

เนื่องจาก `decimals()` ไม่บังคับ โทเค็นที่เป็นไปตามมาตรฐานอาจไม่มีฟังก์ชันนี้ implementation แบบกำหนดเองหรืออัปเกรดได้อาจคืนค่าที่ไม่คาดคิดหรือเปลี่ยนหลังอัปเกรด สำหรับ proxy ERC-1967 ให้ตรวจที่อยู่ proxy, implementation หรือ beacon, ผู้ดูแล และ event การอัปเกรด อ่านสถานะโทเค็นที่ที่อยู่ proxy และตรึงการเปรียบเทียบทั้งหมดไว้ที่บล็อกเดียวกัน

Allowance และค่า ERC-2612 `permit` ก็เป็นจำนวนเต็มดิบเช่นกัน การแสดงผลการโอนถูกต้องไม่ได้พิสูจน์ว่าการอนุมัติ ค่าต่ำสุดของ router จำนวนบริดจ์ หรือฐานข้อมูลบัญชีใช้สเกลเดียวกัน สัญญาต้นทางและปลายทางของบริดจ์อาจมี decimals ต่างกัน จึงต้องเทียบมูลค่าที่อ่านได้และหน่วยดิบทั้งสองด้านตามกฎการแปลงและปัดเศษที่ระบุไว้

ใช้ขั้นตอนต่อไปนี้:

1. ตรึง chain ID หรือ domain, สัญญาโทเค็น, เลขบล็อก, endpoint RPC และเวลาที่สังเกต
2. ยืนยันที่อยู่จากทะเบียนทางการของผู้ออก อย่าถือว่าชื่อ สัญลักษณ์ ไอคอน หรือผลค้นหาเป็นหลักฐานที่เชื่อถือได้
3. ตรวจโค้ดที่ deploy และดูว่าที่อยู่เป็น proxy หรือไม่ บันทึก implementation หรือ beacon, ผู้ดูแล และการอัปเกรดล่าสุด
4. เรียก `decimals()` ถอดรหัส `uint8` ตาม ABI และบันทึกผลสำเร็จ revert ค่าว่าง หรือผลผิดรูป โดยไม่แทนด้วยค่าเริ่มต้น
5. อ่าน `balanceOf`, `totalSupply`, allowance, calldata ธุรกรรม, receipt และ event แบบดิบที่บล็อกสอดคล้องกัน แล้วจัดรูปแบบด้วยสเกลที่พบ
6. คำนวณการโอน การอนุมัติ ราคาเสนอ และบริดจ์ใหม่ด้วยจำนวนเต็ม รวมค่าธรรมเนียม การปัดเศษ เศษคงเหลือ rebase หรือภาษีการโอน
7. จำลองและส่งธุรกรรมขนาดเล็ก แล้วกระทบยอดดิบก่อนและหลัง หยุดหากอินเทอร์เฟซ RPC event หรือยอดคงเหลือไม่ตรงกัน

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

## ตัวอย่าง

- **ค่าดิบเดียว สองสเกล** เมื่อ `raw = 123456789`, `d = 6` แสดง `123.456789` ส่วน `d = 18` แสดง `0.000000000123456789` ต่างกันเป็น `10^12` เท่า
- **ต้องคำนึงถึงค่าที่แทนได้** เมื่อ `d = 6`, `1.25` โทเค็นเป็นหน่วยดิบ `1250000` ส่วน `0.0000001` โทเค็นเล็กกว่าหนึ่งหน่วยดิบ จึงต้องปฏิเสธหรือปัดตามกฎที่ระบุชัด
- **สเกลการอนุมัติผิด** allowance `100` โทเค็นเมื่อ `d = 6` คือ `100000000` หากเข้ารหัสด้วย `d = 18` จะเป็น `100000000000000000000` หรือมากกว่าที่ตั้งใจ `10^12` เท่า
- **ปรับสเกลผ่านบริดจ์** หากเส้นทาง `1:1` ที่มีเอกสารแปลงโทเค็นต้นทาง `d = 6` เป็นตัวแทนปลายทาง `d = 18` ค่าดิบ `2500000` แทน `2.5` โทเค็น และค่าปลายทาง `2500000000000000000` ก็แทน `2.5` ยังต้องตรวจค่าธรรมเนียม เพดาน เศษ และยอดรับจริง

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

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

- สอบถามที่อยู่ถูกต้องบนเชนที่ผิด
- ชื่อ สัญลักษณ์ หรือไอคอนที่ลอกมาซ่อนสัญญาอื่น
- implementation ของ proxy หรือ beacon เปลี่ยนหลังการตรวจ
- RPC หรือ explorer ให้สถานะเก่า ยังไม่ final หรือไม่สอดคล้อง
- ข้อมูลเมตาที่หายหรือผิดรูปถูกแทนด้วย `18` โดยไม่แจ้ง
- floating-point ฐานสองปัดจำนวนมากหรือจำนวนละเอียด
- กระเป๋าจัดรูปแบบการโอนถูก แต่จัด allowance หรือ permit ผิด
- ฐานข้อมูลปะปนหน่วยดิบกับจำนวนที่คนอ่าน
- บริดจ์สมมติ decimals เท่ากันหรือไม่เปิดเผยการปัดเศษ
- fee-on-transfer, rebase, mint, burn, pause หรือ freeze ทำให้กระทบยอดแบบง่ายไม่ได้
- calldata, event, receipt และการเปลี่ยนยอดจริงไม่ตรงกัน
- เข้าใจผิดว่าการตรวจ decimals พิสูจน์ผู้ออก เงินสำรอง สภาพคล่อง หรือความปลอดภัย

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

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

- **ERC-20 ทุกตัวมี `18` decimals** ข้อมูลนี้ไม่บังคับและ implementation อาจคืนค่าอื่น
- **Decimals คือบิตความแม่นยำที่ EVM ใช้** นี่เป็นธรรมเนียมแสดงผลฐานสิบ การคำนวณโทเค็นยังเป็นจำนวนเต็ม
- **ยอดที่ explorer จัดรูปแบบคือการยืนยันอิสระ** อาจพึ่งการเรียกข้อมูลเดียวกันและมีข้อผิดพลาดเดียวกัน
- **สัญลักษณ์และ decimals เดียวกันระบุสินทรัพย์เดียวกัน** ยังต้องมีเชนถูกต้อง สัญญาแน่นอน และหลักฐานจากผู้ออก
- **การโอนเล็กที่สำเร็จตรวจสอบทุก integration แล้ว** การอนุมัติ router บริดจ์ exchange และบัญชีอาจปรับสเกลแยกกัน

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

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

- [การตรวจสอบสัญญาโทเค็น](/crypto/token-contract-verification/)
- [การถอดรหัส calldata ในกระเป๋า](/crypto/calldata-decoding-wallet/)
- [การตรวจสอบโทเค็นบริดจ์](/crypto/bridge-token-verification/)
- [ความเสี่ยงโทเค็นเก็บค่าธรรมเนียมการโอน](/crypto/fee-on-transfer-token-risk/)
- [สัญญา proxy](/crypto/proxy-contract/)

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

## แหล่งข้อมูล

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)
- [ERC-20](https://docs.openzeppelin.com/contracts/5.x/erc20) - OpenZeppelin Docs (เข้าถึง: 2026-08-21)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - ethereum.org (เข้าถึง: 2026-08-21)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-21)

Source: https://wiki.fcontext.com/th/crypto/token-decimals-verification/index.mdx