ความรับผิดชอบของ DeFi โอเพนซอร์ส: ทำไมวอชิงตันถึงกำลังเขียนกฎใหม่สำหรับโค้ดที่ไม่ใช่ Custodial

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

วอชิงตันกำลังมุ่งเป้าไปที่ว่าใครต้องรับผิดชอบเมื่อโค้ด DeFi แบบโอเพนซอร์สสัมผัสกับเงินจริง ไม่ใช่แค่มิกเซอร์หรือสเตเบิลคอยน์ แต่รวมถึง front end, fee switch, อำนาจการกำกับดูแล และตลาดที่อิงตามเหตุการณ์ คำถามที่อยู่บนโต๊ะ: เมื่อไหร่การเผยแพร่โค้ดจะกลายเป็นการดำเนินผลิตภัณฑ์ทางการเงิน?

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

ประเด็น รายละเอียด จุดเน้นด้านการกำกับดูแลกำลังเปลี่ยนแปลง หน่วยงานสหรัฐฯ กำลังตรวจสอบว่าความรับผิดชอบแนบมาที่ไหนสำหรับโค้ด DeFi แบบ non-custodial โดยเฉพาะเมื่อมีการควบคุม ค่าธรรมเนียม หรืออินเทอร์เฟซที่คัดสรร มีช่วงเวลาออกกฎระเบียบที่ใช้งานอยู่ SEC และ CFTC เปิดกระบวนการแสดงความคิดเห็นร่วมเกี่ยวกับนิยามผลิตภัณฑ์อนุพันธ์ที่อาจครอบคลุมตลาด DeFi ใหม่ U.S. Securities and Exchange Commission (ข่าวเผยแพร่) นักพัฒนาต้องการขอบเขตที่ปลอดภัย บริษัทคริปโตหลายสิบแห่งเร่งเร้าให้รัฐสภารักษาการคุ้มครองสำหรับนักพัฒนาโอเพนซอร์สใน Section 604 ของ CLARITY Act Advisers LLP (การวิเคราะห์ทางกฎหมาย, 22 มิถุนายน 2026) เจ้าหน้าที่บังคับใช้กฎหมายโต้กลับ กลุ่มอัยการและตำรวจรายใหญ่เตือนว่า Section 604 อาจทำให้ AML และการสืบสวนอ่อนแอลงหากกำหนดไว้กว้างเกินไป Joint law-enforcement letter (PDF) / รายงานโดย The Block การถกเถียงระหว่างการแสดงออกกับการกระทำกำลังดำเนินอยู่ กรรมาธิการ SEC Hester Peirce โต้แย้งว่าการเผยแพร่โค้ดเพียงอย่างเดียวไม่ควรทำให้เกิดกฎหมายหลักทรัพย์ โดยวางความรับผิดชอบไว้ที่ผู้กระทำผิด Cointelegraph (รายงานคำพูดของ Peirce)

ทำไมหน่วยงานกำกับดูแลจึงวนเวียนอยู่กับโค้ด non-custodial ในตอนนี้

มีกระแสหลายอย่างมาบรรจบกัน

ประการแรก หน่วยงานต้องการความชัดเจนในจุดที่ DeFi ทับซ้อนกับโครงสร้างตลาด เมื่อวันที่ 18 มิถุนายน 2026 SEC และ CFTC ได้เปิดคำขอแสดงความคิดเห็นสาธารณะร่วมเพื่อประสานวิธีการจัดประเภท swap, security-based swap, mixed swap และผลิตภัณฑ์ที่อิงตามเหตุการณ์รูปแบบใหม่ ช่วงเวลาดังกล่าวสิ้นสุด 60 วันหลังการเผยแพร่ใน Federal Register ซึ่งมีความสำคัญต่อตลาดการทำนาย สินทรัพย์สังเคราะห์ และการออกแบบโปรโตคอลที่ดูเหมือนสถานที่ซื้อขายอนุพันธ์แม้จะอยู่บนเชน ข่าวเผยแพร่อยู่ที่นี่: U.S. Securities and Exchange Commission (ข่าวเผยแพร่)

ประการที่สอง รัฐสภากำลังพิจารณาวิธีแยกผู้สร้างออกจากผู้กระทำผิด ผู้ก่อตั้งและบริษัทมากกว่า 60 รายรวมถึงตลาดแลกเปลี่ยนขนาดใหญ่และกองทุน venture ได้กดดันผู้นำวุฒิสภาเมื่อวันที่ 9 มิถุนายน เพื่อรักษาการคุ้มครองนักพัฒนาใน Section 604 ของ CLARITY Act ไว้อย่างครบถ้วน แนวคิดนั้นเรียบง่าย: การเผยแพร่และดูแลโค้ดไม่ควรเท่ากับการดำเนินตลาดแลกเปลี่ยนหรือนายหน้าที่ไม่ได้จดทะเบียน อ่านสรุปทางกฎหมายได้ที่นี่: Advisers LLP (การวิเคราะห์ทางกฎหมาย, 22 มิถุนายน 2026)

ประการที่สาม เจ้าหน้าที่บังคับใช้กฎหมายมีความสงสัย เมื่อวันที่ 23-24 มิถุนายน องค์กรหลักสี่แห่งที่เป็นตัวแทนของอัยการและตำรวจได้ส่งจดหมายร่วมถึงกระทรวงยุติธรรมและทำเนียบขาว โดยเตือนว่า Section 604 อาจสร้างจุดบอด AML และขัดขวางการสืบสวนอาชญากรรมคริปโต จดหมายดังกล่าวเป็นสาธารณะ: Joint law-enforcement letter (PDF) / รายงานโดย The Block

นอกจากนี้ยังมีความเห็นในเดือนมิถุนายนของกรรมาธิการ SEC Hester Peirce ที่ว่าการเผยแพร่โอเพนซอร์สเป็นการแสดงออกที่ได้รับการคุ้มครองและไม่ควรทำให้ผู้เขียนโค้ดกลายเป็นผู้ละเมิดกฎหมายหลักทรัพย์หากไม่มีการกระทำอื่นใด กรอบดังกล่าวขีดเส้นแบ่งระหว่างการแสดงออกและการให้บริการ ดูรายงานได้ที่นี่: Cointelegraph (รายงานคำพูดของ Peirce)

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

สิ่งที่นักพัฒนาโอเพนซอร์สควบคุมได้และควบคุมไม่ได้

การควบคุมคือหัวใจสำคัญ

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

พื้นที่ที่มักดูเหมือนการแสดงออก

• การเผยแพร่ repo และเอกสารพร้อม permissive license
• การวิจัยเชิงวิชาการหรือการนำไปใช้อ้างอิงที่ผู้เขียนไม่ได้ deploy
• Fork ที่ไม่ใช่เชิงพาณิชย์ที่ใช้สำหรับทดสอบหรือสาธิต

พื้นที่ที่มักดูเหมือนการกระทำ

• การรัน canonical front end ที่นำผู้ใช้เข้าสู่สภาพคล่องจริง
• การควบคุม admin key, upgrader หรือพารามิเตอร์เริ่มต้นที่เปลี่ยนความเสี่ยงสำหรับผู้ใช้
• การดำเนินราคาหรือข้อมูล oracle ที่ส่งผลต่อการดำเนินการอย่างมีนัยสำคัญ
• การเก็บค่าธรรมเนียมโปรโตคอลหรืออินเทอร์เฟซที่ไหลไปยังบริษัทหรือบุคคลภายใน
• การมุ่งเป้าไปยังผู้ใช้ในสหรัฐฯ ด้วยการตลาดเพื่อผลตอบแทนทางการเงิน

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

ตัวกระตุ้นความรับผิดชอบที่วอชิงตันชี้ให้เห็นอยู่เสมอ

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

สถานการณ์ เหตุผลที่ดึงดูดความสนใจ Front-end เป็นตัวกำหนด อินเทอร์เฟซที่คัดสรรพร้อมค่าธรรมเนียมในตัวหรือการกรองผู้ใช้ดูเหมือนธุรกิจ ซึ่งใกล้เคียงกับตัวกลางที่ถูกกำกับดูแลมากกว่าโค้ดที่เป็นกลาง Admin key และการควบคุมฉุกเฉิน Kill switch, pausability และการเปลี่ยนพารามิเตอร์บ่งบอกถึงการควบคุมเงินทุนของผู้ใช้หรือโครงสร้างตลาด Fee switch และการแบ่งปันรายได้ เมื่อทีมพัฒนาหรือ DAO เก็บรายได้ เส้นแบ่งระหว่างซอฟต์แวร์และบริการจะเลือนลาง คุณภาพการเปิดเผยข้อมูลและการกำกับดูแลมีความสำคัญที่นี่ แรงจูงใจโทเค็นและการตลาด การอ้างสิทธิ์ส่งเสริมการขายหรือเศรษฐศาสตร์โทเค็นที่เน้นกำไรอาจเชิญให้เกิดการวิเคราะห์ด้านหลักทรัพย์ Oracle และผลิตภัณฑ์ที่อิงตามเหตุการณ์ เมื่อ oracle กำหนดผลลัพธ์สำหรับตลาดแบบ binary หรือตลาดทำนาย สิ่งนั้นอาจดูเหมือนแพลตฟอร์มอนุพันธ์ภายใต้การตรวจสอบร่วมของ SEC และ CFTC การปฏิบัติตามกฎระเบียบโดยการออกแบบขาดหายไป การไม่มีมาตรการปกป้องผู้ใช้ ไม่มีการเปิดเผยข้อมูล หรือการเพิกเฉยต่อความเสี่ยงจากการคว่ำบาตรที่ชัดเจนจะยิ่งทำให้สถานการณ์ร้อนแรงขึ้น

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

คู่มือสำหรับผู้สร้าง: การเผยแพร่โค้ดโดยไม่ทำให้ตัวเองเป็นเป้าหมาย

คุณไม่สามารถทำให้โปรเจกต์ป้องกันทฤษฎีความรับผิดชอบทุกอย่างได้ แต่คุณสามารถลดพื้นที่การโจมตีที่ชัดเจนได้ นี่คือรายการตรวจสอบที่ช่วยทีมต่างๆ ได้ดี

• แยกการแสดงออกออกจากการให้บริการ เปิด repo, การวิจัย และข้อกำหนดเอาไว้ หากคุณเสนออินเทอร์เฟซแบบโฮสต์ ให้เปิดเผยว่าเป็นบริการแยกต่างหากที่มีเงื่อนไขของตัวเอง
• ลดการควบคุมแบบฝ่ายเดียว ใช้การอัปเกรดแบบ time-locked, multisig ที่กระจายอย่างกว้างขวาง หรือการกำกับดูแลบนเชนที่มีการมีส่วนร่วมจริง บันทึกว่าใครเปลี่ยนแปลงอะไรได้บ้าง
• เปิดเผยความเสี่ยงอย่างผู้ใหญ่ อธิบายวิธีทำงานของ oracle สิ่งที่อาจเสียหาย ใครได้รับค่าธรรมเนียม และภายใต้เงื่อนไขใดที่เงินทุนจะถูกหยุดหรือโอนย้าย
• ออกแบบการไหลของค่าธรรมเนียมด้วยความระมัดระวัง หากค่าธรรมเนียมสะสม ให้นำไปไว้ใน community treasury ที่มีการกำกับดูแลที่ชัดเจน หลีกเลี่ยงการที่ทีมนำส่วนแบ่งโดยตรงซึ่งดูเหมือนการตัดส่วนของผู้ดำเนินการเชิงพาณิชย์
• ระมัดระวังในการแถลงต่อสาธารณะ หลีกเลี่ยงการสัญญาเรื่องกำไรหรือผลตอบแทนที่รับประกัน มุ่งเน้นไปที่ฟังก์ชันการทำงาน ไม่ใช่ผลประโยชน์ทางการเงิน
• ทำ geofencing เมื่อจำเป็น หากคุณดำเนินการ front end แบบโฮสต์ ให้ใช้มาตรการที่เหมาะสมในการจำกัดการเข้าถึงในที่ที่คุณไม่สามารถให้บริการผู้ใช้ได้อย่างถูกกฎหมาย
• มีกระบวนการจัดการช่องโหว่ เสนอ bug bounty และช่องทางที่เปิดเผยสำหรับรายงานความปลอดภัย ซึ่งแสดงถึงการดำเนินการที่รับผิดชอบ
• บันทึก fork และความเป็นอิสระ หากบุคคลที่สามรัน deployment ของตัวเอง ให้ชี้แจงว่าคุณไม่ได้ควบคุมพวกเขา

เคล็ดลับ: เผยแพร่ matrix "ใครควบคุมอะไร" ง่ายๆ ในเอกสารของคุณ เมื่อหน่วยงานกำกับดูแลถาม คุณจะมีแผนที่ที่ซื่อสัตย์แทนที่จะต้องโบกมือ

ผู้ดำเนินการตลาดแลกเปลี่ยนและ front-end: จุดคอขวดใหม่

แม้ว่า smart contract จะไม่เปลี่ยนแปลงได้ แต่พื้นที่ผิวที่สัมผัสกับผู้ใช้ไม่ใช่เช่นนั้น Wallet UI, อินเทอร์เฟซแบบโฮสต์, RPC gateway และบริการตั้งชื่อล้วนเป็นบริการที่ดำเนินการโดยมนุษย์ นั่นคือที่ที่ภาระผูกพันมักจะติดอยู่ก่อน

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

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

อนุพันธ์คือขอบที่คมที่สุด

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

สำหรับผู้สร้าง การอ่านเชิงปฏิบัติเป็นเรื่องง่าย หากโปรโตคอลของคุณแก้ไขผลลัพธ์ตามเหตุการณ์ภายนอก หรืออนุญาตให้ผู้ใช้รับ leveraged exposure ต่อสินทรัพย์ วางแผนสำหรับคำถามเกี่ยวกับว่าคุณกำลังเสนอผลิตภัณฑ์อนุพันธ์หรือไม่ กระบวนการแสดงความคิดเห็นเปิดรับ 60 วันหลังจากออกใน Federal Register ซึ่งเป็นช่วงเวลาสั้นๆ ในการแสดงความคิดเห็นพร้อมตัวอย่างที่เป็นรูปธรรม ดูคำขอได้ที่: U.S. Securities and Exchange Commission (ข่าวเผยแพร่)

คำพูดของกรรมาธิการ Peirce เกี่ยวกับโค้ดในฐานะการแสดงออกที่ได้รับการคุ้มครองจะเป็นส่วนหนึ่งของการสนทนา โดยเฉพาะสำหรับทีมที่เผยแพร่เฉพาะ reference implementation แต่ถ้า DAO หรือบริษัทของคุณรันอินเทอร์เฟซที่เชิญชวนผู้ใช้สหรัฐฯ ให้ซื้อขาย event contract ในราคาค่าธรรมเนียม นั่นถือเป็นสถานะที่แตกต่างจาก GitHub repo อย่างมาก รายงานคำพูดของเธอ: Cointelegraph (รายงานคำพูดของ Peirce)

สถานการณ์ผลกระทบต่อตลาดในช่วง 12 เดือนข้างหน้า

การทำ geofencing และข้อจำกัดความรับผิดชอบเพิ่มมากขึ้น

UI แบบโฮสต์ที่ให้บริการปริมาณการใช้งานในสหรัฐฯ จำนวนมากมีแนวโน้มที่จะขยายการบล็อกตามเขตอำนาจศาลและเพิ่มความยุ่งยากที่ขอบเขต คาดว่าจะมีคำเตือน modal เพิ่มขึ้น การเปิดเผยค่าธรรมเนียมที่ชัดเจนขึ้น และการรับทราบความเสี่ยงแบบ opt-in

การปรับปรุงการกำกับดูแล DAO

โปรเจกต์ที่มี multisig แบบ casual และอำนาจฉุกเฉินที่ไม่ชัดเจนจะเข้มงวดการกำกับดูแล ขั้นตอนที่เป็นลายลักษณ์อักษรและ public timelock มีราคาถูกเมื่อเทียบกับความเสี่ยงทางกฎหมาย

ความระมัดระวังในการลิสต์สินทรัพย์

Front end และ aggregator อาจค่อยๆ ถอนการลิสต์หรือซ่อนตลาดเหตุการณ์บางอย่างและฟีเจอร์ leverage สูงในขณะที่นิยามอนุพันธ์ยังอยู่ระหว่างการหารือ สภาพคล่องอาจไหลตามเส้นทางที่มีความเสี่ยงน้อยที่สุด โดยเปลี่ยนไปสู่โปรโตคอลที่สื่อสารขอบเขตที่ชัดเจน

การย้ายถิ่นของผู้สร้างและ fork

บางทีมอาจสร้าง deployment นอกสหรัฐฯ หรือ fork ที่ดูแลโดยชุมชนสำหรับฟีเจอร์ขั้นสูง ในขณะที่รักษาอินเทอร์เฟซหลักที่หันหน้าสู่สหรัฐฯ ให้เรียบง่ายกว่า ซึ่งทำให้สภาพคล่องและ UX แตกแยก แต่เป็นวาล์วระบายความปลอดภัยที่พบได้บ่อย

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

วิธีมีส่วนร่วมก่อนที่กฎเกณฑ์จะแน่วแน่

ช่วงเวลาของนโยบายเปิดอยู่ตอนนี้ นี่คือวิธีที่ทีมและชุมชนสามารถมีส่วนร่วมได้โดยไม่เผาเวลา

1. ยื่นความคิดเห็นสั้นๆ ตอบสนองต่อคำขอร่วมของ SEC และ CFTC พร้อมตัวอย่างปฏิบัติจริงว่าโปรโตคอลของคุณแตกต่างจากสถานที่ซื้อขายอนุพันธ์แบบรวมศูนย์อย่างไร ให้เป็นข้อเท็จจริงและเจาะจง ลิงก์: U.S. Securities and Exchange Commission (ข่าวเผยแพร่)
2. มีส่วนร่วมใน Section 604 อย่างสุภาพ หากคุณสนับสนุนการรักษาการเผยแพร่โค้ดให้พ้นจากรัศมีความรับผิดชอบ อธิบายว่าคุณแยกการแสดงออกออกจากการกระทำในโปรเจกต์ของตัวเองอย่างไร จดหมายของอุตสาหกรรมสรุปไว้ที่นี่: Advisers LLP (การวิเคราะห์ทางกฎหมาย, 22 มิถุนายน 2026)
3. จัดการกับความกังวลของเจ้าหน้าที่บังคับใช้กฎหมายโดยตรง บันทึกว่าการออกแบบของคุณหลีกเลี่ยงจุดบอด AML ที่ชัดเจนได้อย่างไรโดยไม่กลายเป็นการเฝ้าระวังโดยค่าเริ่มต้น ทราบการวิจารณ์: Joint law-enforcement letter (PDF) / รายงานโดย The Block
4. เผยแพร่หน้าความรับผิดชอบของผู้ดำเนินการ หากคุณรัน front end ให้ระบุอย่างชัดเจนว่าคุณควบคุมอะไรและไม่ควบคุมอะไร ค่าธรรมเนียมทำงานอย่างไร และผู้ใช้สามารถโต้ตอบกับ contract โดยตรงได้อย่างไรหากต้องการ
5. ประสานงานกับโปรเจกต์อื่นๆ มาตรฐานร่วมสำหรับการเปิดเผยข้อมูล การกำกับดูแลบนเชน และความโปร่งใสของ oracle มีน้ำหนักมากกว่าการแถลงการณ์ครั้งเดียว

หากคุณต้องการมุมมองรายสัปดาห์ที่สงบนิ่งเกี่ยวกับวิธีที่สิ่งนี้กำลังพัฒนา เราครอบคลุมการเคลื่อนไหวด้านนโยบายและโค้ดที่จัดส่งอยู่เบื้องหลังที่ Crypto Daily คุณสามารถตรวจสอบรายงานล่าสุดได้ที่ Crypto Daily

คำถามที่พบบ่อย

การเผยแพร่โค้ด DeFi โอเพนซอร์สทำให้ฉันกลายเป็นนิติบุคคลที่ถูกกำกับดูแลหรือไม่?

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

Section 604 ของ CLARITY Act เกี่ยวกับอะไร?

เป็นข้อเสนอที่ตามคำกล่าวของผู้สนับสนุนในอุตสาหกรรม จะคุ้มครองนักพัฒนาโอเพนซอร์สที่เผยแพร่โค้ดจากการถูกถือว่าเป็นตัวกลางทางการเงิน ผู้สนับสนุนต้องการรักษาการคุ้มครองเหล่านั้นไว้ ในขณะที่กลุ่มเจ้าหน้าที่บังคับใช้กฎหมายเตือนว่าการได้รับเอกสิทธิ์มากเกินไปอาจทำให้เครื่องมือ AML และการสืบสวนอ่อนแอลง อ้างอิง: Advisers LLP (การวิเคราะห์ทางกฎหมาย, 22 มิถุนายน 2026) และ Joint law-enforcement letter (PDF) / รายงานโดย The Block

กระบวนการแสดงความคิดเห็นของ SEC และ CFTC ส่งผลต่อ DeFi อย่างไร?

หน่วยงานต่างๆ กำลังถามว่าจะนิยาม swap, security-based swap และผลิตภัณฑ์ที่อิงตามเหตุการณ์ในลักษณะที่สอดคล้องกันได้อย่างไร หากโปรโตคอลของคุณคล้ายกับตลาดอนุพันธ์ ผลลัพธ์อาจส่งผลต่อสิ่งที่คุณสามารถเสนอให้ผู้ใช้สหรัฐฯ หรือวิธีที่คุณอธิบายมัน คำขออยู่ที่นี่: U.S. Securities and Exchange Commission (ข่าวเผยแพร่)

การรัน DAO เพียงพอที่จะหลีกเลี่ยงความรับผิดชอบหรือไม่?

ไม่โดยอัตโนมัติ หากกลุ่มเล็กๆ ควบคุมการอัปเกรด ค่าธรรมเนียม หรือ oracle การเรียกมันว่า DAO ไม่ได้ลบการควบคุมการดำเนินงานออกไป หน่วยงานกำกับดูแลดูสิ่งที่เกิดขึ้นจริง ไม่ใช่ป้ายชื่อ

ผู้ดำเนินการ front-end สามารถดำเนินการอะไรได้ตอนนี้?

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

นักพัฒนาควรทำ geofencing กับ contract เองหรือไม่?

Smart contract เป็นระดับโลกและยากต่อการทำ geofencing อย่างมีความหมาย หากคุณเสนอบริการแบบโฮสต์เช่นเว็บไซต์หรือ API นั่นเป็นสถานที่ที่เหมาะสมกว่าในการใช้การควบคุมการเข้าถึงตามคำแนะนำของที่ปรึกษา

ข้อผิดพลาดหลักที่ทีมทำในพื้นที่นี้คืออะไร?

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

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