ข้ามไปยังเนื้อหาหลัก
ความปลอดภัย

ความปลอดภัยที่ Blockchain0x.

การชำระเงินของตัวแทนเคลื่อนย้ายเงินจริง. ตัวเลือกทางสถาปัตยกรรมที่ปกป้องเงินทุนของลูกค้า, ท่าทีการตรวจสอบในปัจจุบัน, และวิธีการติดต่อเราหากคุณพบสิ่งผิดปกติ.

ขอบเขต

สิ่งที่คุณสามารถคาดหวังจากหน้านี้

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

What this page is not: a marketing surface designed to look maximally serious about security. We did not invent security certifications we do not hold, did not list "compliance" with frameworks we have not audited against, and did not put trust badges on the page that we did not earn. When we have a SOC 2 attestation or a third-party penetration test report, those will be referenced here with the auditing firm, the date, and the scope. Until then, this page says so plainly.

การรับประกันทางสถาปัตยกรรม

สี่คุณสมบัติที่ถือว่ามีอยู่ตามการสร้าง

การรับประกันด้านล่างนี้เป็นด้านสถาปัตยกรรม - พวกเขาคือคุณสมบัติของวิธีการสร้างระบบ ไม่ใช่วิธีการดำเนินการ ความปลอดภัยในการดำเนินงานอาจล้มเหลว (คีย์รั่วไหล, การปรับใช้ที่กำหนดค่าไม่ถูกต้อง); การรับประกันด้านสถาปัตยกรรมไม่ขึ้นอยู่กับการดำเนินงานในแต่ละวันที่สมบูรณ์แบบ นี่คือส่วนของเรื่องราวความปลอดภัยที่คุณสามารถพึ่งพาได้แม้ในสัปดาห์ที่เลวร้ายที่สุดของการดำเนินงาน.

ไม่เก็บรักษาที่ชั้นแพลตฟอร์ม

Blockchain0x ไม่ถือเงินของลูกค้า กระเป๋าเงินเป็นของตัวแทน (หรือตัวให้บริการการดูแลที่ลูกค้าเชื่อมต่อ เช่น Circle Programmable Wallets หรือ Coinbase Smart Wallet) บริการ Blockchain0x ดำเนินการพื้นผิวการพัฒนาที่อยู่เหนือกระเป๋าเงินเหล่านั้น - APIs, แดชบอร์ด, อัตลักษณ์, นโยบายการใช้จ่าย - และไม่มีอำนาจในการลงนามเหนือยอดเงิน.

นโยบายการใช้จ่ายที่บังคับใช้ที่ฝั่งเซิร์ฟเวอร์ ไม่ใช่ในเอเจนต์

ขีดจำกัดรายวัน, เพดานต่อการชำระเงิน, รายชื่ออนุญาตของคู่ค้า, และช่วงเวลาจะถูกประเมินโดย API กระเป๋าเงิน Blockchain0x ในทุกความตั้งใจในการชำระเงินก่อนการชำระเงินจริง ตัวรันไทม์ของตัวแทนไม่สามารถเข้าถึงที่เก็บนโยบายได้; ตัวแทนที่ถูกฉีดคำสั่งยังไม่สามารถเพิ่มขีดจำกัดของตนเองได้

การยืนยันการชำระเงินที่ตรวจสอบใบเสร็จ

ใบเสร็จการชำระเงินที่ปรากฏโดย API จะถูกตรวจสอบที่ฝั่งเซิร์ฟเวอร์กับธุรกรรมที่ออกก่อนที่จะยืนยัน ลูกค้าไม่สามารถปลอมใบเสร็จในท้องถิ่นและนำเสนอเป็นหลักฐานการชำระเงินได้; ขั้นตอนการตรวจสอบใบเสร็จเป็นโมเดลความเชื่อมั่นเดียวกับที่ใช้ลายเซ็น webhook ของ Stripe.

ลายเซ็น webhook ไม่ใช่ความลับที่แชร์ใน URLs

ทุกเหตุการณ์ webhook ที่เราส่งออกจะถูกลงนามด้วย HMAC-SHA256 บนเนื้อดิบโดยใช้ความลับในการลงนามต่อผู้เช่า ความลับในการลงนามจะไม่ถูกส่งใน URL หรือสตริงคำค้น ลูกค้าจะตรวจสอบลายเซ็นเมื่อได้รับ; เราให้การใช้งานอ้างอิงในเอกสาร

ท่าทางการตรวจสอบ

วันนี้เราอยู่ที่ไหน อย่างตรงไปตรงมา

The table below is the current state of external audits, third-party reviews, and certifications. We update this page when any line changes - dates are real, scopes are real, and "planned" means scheduled with a firm, not aspirational.

การทดสอบการเจาะจากบุคคลที่สาม

วางแผนสำหรับไตรมาสที่ 4 ปี 2026

การทดสอบการเจาะระบบภายนอกครั้งแรกมีกำหนดในช่วงครึ่งหลังของปี ขอบเขต: แอปเว็บ, API สาธารณะ, พื้นผิว webhook, การตรวจสอบแดชบอร์ด สรุปรายงานฉบับสมบูรณ์จะเผยแพร่ที่นี่เมื่อเสร็จสิ้น

SOC 2 Type I

ตั้งเป้าไว้สำหรับปี 2027

เรายังไม่ได้รับการตรวจสอบ SOC 2 ในวันนี้ ช่วงเวลาที่คาดหวังอย่างซื่อสัตย์สำหรับการรับรองประเภท I คือครึ่งแรกของปี 2027; ประเภท II จะตามมาหลังจากช่วงเวลาการสังเกต 6 ถึง 12 เดือน

การตรวจสอบสัญญาอัจฉริยะ

สืบทอดจากต้นน้ำ

ตอนนี้เราไม่ได้ดูแล smart contracts ของเราเอง on-chain primitives ที่ใช้อยู่คือ Circle Programmable Wallets, Coinbase Smart Wallet, และ contracts พื้นฐานของ Base / USDC ซึ่งทั้งหมดมีรายงาน audit อิสระของตนเองจากทีมผู้ออก หากและเมื่อเราเปิดใช้ contracts ของเราเอง (ฟีเจอร์ account-abstraction) จะต้องผ่านการ audit ก่อนนำขึ้น mainnet

การตรวจสอบความปลอดภัยภายในประจำปี

กำลังดำเนินการ

การหมุนเวียนความลับรายไตรมาส, การตรวจสอบการสแกนความพึ่งพา, และการตรวจสอบการควบคุมการเข้าถึง รายการตรวจสอบการเสริมความแข็งแกร่งก่อนการเปิดตัวได้ถูกบันทึกใน [คู่มือการรักษาความปลอดภัยกระเป๋าเงินของคุณ](/learn/guides/secure-your-agent-wallet) สำหรับลูกค้า; เวอร์ชันภายในจะสะท้อนสิ่งนี้.

การเปิดเผยช่องโหว่

เราไม่มี bug bounty แบบจ่ายเงิน

เพื่อให้ชัดเจนอย่างยิ่ง: Blockchain0x ไม่มีโครงการ bug bounty และไม่จ่ายเงิน, สินทรัพย์คริปโต, เครดิต, ของที่ระลึก, หรือค่าตอบแทนใดๆ สำหรับช่องโหว่ที่รายงาน ไม่มีระดับความรุนแรง ไม่มีช่วงเงินรางวัล และไม่มีการเจรจาใดๆ ในเรื่องนี้ - ใครก็ตามที่บอกคุณเป็นอย่างอื่นไม่ได้อ้างอิงจากเรา เราอยากพูดให้ตรงไปตรงมามากกว่าปล่อยให้นักวิจัยเสียเวลาช่วงสุดสัปดาห์ไปกับระบบของเราโดยคาดหวังเช็คที่ไม่มีอยู่จริง

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

อยู่ในขอบเขต

  • การยืนยันตัวตนและการจัดการ session บนแดชบอร์ดหรือ API
  • การยกระดับสิทธิ์ระหว่าง workspaces หรือเอเจนต์ในบัญชีเดียวกัน
  • server-side request forgery, command injection, หรือ remote code execution ใน API
  • การข้ามการตรวจสอบลายเซ็น webhook หรือการข้ามการตรวจสอบ receipt
  • การ bypass spend-policy ที่ทำให้เอเจนต์ย้ายเงินออกนอกเพดานหรือ allowlist ที่กำหนดไว้
  • การเปิดเผยข้อมูลจำนวนมาก (ธุรกรรมของผู้เช่ารายอื่น, secrets, audit logs)

นอกเหนือขอบเขต

  • Self-XSS หรือการโจมตีที่ต้องให้เหยื่อพิมพ์หรือวางอินพุตที่เป็นอันตรายลงใน console ของตนเอง
  • รายงานที่อาศัยการ social-engineering กับพนักงานหรือผู้รับจ้าง
  • รายงานที่เกี่ยวกับบริการบุคคลที่สามซึ่ง Blockchain0x เชื่อมต่อด้วย (Coinbase, Circle ฯลฯ) - ควรส่งไปยังโปรแกรมของบุคคลที่สามโดยตรง
  • ผลการตรวจพบจาก test endpoint (`sk_test_` keys, `*.test.blockchain0x.com`, Base Sepolia)
  • security headers ที่หายไปโดยไม่มีผลกระทบที่แสดงให้เห็น
  • ปัญหาเชิงทฤษฎีที่ยังไม่มี proof-of-concept ที่ใช้งานได้จริง
สิ่งที่ผู้รายงานจะได้รับรายละเอียด
การตอบรับทางอีเมลทุกรายงานจะได้รับการตอบกลับจากคนจริงที่ [email protected] ไม่ว่าผลการค้นพบจะถูกต้องหรือไม่ก็ตาม และจะได้รับผลการคัดกรองเมื่อเรามีข้อสรุปแล้ว
ใบรับรองการเปิดเผยอย่างรับผิดชอบสำหรับผลการค้นพบที่ยืนยันได้ ทำซ้ำได้ และอยู่ในขอบเขต: จะมีใบรับรองลงนามระบุชื่อคุณ (หรือ handle ของคุณ), ประเภทของปัญหา, และวันที่เปิดเผย ออกให้หลังจากปล่อยการแก้ไขแล้ว
การกล่าวถึงสาธารณะหากคุณอนุญาต ชื่อหรือแฮนเดิลของคุณจะถูกเพิ่มในรายชื่อการขอบคุณที่เผยแพร่บนหน้านี้เมื่อปัญหาได้รับการแก้ไขแล้ว หากคุณต้องการคงความไม่เปิดเผยตัวตนก็ได้ - เพียงแจ้งเรา เงื่อนไขนี้อยู่ภายใต้ข้อกำหนดการรักษาความลับด้านล่าง
รางวัลเป็นเงินไม่มี เราไม่จ่ายเงินสำหรับการรายงานช่องโหว่ไม่ว่าจะมีระดับความรุนแรงใด และการส่งรายงานไม่ได้ก่อให้เกิดสิทธิ์ใดๆ ในการรับเงิน

การตัดสินเรื่องความถูกต้องจะทำโดยหัวหน้าวิศวกรรมร่วมกับผู้ก่อตั้ง และถือเป็นที่สิ้นสุด การยกย่องจะมอบให้กับผลการค้นพบที่ยืนยันได้และทำซ้ำได้ภายในขอบเขตที่กำหนด; หากปัญหาเดียวกันถูกรายงานมากกว่าหนึ่งครั้ง ผู้ที่รายงานก่อนจะได้รับเครดิต เราไม่กำหนดให้ต้องมี NDA เพื่อยื่นรายงาน และเงื่อนไขด้านล่างนี้คือข้อผูกมัดเพียงเท่านั้น

เงื่อนไขที่ผูกกับการยกย่อง

ทั้งใบรับรองการเปิดเผยอย่างรับผิดชอบและการยกย่องต่อสาธารณะมีเงื่อนไขว่าคุณต้องรักษารายงานเป็นความลับ ห้ามเผยแพร่ช่องโหว่ รายงาน หรือรายละเอียดใดๆ ของมัน - ขั้นตอนการทำซ้ำ โค้ด proof-of-concept ภาพหน้าจอ endpoint ที่ได้รับผลกระทบ หรือการติดต่อสื่อสารของเราเกี่ยวกับเรื่องนี้ - ในสื่อใดๆ ทั้งสิ้น ซึ่งรวมถึงโพสต์ในบล็อก บทความเชิงวิเคราะห์ โพสต์ข้อความหรือรูปภาพบนโซเชียลเน็ตเวิร์กหรือฟอรัม วิดีโอ เสียง พอดแคสต์ การบรรยายในงานประชุม จดหมายข่าว กลุ่มแชท และสิ่งที่สร้างโดย AI ที่ดัดแปลงมาจากสิ่งเหล่านี้ หากคุณต้องการเผยแพร่หลังจากการแก้ไขถูกปล่อยใช้งานแล้ว โปรดแจ้งเราก่อน และโดยปกติเราจะตกลงเป็นลายลักษณ์อักษรเกี่ยวกับวันและระดับรายละเอียดให้ การเผยแพร่โดยไม่มีข้อตกลงเป็นลายลักษณ์อักษรดังกล่าวจะทำให้สิทธิ์ในใบรับรองและการยกย่องเป็นโมฆะ และเราขอสงวนสิทธิ์ในการใช้มาตรการเยียวยาอื่นใดที่มีอยู่ทั้งหมด

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

การกล่าวถึงสาธารณะ

นักวิจัยที่รายงานช่องโหว่ที่ยืนยันแล้วและขอให้ระบุชื่อไว้ จะถูกแสดงที่นี่ โดยเรียงจากล่าสุดก่อน เมื่อการแก้ไขถูกปล่อยใช้งานแล้ว ตอนนี้ยังไม่มีรายชื่อ - หากคุณเป็นคนแรก เราจะระบุไว้ที่นี่พร้อมชื่อหรือแฮนเดิลของคุณ และเดือนที่รายงาน การแสดงรายชื่อที่นี่อยู่ภายใต้เงื่อนไขการรักษาความลับที่ระบุไว้ข้างต้น

การเปิดเผยข้อมูลอย่างรับผิดชอบ

วิธีการรายงานปัญหาด้านความปลอดภัย.

ส่งอีเมลไปที่ [email protected] พร้อม: คำอธิบายของปัญหา, ขั้นตอนการทำซ้ำแบบทีละขั้น, URL หรือ endpoint ที่ได้รับผลกระทบ, ผลกระทบที่คุณสังเกตเห็น, และชื่อหรือ handle ที่คุณต้องการให้แสดงบนใบรับรองและในรายการผู้ได้รับการกล่าวถึง (ใช้แค่ handle ก็เพียงพอ ไม่จำเป็นต้องใช้ชื่อจริง และคุณสามารถขอให้ไม่เปิดเผยตัวตนได้) เรายินดีรับรายงานที่เข้ารหัส - สามารถขอ PGP key ของเราได้

เรามุ่งมั่นที่จะตอบรับรายงานของคุณภายในสองวันทำการ คัดกรองเบื้องต้นภายในห้าวัน และปล่อยการแก้ไขหรือข้อสรุปรับความเสี่ยงภายในสามสิบวันสำหรับผลการค้นพบที่ยืนยันแล้ว (หรือเร็วกว่านั้นสำหรับปัญหาวิกฤต) เราไม่ขู่ดำเนินคดีทางกฎหมายต่อการวิจัยด้านความปลอดภัยที่ทำด้วยความสุจริตและปฏิบัติตามหลักการเปิดเผยอย่างรับผิดชอบ - เปิดเผยข้อมูลเท่าที่จำเป็นเพื่อแสดงให้เห็นปัญหาเท่านั้น ไม่ขโมยข้อมูลลูกค้า ไม่ทดสอบแบบรบกวนที่กระทบผู้ใช้ในระบบ production และไม่เผยแพร่ผลการค้นพบก่อนที่เราจะตกลงเป็นลายลักษณ์อักษรว่าจะเผยแพร่เมื่อใดและอย่างไร

สำหรับปัญหาที่ไม่เกี่ยวกับความปลอดภัย (การสนับสนุนทั่วไป, การเรียกเก็บเงิน, ความร่วมมือ) ใช้ /contact. อีเมลด้านความปลอดภัยจะถูกตรวจสอบเฉพาะสำหรับรายงานด้านความปลอดภัย

การสื่อสารเหตุการณ์

สิ่งที่เราพูดหากมีบางอย่างผิดพลาด

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

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

ติดต่อด้านความปลอดภัย

รายงานช่องโหว่: [email protected] ขอ PGP key ได้ตามคำร้องขอ รายงานจะได้รับการตอบรับ แต่ไม่มีการจ่ายเงิน