# TAP, Trac และ Ordinals

Bitcoin ให้ประวัติบล็อกสาธารณะ TAP กำหนดการตีความเมตาโปรโตคอล Ordinals บรรจุเนื้อหา inscription และ Trac เป็นชั้นสื่อสารแบบเลือกใช้ สัญญาอะแดปเตอร์ P21 รักษาบทบาทเหล่านี้แยกกัน

## TAP

TAP กำหนดกฎตีความโทเคนและ DMT ที่รองรับ รายงาน P21 ที่อ้างเข้ากับสินทรัพย์ TAP-DMT ต้องทำตามกฎและพฤติกรรมเปิดใช้ ตัวทำดัชนีเดี่ยวช่วยตัดการพึ่งเครือข่าย แต่ไม่ตัดข้อกำหนดตีความสินทรัพย์

## ord-tap

ord-tap เป็นดัชนี TAP แบบอิสระที่พัฒนาจาก `ord` และเปิดสถานะปัจจุบันกับประวัติผ่าน REST อะแดปเตอร์บันทึกเวอร์ชัน ความครอบคลุมการซิงก์ และพฤติกรรม reorganization ชุดทดสอบอ้างอิงตรวจการตีความ ส่วนคำตอบ API ยังคงเป็นข้อสังเกตจนกว่าจะตรวจสอบอย่างอิสระ

## Trac และ OpenMayhem

Intercom ให้โครงสร้างพื้นฐานสื่อสารแบบ peer-to-peer และสถานะที่ทำสำเนา OpenMayhem กำหนดใบรับบริการที่ลงนาม หลักฐาน ความยินยอม และกฎข้อพิพาท ขอบเขต P21 คือการประเมินอาร์ติแฟกต์เดิมแบบส่งต่อได้ ไม่ใช่การแทนที่เครือข่ายสื่อสาร

## Ordinals

จารึกใช้เผยแพร่เนื้อหาและแหล่งอ้างอิงได้ ไม่ได้ทำให้ข้อความใด ๆ เป็นจริง ใช้การอ้างนโยบาย/ข้อกำหนดแบบเลือกได้เมื่อที่มามีประโยชน์ อย่าจารึกทุกผลตรวจ P21 ทั่วไป

## การเลือกส่วนพึ่งพา

การตีความ DMT ดั้งเดิมยึดกฎที่เข้ากันได้กับ TAP เครือข่าย Trac เป็นทางเลือก เอเจนต์ภายนอกใช้อินเทอร์เฟซบริการทั่วไป โปรโตคอลไม่บังคับให้ทุกเอเจนต์รันสแตก Bitcoin ทั้งหมด

อ้างอิง: [TAP](https://github.com/Trac-Systems/tap-protocol-specs), [ord-tap](https://github.com/Trac-Systems/ord-tap), [Intercom](https://github.com/Trac-Systems/intercom), [กฎ OpenMayhem](https://github.com/Trac-Systems/openmayhem/blob/main/RULES.md), [Ordinals](https://docs.ordinals.com/inscriptions.html)

<!-- p21-source-payment-v08 -->

## การแก้ความหมาย DMT โดยไม่ต้องสร้างโทเคน

Proof21 ใช้ DMT เป็นข้อกำหนดการตีความแหล่งข้อมูลที่ระบุเวอร์ชัน ไม่ใช่ฉันทามติของ Bitcoin หรือเครื่องตัดสินความจริงทุกประเภท การทำงาน DMT อ้างอิงนิยามองค์ประกอบที่ยอมรับ ระบุบล็อก Bitcoin ด้วยแฮชและความสูง ประเมินฟิลด์หรือรูปแบบที่รองรับ แล้วบันทึกอินพุตในใบรับรองกระบวนการที่ทำซ้ำได้ ไม่ต้องมีโทเคน DMT การมินต์ หรือการเขียน Bitcoin ต่อใบรับรอง งานที่ใช้ข้อมูล Bitcoin โดยตรงมีโปรไฟล์แหล่งข้อมูลแยกชัดเจน

องค์ประกอบแหล่งข้อมูล P21 **จะประกาศภายหลัง** หน้านี้ไม่เปิดเผยข้อความลงทะเบียน ฟิลด์หรือรูปแบบที่เลือก ชื่อที่สงวน หรือ ID ของ inscription การใช้องค์ประกอบเดิมที่ถูกต้องทำได้ และโปรโตคอลไม่ได้บังคับให้สร้าง inscription ใหม่ในชื่อแบรนด์

`ord-tap` แบบทำงานอิสระของ Trac มีระบบดัชนีที่นำกลับมาใช้ได้ ตัวแยกวิเคราะห์เวอร์ชันที่ตรึงรองรับฟิลด์ 4, 10 และ 11 ตรวจการเปิดใช้กฎ ปรับชื่อเป็นรูปแบบมาตรฐาน ตรวจรูปแบบ และปฏิเสธทั้งชื่อซ้ำและลายเซ็นฟิลด์/รูปแบบซ้ำ การเปลี่ยนชื่อไม่ได้ทำให้ลงทะเบียนนิยามทั้งฟิลด์ที่มีอยู่แล้วได้ โค้ดที่ตรวจไม่มีกระบวนการอนุมัติโดยทีม แต่ความถูกต้องยังขึ้นอยู่กับการตรวจประวัติตามกฎ ไม่ใช่เพียงการอยู่ใน Bitcoin สิทธิ์ใช้ผู้ให้บริการโฮสต์และเงื่อนไขบริการเป็นอีกเรื่องหนึ่ง [1][2][6]


## แยกการตีความ การลงทะเบียน และกรรมสิทธิ์

ใบรับรองแยกการอ่านข้อมูลต้นทาง การลงทะเบียนองค์ประกอบ การคำนวณแบบกำหนดผลแน่นอน ความถูกต้องของการสร้างหรือมินต์โทเคน และกรรมสิทธิ์หรือยอดคงเหลือปัจจุบัน การตรวจข้อหนึ่งไม่ได้ยืนยันข้ออื่น การตรวจผู้ลงทะเบียนที่ถูกต้องรายแรกต้องมีดัชนีประวัติและกฎการเปิดใช้งาน หลักฐานว่า inscription อยู่ในบล็อกไม่พิสูจน์ว่าไม่เคยมีองค์ประกอบขัดแย้งก่อนหน้า

ตรึงแฮชเนื้อหา inscription โปรไฟล์แหล่งข้อมูล เวอร์ชันต้นน้ำ เครือข่าย แฮชและความสูงบล็อก การเข้ารหัสมาตรฐาน การดำเนินการ พารามิเตอร์ commitment ของอินพุต และผลลัพธ์ ระบุขอบเขตหลักฐานและข้อจำกัด ข้อมูลที่ขาดหรือรูปแบบที่ไม่รองรับให้ผล INDETERMINATE ไม่ใช่สร้างผลว่าถูกต้อง แยกข้อมูลที่ดัชนีรายงานจากสถานะที่เล่นซ้ำโดยอิสระ การใช้ฟิลด์ Bitcoin โดยตรงแทนต้องไม่แอบนับเป็นการตรวจทะเบียน DMT ที่ยังไม่ได้ทำ


## การชำระเงินเริ่มต้น: NAT ดั้งเดิมและ USDC

NAT ดั้งเดิมเป็น**วิธีชำระเงินที่ต้องมีในการเปิดบริการเชิงพาณิชย์ครั้งแรก** ควบคู่กับ USDC ผ่านช่องทาง x402 ที่ทดสอบแล้ว ไม่ใช่ตัวเลือกที่เลื่อนไปภายหลัง โปรโตคอลหลักฐานยังไม่ผูกกับวิธีชำระเงิน ลูกค้าเลือกวิธีที่รองรับ และการตรวจใบรับรองอย่างอิสระไม่บังคับซื้อ NAT หรือโทเคน P21

โปรไฟล์ NAT ดั้งเดิมระบุ Bitcoin mainnet, TAP, inscription การสร้าง NAT เดิม และชื่อโทเคนแบบ fungible ที่ปรับเป็นมาตรฐาน โทเคนชื่อเดียวกันบนเชนอื่นเป็นคนละสินทรัพย์ เว้นแต่มีโปรไฟล์แยกที่ตรวจสอบแล้ว การโอน inscription มินต์ UNAT ไม่ได้โอนยอด NAT แบบ fungible [3][4]

ใบแจ้งชำระ NAT และการเติมเครดิตบริการล่วงหน้าทำงานแบบรอผล ยืนยันการโอนโทเคน fungible ที่ดำเนินการจริงตามกฎ TAP ที่ตรึง แล้วเพิ่มเครดิตเพียงครั้งเดียว งานขนาดเล็กถัดไปหักเครดิตบริการภายในที่โอนต่อไม่ได้ ไม่ต้องโอน NAT หรือสร้าง inscription ทุกงาน เครดิตเป็นบันทึกบัญชีบริการ ไม่ใช่โทเคน P21 ผลิตภัณฑ์ผลตอบแทน หรือการอ้างว่าฝากทรัพย์แบบไม่ต้องเชื่อใจ ใบแจ้งชำระตรงสำหรับงานใหญ่ใช้การตรวจเดียวกันได้

การรองรับ NAT ไม่ต้องพึ่งการแลกผ่าน DEX อัตโนมัติ กำหนดจำนวน NAT คงที่ต่อแพ็กเกจ หรือใช้นโยบายราคาที่อนุมัติแยก พร้อมเวลาหมดอายุและกฎปัดเศษ ก่อนรับเงินต้องเผยแพร่ค่าธรรมเนียมเครือข่าย ยอดเติมขั้นต่ำ การชำระช้า ขาดหรือเกิน การยกเลิก และการคืนเงิน ข้อกำหนดนี้ไม่แต่งอัตราแลกเปลี่ยนหรือยอดขั้นต่ำขึ้นเอง


[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry

[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs

[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live

[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer

[5] https://docs.x402.org/core-concepts/network-and-token-support

[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md

[7] https://arxiv.org/abs/1605.04559

<!-- p21-ecosystem-payments-v09 -->

## NAT บนหลายเครือข่าย

NAT มีสินทรัพย์ตัวแทนข้ามเชน ไม่ได้จำกัดอยู่ที่อินเทอร์เฟซกระเป๋าบิตคอยน์เท่านั้น ข้อมูลที่ตรวจพบระบุสินทรัพย์บน Ethereum, สินทรัพย์ Solana ชื่อ dmt-nat (Wormhole) และสัญญาโทเคนบริดจ์บน BNB Smart Chain สิ่งนี้เพิ่มช่องทางให้ชุมชน NAT เข้าถึงบริการ แต่ข้อมูลเหล่านี้ไม่ใช่การตรวจสอบเงินสำรองบริดจ์ การจับคู่สินทรัพย์ต้นทาง การไถ่ถอน หรือสถานะการทำงานของบริดจ์โดย P21

NAT ดั้งเดิมบน Bitcoin TAP ยังเป็นวิธีชำระเงินที่จำเป็นในระยะแรก NAT ข้ามเชนเป็นเป้าหมายอะแดปเตอร์หลัก โดยต้องอนุมัติแต่ละเครือข่ายและสัญญาหรือ mint แยกกัน โปรไฟล์ต้องเก็บอ้างอิงการออกสินทรัพย์ต้นทาง เส้นทางและเวอร์ชันบริดจ์ ตัวตนปลายทาง ทศนิยม ความสิ้นสุดของธุรกรรม และสมมติฐานการหยุดหรือไถ่ถอน ชื่อย่อเหมือนกันหรือการจดทะเบียนในตลาดเพียงอย่างเดียวไม่เพียงพอ สินทรัพย์ที่อนุมัติสามารถจ่ายบนเครือข่ายปลายทางได้ โดยไม่ต้องบริดจ์หรือแลกเงินทุกงาน

การตรวจสินทรัพย์ตัวแทนไม่เปลี่ยนการแปลข้อมูล DMT บิตคอยน์ยังเป็นแหล่งข้อมูลของข้ออ้าง Bitcoin/DMT แม้ค่าบริการมาจากเชนอื่น องค์ประกอบข้อมูลของ P21 ยังรอประกาศ เอกสารนี้ไม่ได้เปิดใช้งานบริดจ์ NAT ใด

[Binance assets and methods](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882)

<!-- p21-enforcement-v10 -->

## P21 TAP enforcement profile แบบเลือกใช้

TAP สามารถเป็น enforcement adapter สำหรับ TAP-native action แต่ไม่ใช่ dependency ของทุก receipt สเปก TAP ปัจจุบันที่ตรวจรองรับ 2-of-2 authority key + policy key ที่ต้องอนุมัติทั้งคู่ และ 2-of-3 หรือ threshold สูงกว่า จึงแมปได้กับ agent authority key + P21 policy signer ตราบใดที่ไม่มี authority อื่นหลบ gate

สเปกเดียวกันระบุ token locks, delegated locks, certified control และ conditional obligations ในชุด activation ที่ block 952317 และมีเส้นทาง HTLC/escrow กับ refund P21 ยังไม่ได้ deploy production policy signer, threshold wallet หรือ escrow service สภาพแวดล้อมอื่นใช้ smart account, MPC, HSM/KMS หรือ API capability proxy โดยรักษา action-binding invariant เดียวกันได้