การตรวจการกระทำทางการเงิน
โปรไฟล์การชำระเงินและการจ่ายเงินเชื่อมคำสั่งของเอเจนต์กับหลักฐานการดำเนินงานบนเครือข่าย 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 ที่ยืนยันอย่างอิสระแล้ว