---
title: "โทเค็นแบบ Canonical, Native และ Wrapped"
description: "คู่มือที่เริ่มจากการตรวจสอบตัวตนของโทเค็น สินทรัพย์ native ของผู้ออก สินทรัพย์ตัวแทนจากบริดจ์ที่โปรโตคอลกำหนด wrapper บนเชนเดียวกัน การค้ำประกัน การไถ่ถอน และมูลค่าทางออกที่ทำได้จริง"
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.

# โทเค็นแบบ Canonical, Native และ Wrapped

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

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

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

Canonical และ wrapped ไม่ใช่ประเภทโทเค็นที่ตรงข้ามกัน canonical อธิบายการจับคู่โทเค็นหรือเส้นทางที่ระบบนิเวศหนึ่งกำหนด ส่วน wrapped อธิบายกลไกการสร้างสินทรัพย์ตัวแทน โทเค็นจากบริดจ์ที่โปรโตคอลกำหนดอาจเป็น wrapped token ด้วย ขณะที่ WETH เป็น wrapper บนเชนเดียวกัน และ USDC native ของผู้ออกบนเชนที่รองรับอาจใช้การเผาและสร้างภายใต้การควบคุมของผู้ออกแทนเอสโครว์ของบริดจ์

เริ่มจากตัวตน ไม่ใช่สัญลักษณ์ ได้แก่ `chainId` ตัวบ่งชี้สินทรัพย์ native หรือสัญญาโทเค็น proxy implementation และบล็อก จากนั้นระบุว่าใครเป็นผู้ออกหรือผู้กำหนด มีสินทรัพย์หรือหนี้สินใดค้ำประกัน ใครมีสิทธิ์ mint, burn, pause หรือ upgrade และผู้ถือที่มีคุณสมบัติสามารถ unwrap, redeem, bridge หรือขายได้จริงหรือไม่ ความสามารถในการชำระหนี้ ความพร้อมในการไถ่ถอน และสภาพคล่องของตลาดเป็นคนละคำถาม

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

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

1. ตรึงภาพสถานะ ได้แก่ เชน `chainId` ตัวบ่งชี้สินทรัพย์ native หรือที่อยู่โทเค็น บล็อกและเวลา decimals, proxy implementation หรือ `codeHash` และเวอร์ชันเอกสารของผู้ออกหรือโปรโตคอล ชื่อ สัญลักษณ์ โลโก้ หรือรายการโทเค็นในกระเป๋าเงินไม่ใช่ตัวตน
2. จำแนกด้วยสองแกน สถานะตัวตนอาจเป็น native ของเชน native ของผู้ออก โปรโตคอลกำหนด หรือบุคคลที่สาม กลไกอาจเป็น wrapper บนเชนเดียวกัน สิทธิเรียกร้องจากบริดจ์แบบ lock-and-mint การโอนแบบ burn-and-mint, custodial wrapper, vault share หรือใบรับจากเครือข่ายสภาพคล่อง โทเค็นหนึ่งอาจอยู่ในหลายป้ายกำกับ
3. ติดตามสายที่มาและกราฟอำนาจอย่างแม่นยำ ได้แก่ สินทรัพย์ต้นกำเนิด คู่สัญญาระยะไกลที่ลงทะเบียน สัญญาเอสโครว์หรือ burn, messenger หรือ attester, minter ปลายทาง proxy admin บทบาท mint และ burn อำนาจ pause หรือ denylist, timelock ขีดจำกัด และแผนย้ายระบบ
4. สร้างบัญชีการค้ำประกันและหนี้สินใหม่ทั้งในหน่วยดิบและหน่วยแสดงผล สำหรับ lock-and-mint ให้กระทบยอดเอสโครว์ที่ใช้ได้กับคู่ดังกล่าว เทียบกับอุปทานสินทรัพย์ตัวแทนที่คงค้างและสิทธิเรียกร้องระหว่างทาง สำหรับ burn-and-mint ของผู้ออก ให้กระทบยอดอุปทานข้ามเชนและหนี้สินของผู้ออก อย่าสมมติเอสโครว์ของบริดจ์ที่ไม่มีอยู่
5. ตรวจสอบวงจรไถ่ถอนที่ทำได้จริง ได้แก่ ผู้มีสิทธิ์ ทิศทาง approval, unwrap หรือ burn, proof หรือ attestation, finalization หรือ claim ค่า gas ในแต่ละเชน ค่าธรรมเนียม ขีดจำกัด pause และการกู้คืนเมื่อผิดพลาด การทดสอบจำนวนเล็กน้อยพิสูจน์ได้เฉพาะเส้นทางและภาพสถานะนั้น
6. เปรียบเทียบเส้นทางออก บันทึก bid และ depth ของ DEX ที่ทำได้จริง slippage ค่าธรรมเนียมโปรโตคอลและ LP ค่า gas ความล่าช้า และการยอมรับของผู้รับฝากหรือแพลตฟอร์มแยกจากอัตราการค้ำประกัน โทเค็นที่มีสินทรัพย์ค้ำประกันอาจซื้อขายต่ำกว่ามูลค่าที่ตราไว้ และราคาที่มีสภาพคล่องไม่ได้พิสูจน์การค้ำประกัน
7. กระทบยอด receipt, event, ยอดคงเหลือ อุปทาน เอสโครว์ สิทธิเรียกร้องที่รอดำเนินการ และ allowance ที่เหลือ แยกยอด native, wrapped, bridged และ issuer-native ออกจากกัน ติดตาม implementation บทบาท การจับคู่ การย้าย pause การเปิดเผยทุนสำรอง และสภาพคล่อง แล้วจำกัดความเสี่ยงตามทางออกที่ทำได้จริงและเลวร้ายอย่างสมเหตุสมผล

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

## ตัวอย่างคำนวณ

- **การค้ำประกันต้องรวมสิทธิเรียกร้องที่รอดำเนินการ** เอสโครว์ที่ใช้ได้กับคู่สัญญามี `2,500.000000 units` อุปทานปลายทางที่สร้างแล้วมี `2,400.000000 units` และสิทธิเรียกร้องที่ล็อกแล้วแต่ยังไม่สร้างมี `100.000000 units` หนี้สินทางเศรษฐกิจคือ `2,400 + 100 = 2,500` ดังนั้นอัตราการค้ำประกันที่ปรับแล้วคือ `2,500 / 2,500 = 100%` การมองข้ามสิทธิเรียกร้องที่รอดำเนินการจะรายงาน `2,500 / 2,400 = 104.1666666667%` ซึ่งเป็นส่วนเกินที่ทำให้เข้าใจผิด แม้อัตราที่ถูกต้องก็ไม่ได้พิสูจน์ความปลอดภัยของสัญญาหรือสภาพคล่องทันที
- **สัญลักษณ์เดียวกันอาจเป็นสิทธิเรียกร้องต่างกัน** ผู้ถือมี `2,500 units` ของสัญญาสองฉบับ สัญญา issuer-native มี bid ที่ทำได้จริง `$0.998` คิดเป็น `2,500 * 0.998 = $2,495` ส่วนสัญญาบริดจ์บุคคลที่สามมี bid `$0.920` คิดเป็น `2,500 * 0.920 = $2,300` ต่างกัน `$195` แม้ชื่อและ decimals ตรงกัน
- **Wrapped ไม่ได้แปลว่าข้ามเชน** กระเป๋าเงินเริ่มด้วย `5.000 ETH` ฝาก `3.000 ETH` เข้า WETH contract บนเชนเดียวกัน และจ่ายค่า gas `0.002 ETH` สุดท้ายมี `1.998 ETH` กับ `3.000 WETH` ทุนสำรองและอุปทานของ wrapper เท่ากับ `3 / 3 = 100%` และความเสี่ยงเชิงเศรษฐกิจคือ `1.998 + 3.000 = 4.998 ETH` ก่อนความเสี่ยงของสัญญา การบวกทุนสำรองซ้ำคือการนับสองครั้ง
- **ทางออกตลาดกับการไถ่ถอนล่าช้าต่างกัน** สำหรับ `10,000 tokens` bid ของ DEX คือ `$0.985` ผลกระทบต่อราคา `0.60%` ค่าธรรมเนียม LP หรือโปรโตคอล `0.10%` และ gas `$12` ตามลำดับที่กำหนด รายรับสุทธิคือ `10,000 * 0.985 * (1 - 0.006 - 0.001) - 12 = $9,769.05` การไถ่ถอนของผู้มีสิทธิ์คืน `$9,987` หลังหักค่าธรรมเนียมใน `7 days` ที่อัตราค่าเสียโอกาสรายปีแบบง่าย `8%` มูลค่าปัจจุบันคือ `9,987 / (1 + 0.08 * 7 / 365) = $9,971.7009519641` หรือมากกว่า `$202.6509519641` นี่ไม่ใช่อาร์บิทราจที่รับประกัน และยังไม่รวมความเสี่ยงผิดนัด finality ภาษี และราคา

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

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

- ใช้เชน ตัวบ่งชี้สินทรัพย์ native หรือสัญญาโทเค็นผิด
- เชื่อสัญลักษณ์ ชื่อ ไอคอน หรือรายการโทเค็นในกระเป๋าเงินที่ปลอมแปลง
- อ่าน decimals หน่วยดิบ อุปทาน หรือความหมายยอดคงเหลือผิด
- พลาด proxy implementation, admin หรือการอัปเกรดโค้ด
- ยอมรับ registry คู่โทเค็น router หรือ gateway ที่ล้าสมัย
- สูญเสียการควบคุมเพราะผู้ออกหรือบทบาท mint, burn หรือ attester ถูกเจาะ
- ถือทุนสำรองที่ปะปน ถูกจำนำ หรือมีภาระผูกพันเป็นสินทรัพย์ค้ำประกันของคู่สัญญา
- นับเอสโครว์ อุปทานสินทรัพย์ตัวแทน และสิทธิเรียกร้องที่รอดำเนินการเป็นมูลค่าแยกกัน
- ไม่รวมเงินฝาก การเผา การถอน ค่าธรรมเนียม หรือข้อความที่ล้มเหลวระหว่างทาง
- สมมติว่าโทเค็นแบบ fee-on-transfer, rebasing หรือ hook-bearing ใช้การบัญชีมาตรฐาน
- พบการ freeze โดยผู้ออก bridge pause, denylist ขีดจำกัด หรือการเซ็นเซอร์
- ให้ allowance มากเกินไปหรือ approve spender ของบริดจ์ผิด
- อ่าน finality ต้นทาง ความถูกต้องของข้อความ หรือสถานะการทำงานปลายทางผิด
- พึ่ง relayer, sequencer, prover, attester หรือข้อมูลที่ไม่พร้อมใช้
- พบ replay, double mint, burn ล้มเหลว source reorg หรือข้อบกพร่องทางบัญชี
- พบว่าผู้ถือไม่มีสิทธิ์ไถ่ถอนโดยตรงกับผู้ออกหรือบริดจ์
- สภาพคล่องแตกส่วน depeg, slippage, MEV หรือ depth ไม่เพียงพอ
- ไม่รวม gas ค่าธรรมเนียม ความล่าช้า ค่าเสียโอกาส หรือการยอมรับของผู้รับฝาก
- ติดอยู่ในสัญญาที่เลิกใช้หรือการย้ายไปโทเค็น native ที่ไม่สมบูรณ์
- รวมความเสี่ยงที่สัมพันธ์กันของเชน บริดจ์ ผู้ออก oracle, UI, RPC ภาษี มาตรการคว่ำบาตร และการรับฝาก

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

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

- Canonical หมายถึง issuer-native เป็นทางการ trustless และปลอดภัยเสมอ
- Wrapped หมายความว่าโทเค็นข้ามเชนเสมอ
- โทเค็นที่มีสัญลักษณ์และ decimals เหมือนกันเป็นสิทธิเรียกร้องที่ใช้แทนกันได้
- ป้ายหนึ่งต่อหนึ่ง ยอดในสัญญา หรือตัวเลขอุปทานพิสูจน์ความสามารถในการไถ่ถอน
- การค้ำประกันด้วยทุนสำรองรับประกันมูลค่าเงินสดหนึ่งต่อหนึ่งทันทีในทุกตลาดและบัญชี

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

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

- [บริดจ์หลักของโปรโตคอล](/th/crypto/canonical-bridge/)
- [การตรวจสอบโทเค็นจากบริดจ์](/th/crypto/bridge-token-verification/)
- [Wrapped token](/th/crypto/wrapped-token/)

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

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

- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (เข้าถึง: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-12)
- [WETH9.sol](https://github.com/gnosis/canonical-weth/blob/master/contracts/WETH9.sol) - Gnosis (เข้าถึง: 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (เข้าถึง: 2026-08-12)
- [Bridged token addresses](https://docs.optimism.io/app-developers/reference/tokens/tokenlist) - Optimism Documentation (เข้าถึง: 2026-08-12)
- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Docs (เข้าถึง: 2026-08-12)
- [Cross-Chain Transfer Protocol](https://developers.circle.com/cctp) - Circle Docs (เข้าถึง: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-12)

Source: https://wiki.fcontext.com/th/crypto/canonical-vs-wrapped-token/index.mdx