# การตรวจการกระทำทางการเงิน

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

## ผูกเจตนากับการดำเนินงาน

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

อ่านธุรกรรมและผลที่สังเกตได้ ตรวจเฉพาะรูปแบบการโอนและความหมายโทเคนที่รองรับ พร็อกซี โทเคนหักค่าธรรมเนียมตอนโอน rebasing เราเตอร์ตัวกลาง internal call และ event ที่ตีความกำกวมต้องจัดการเฉพาะ ไม่ใช่แค่จับคู่ event log แบบครอบจักรวาล

## รายงานทีละเงื่อนไข

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

การจ่าย x402 เพื่อจ้างบริการดำเนินการเป็นคนละเหตุการณ์กับการจ่ายเงินที่จ้างให้บริการนั้นทำ อย่างแรกไม่ใช่หลักฐานแทนอย่างหลัง

## คุณค่าอยู่ตรงไหน

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

สัญญาอัจฉริยะเดิมอาจบังคับยอดขั้นต่ำหรือราคาสูงสุดอยู่แล้ว อย่าขายเงื่อนไขที่บังคับใช้อยู่เป็นคุณสมบัติความปลอดภัยใหม่ โปรไฟล์ swap ในอนาคตต้องระบุเราเตอร์และความหมายคำสั่งที่รองรับ ข้อมูลสถานที่ซื้อขายไม่ครบพิสูจน์ best execution ทั่วโลกหรือผลกำไรไม่ได้

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

## ผูก authorization กับ action ที่แน่นอน

ใน execution-gated profile ผล preflight PASS ยังไม่พอ `actionDigest` ของ authorization ต้อง commit canonical action ที่ profile กำหนด เช่น Bitcoin transaction/PSBT, EVM transaction/UserOperation หรือ canonical API request

ก่อน sign/invoke gate คำนวณ digest จริงอีกครั้งและตรวจ request, policy, network, asset, recipient/amount เมื่อเกี่ยวข้อง, nonce และ expiry Proof ของ transaction A ใช้อนุญาต transaction B ที่ถูกแทนที่ไม่ได้ หาก state-dependent condition ล้าสมัยต้อง refresh ก่อน และการ REJECT ภายหลังไม่เปลี่ยน settlement ที่ยืนยันอย่างอิสระแล้ว