ปัญหาของ Real-Time Vaults
หุ้นของ vault (vault shares) ทุกตัวแทนสิทธิ์ในสินทรัพย์อ้างอิง คำถามคือราคาที่ใช้ในการสร้าง (mint) และไถ่ถอน (redeem) หุ้นเหล่านั้นถูกต้องหรือไม่
ในโลกการเงินแบบดั้งเดิม มูลค่าสินทรัพย์สุทธิ (NAV)(1) จะเปลี่ยนแปลงอย่างช้าๆ กองทุนส่วนใหญ่ใช้การกำหนดราคาแบบส่งต่อ (forward pricing) ซึ่งเงินฝากจะถูกตัดสินในภายหลังผ่านช่วงเวลาการเข้าร่วมแบบคิว (queued entry windows) ซึ่งโดยธรรมชาติแล้วจะช่วยลดความเสี่ยงจากราคาที่ล้าสมัย (stale pricing)
DeFi เปลี่ยนแปลงสิ่งนั้นโดยสิ้นเชิง เพื่อให้หุ้นของ vault สามารถทำงานร่วมกันได้ (composable) ในตลาดสินเชื่อ (lending markets), วงจรเลเวอเรจ (leverage loops), และระบบการเงินบนเชน จำเป็นต้องมีการฝากเงินแบบอะตอมมิก (atomically) ในขณะที่กลยุทธ์และระบบบัญชีพื้นฐานอัปเดตแบบอะซิงโครนัส (asynchronously) ไปทั่วทั้งเชน (chains), สังเวียน (venues), และสภาพแวดล้อมการทำงาน
สิ่งนี้สร้างช่องว่างอันตรายระหว่างสิ่งที่ vault ครอบครองจริงกับสิ่งที่ vault เชื่อว่าตนครอบครอง
ทันทีที่เงินทุนสามารถเคลื่อนที่ได้อย่างต่อเนื่อง NAV จะหยุดเป็นเพียงหน้าที่ในการรายงานและกลายเป็นโครงสร้างพื้นฐานหลัก ทุกการฝาก, การไถ่ถอน, การปรับสมดุล และการชำระบัญชีขึ้นอยู่กับความถูกต้องของราคาที่ใช้ในเวลานั้นๆ NAV ที่ล้าสมัยไม่ใช่ปัญหาเชิงรูปลักษณ์ แต่เป็นเหตุการณ์ที่เกิดการถ่ายโอนมูลค่า (value-transfer event)
หากการฝากเงินถูกกำหนดราคาตามยอดคงเหลือที่ล้าสมัย ผู้ใช้ใหม่จะอุดหนุนผู้ถือหุ้นเดิม หากการไถ่ถอนถูกชำระตามราคาที่ล้าสมัย ผู้ใช้ที่ถอนเงินจะดึงมูลค่าออกจาก vault และหากกลยุทธ์เกิดขาดทุนก่อนที่ NAV จะอัปเดตทัน เงินฝากใหม่ก็อาจซื้อสินค้าคงคลังที่ด้อยค่า (impaired inventory) ในราคาก่อนขาดทุนโดยไม่รู้ตัว ความล้มเหลวเหล่านี้ไม่มีปรากฏใน APY ที่แสดงเป็นหัวข้อหลัก แต่มันมีความสำคัญ
นี่คือปัญหาโครงสร้างพื้นฐานที่ซ่อนอยู่เบื้องหลังสถาบันการเงินใน DeFi และนี่คือเหตุผลที่ Concrete สร้างระบบการจัดการ NAV แบบเรียลไทม์ที่ออกแบบมาสำหรับการเงินบนเชนแบบอะซิงโครนัส
ระบบ vault ส่วนใหญ่ถูกสร้างขึ้นบนสมมติฐานที่ว่า: กลยุทธ์ต่างๆ อยู่บนเชนทั้งหมด และการสร้างผลตอบแทนเป็นไปตามโปรแกรม เงินทุนเคลื่อนผ่าน smart contracts, สถานะ (positions) อัปเดตอย่างกำหนดได้ (deterministically), และการทำบัญชีสามารถถูกเขียนเป็นโค้ดตายตัวลงใน vault ได้โดยตรง ตราบใดที่กลยุทธ์ยังคงอยู่บนเชนทั้งหมด NAV ก็ยังคงคำนวณได้ค่อนข้างตรงไปตรงมา เพราะ vault สามารถมองเห็นสถานะและยอดคงเหลือเบื้องต้นได้ทันที
สมมติฐานนั้นพังทลายทันทีที่ vault พัฒนาเกินกว่ากลยุทธ์ smart contract
ระบบ vault สมัยใหม่พึ่งพาการดำเนินการแบบแอคทีฟ (active execution), การจัดสรรโดยผู้ดูแล (curator-driven allocations), การปรับใช้ข้ามเชน (cross-chain deployment), และแหล่งผลตอบแทนนอกเชน (off-chain yield sources) ที่ไม่สามารถสะท้อนบนเชนได้แบบเรียลไทม์ กลยุทธ์ในปัจจุบันดำเนินการข้ามสะพาน (bridges), สังเวียน perpetual, money markets, ระบบ restaking, และ pools สภาพคล่อง โดยทั้งหมดมีเวลาการชำระบัญชี (settlement times), ความล่าช้าในการรายงาน (reporting delays), และลักษณะสภาพคล่อง (liquidity characteristics) ที่แตกต่างกัน ในบางกรณี สถานะของสถานะที่เกี่ยวข้องอาจขึ้นอยู่กับบันทึกของผู้ดูแล (custodian records), ข้อมูลจากสังเวียน (venue data), การชำระบัญชีข้ามเชน (cross-chain settlement), หรือบันทึกการดำเนินการนอกเชน (off-chain execution records) ที่ไม่สามารถสะท้อนบนเชนได้ด้วยความเร็วเท่ากับยอดคงเหลือของโทเค็นธรรมดา
ผลลัพธ์ก็คือเงินทุนเคลื่อนที่อย่างต่อเนื่องในขณะที่สถานะพื้นฐานของ vault อัปเดตแบบอะซิงโครนัส ซึ่งสร้างช่องว่างอันตรายระหว่างสิ่งที่ vault ครอบครองจริงกับสิ่งที่ vault เชื่อว่าตนครอบครอง
ในช่องว่างนั้น มูลค่ารั่วไหล (value leaks)
ความหน่วงของราคาไม่ใช่แรงเสียดทานในการดำเนินงาน แต่คือการถ่ายโอนความเสี่ยงที่ซ่อนอยู่ ยิ่ง DeFi เคลื่อนที่เร็วเท่าไร ความสมบูรณ์ของการทำบัญชีก็ยิ่งสำคัญมากขึ้นเท่านั้น
การจัดการ NAV สำหรับการเงินบนเชน
Concrete เข้าใกล้ NAV ในฐานะปัญหาระบบ (systems problem) มากกว่าการอัปเดต oracle หรือบัญชีเพียงครั้งเดียว สถาปัตยกรรมผสมผสานโมเดลการปรับเรียบ (smoothing models), เกณฑ์ความเสี่ยงแบบไดนามิก (dynamic risk thresholds), การตรวจสอบอิสระ (independent verification), การควบคุมเงินฝาก (deposit controls), และกลไกหยุดชั่วคราวอัตโนมัติ (automated pause mechanisms) เข้ากับกรอบงานแบบครบวงจรที่ออกแบบมาเพื่อให้ราคาของ vault ยังคงแม่นยำแม้ในช่วงสภาวะตลาดที่ผันผวน
ความท้าทายแรกคือสัญญาณรบกวน (noise) ข้อมูลราคาดิบมีความไม่สมบูรณ์แบบโดยธรรมชาติ ความล่าช้าของสะพาน (bridge delays), APIs ที่ล้าสมัย, การหยุดชะงักของสภาพคล่องชั่วคราว (temporary liquidity dislocations), และเหตุการณ์การชำระบัญชีแบบอะซิงโครนัส (asynchronous settlement events) ล้วนสามารถบิดเบือนการทำบัญชีระยะสั้นได้ Concrete ปรับเรียบการสังเกตการณ์ NAV โดยใช้ค่าเฉลี่ยเคลื่อนที่แบบถ่วงน้ำหนักเอ็กซ์โปเนนเชียล (EWMA) ซึ่งช่วยให้การสังเกตการณ์ล่าสุดมีน้ำหนักมากขึ้น ในขณะเดียวกันก็กรองจุดสูงสุดที่แยกตัวออกมา (isolated spikes) และความผิดปกติชั่วคราว (transient anomalies)(2) วัตถุประสงค์ไม่ใช่เพื่อระงับความผันผวน แต่เพื่อจำกัดอิทธิพลของความผิดปกติของข้อมูลที่แยกตัวออกมาต่อการกำหนดราคาของ vault
แต่การปรับเรียบเพียงอย่างเดียวนั้นไม่เพียงพอ เพราะทุก vault มีพฤติกรรมที่แตกต่างกัน กลยุทธ์ delta-neutral carry มีโปรไฟล์ความผันผวนที่แตกต่างอย่างสิ้นเชิงจาก leveraged restaking vault การเคลื่อนไหว 50 basis point อาจไม่สำคัญสำหรับกลยุทธ์หนึ่ง แต่อาจเป็นหายนะสำหรับอีกกลยุทธ์หนึ่ง Concrete ปรับเทียบทุก vault อย่างอิสระโดยเชื่อมโยงเกณฑ์การหยุดชั่วคราว (pause thresholds) เข้ากับการวัดความผันผวนแบบหมุน (rolling volatility measurements) ที่ได้จากแบบจำลองส่วนเบี่ยงเบนมาตรฐานสองสัปดาห์ (two-week standard deviation model)(3) เกณฑ์ต่างๆ จะถูกจำกัดให้แคบลงโดยอัตโนมัติในช่วงที่มีเสถียรภาพ และขยายกว้างขึ้นในช่วงที่ผันผวน ทำให้การจัดการความเสี่ยงสามารถปรับตัวแบบไดนามิกตามพฤติกรรมของกลยุทธ์พื้นฐาน แทนที่จะพึ่งพาสมมติฐานแบบคงที่
การตรวจสอบก่อนการชำระบัญชี
ถึงกระนั้น ความเร็วที่ปราศจากการตรวจสอบนั้นไม่ใช่โครงสร้างพื้นฐานของสถาบัน ทุกการอัปเดต NAV ภายใน Concrete ต้องผ่านกระบวนการตรวจสอบแบบสามฝ่าย (three-party verification process) ผู้เสนอธุรกรรม (Transaction Proposer) คำนวณการอัปเดตที่เสนอโดยใช้ข้อมูลกลยุทธ์และบัญชี ผู้ลงนามอิสระ (Independent Signer) ตรวจสอบความถูกต้องของการอัปเดตกับแหล่งบัญชีที่แยกต่างหาก สุดท้าย smart contract เองจะปฏิเสธการอัปเดตที่อยู่นอกเหนือขอบเขตบัญชีที่กำหนดไว้ล่วงหน้า (predefined accounting bounds)(4) โดยการออกแบบแล้ว ไม่มีผู้ปฏิบัติงานรายเดียว รวมถึง Concrete ที่สามารถแก้ไขบัญชีของ vault ฝ่ายเดียว (unilaterally) นอกเหนือขอบเขตที่บังคับใช้โดย smart contract วัตถุประสงค์ของระบบไม่ใช่เพียงแค่ความซ้ำซ้อนในการปฏิบัติงาน แต่เพื่อลดความเสี่ยงที่ข้อมูลที่ไม่ดี, การรายงานที่ล้าสมัย, หรือข้อผิดพลาดของผู้ปฏิบัติงานจะส่งผลโดยตรงต่อชั้นการกำหนดราคาที่ผู้ใช้ทำธุรกรรมด้วย
อย่างไรก็ตาม ความสมบูรณ์ของการกำหนดราคาเป็นเพียงครึ่งหนึ่งของปัญหา แม้แต่ระบบบัญชีที่ตรวจสอบอย่างสมบูรณ์แบบก็ไม่สามารถขจัดความหน่วงระหว่างเหตุการณ์ในตลาดและการอัปเดตการชำระบัญชีได้
การตรวจสอบทำให้แน่ใจได้ว่า NAV ที่รายงานนั้นถูกต้อง ความสมบูรณ์ของการชำระบัญชี (Settlement integrity) ทำให้แน่ใจว่าผู้ใช้ทำธุรกรรมกับ NAV นั้นอย่างยุติธรรมในขณะที่สถานะพื้นฐานของ vault ยังคงอัปเดตแบบอะซิงโครนัสต่อไป
เป้าหมายไม่ใช่เพื่อขจัดความหน่วงโดยสิ้นเชิง เป้าหมายคือเพื่อป้องกันไม่ให้ความไม่แน่นอนชั่วคราวกลายเป็นการรั่วไหลของมูลค่าถาวร
การปกป้องผู้ฝากเงินรายถัดไป
สิ่งนี้มีความสำคัญมากที่สุดในช่วงเหตุการณ์ขาดทุนที่มีนัยสำคัญ (material loss events) ซึ่งเป็นจุดที่ระบบหยุดชั่วคราว (pause systems) ส่วนใหญ่ของ DeFi มักถูกเข้าใจผิด กลไกหยุดชั่วคราวมักถูกมองว่าเป็นมาตรการป้องกันการปฏิบัติงานที่ปกป้องโปรโตคอลหรือผู้ปฏิบัติงาน ในความเป็นจริง กลไกเหล่านี้มีไว้เพื่อปกป้องผู้ฝากเงินรายถัดไป
หากกลยุทธ์เกิดขาดทุนที่มีนัยสำคัญก่อนที่ NAV จะอัปเดตอย่างสมบูรณ์ ผลลัพธ์ที่แย่ที่สุดคือการปล่อยให้เงินฝากใหม่เข้ามาใน vault ต่อไปด้วยราคาที่ล้าสมัย ผู้ใช้เหล่านั้นกำลังซื้อสินค้าคงคลังที่ด้อยค่าโดยไม่รู้ตัว สถาปัตยกรรมการหยุดชั่วคราวของ Concrete ได้รับการออกแบบมาสำหรับสถานการณ์นี้โดยเฉพาะ เมื่อความเบี่ยงเบนระหว่างชั้นการสังเกตการณ์สด (live observation layer) กับโมเดลราคาที่ปรับเรียบ (smoothed pricing model) ละเมิดเกณฑ์ที่ปรับตามความผันผวน ระบบจะถูกออกแบบมาให้หยุดการฝากเงินจนกว่าความสมบูรณ์ของการกำหนดราคาจะกลับคืนมา(5) วัตถุประสงค์ไม่ใช่เพื่อความสะดวกในการปฏิบัติงาน แต่เพื่อลดความเสี่ยงที่ผลขาดทุนจะถูกกระจายไปยังผู้เข้าร่วมโดยไม่ได้ตั้งใจ (unintentionally socialized)
การถอนเงินทำให้เกิดปัญหาเดียวกันในทิศทางตรงกันข้าม หากเงินทุนยังคงถูกใช้งานหลังจากมีการร้องขอการถอน เงินทุนนั้นยังคงสร้างผลตอบแทนและยังคงเผชิญกับความเสี่ยง การปฏิบัติต่อผู้ใช้ราวกับว่าพวกเขาออกไปแล้วก่อนที่สถานะจะถูกคลี่คลายจริง (unwound) จะสร้างความไม่สอดคล้องกันระหว่างความเสี่ยงทางเศรษฐกิจ (economic exposure) และความเป็นจริงทางบัญชี
สถาปัตยกรรม vault แบบอะซิงโครนัส (async vault architecture) ของ Concrete ใช้คิวการถอนแบบ epoch ที่เข้ากันได้กับมาตรฐาน ERC-4626 ซึ่งจะชำระการไถ่ถอนตาม NAV ณ เวลาที่ชำระบัญชี ไม่ใช่ NAV ณ เวลาที่ขอ(6) หลักการนั้นง่าย: หากเงินทุนยังคงมีความเสี่ยงจากกลยุทธ์ เงินทุนนั้นจะต้องยังคงเผชิญกับการเปลี่ยนแปลงของ NAV ที่เป็นผลตามมาด้วย สิ่งอื่นใดจะสร้างโอกาสในการเก็งกำไร (arbitrage opportunities) และการถ่ายโอนมูลค่าที่ไม่เป็นธรรมระหว่างผู้เข้าร่วม
ผลิตภัณฑ์คือ Stack (The Product Is the Stack)
สิ่งที่สำคัญไม่ใช่ชั้นการควบคุม (control layer) แต่ละชั้น แต่เป็นวิธีการที่ชั้นต่างๆ เสริมกำลังซึ่งกันและกัน การปรับเรียบโดยไม่มีเกณฑ์แบบปรับตัวได้ (adaptive thresholds) จะเข้มงวดเกินไป เกณฑ์โดยไม่มีการตรวจสอบทำให้เกิดความเสี่ยงในการปฏิบัติงาน การตรวจสอบโดยไม่มีการควบคุมเงินฝากยังคงทำให้ผู้ใช้เสี่ยงในช่วงเวลาที่มีความหน่วง การจำกัดวงเงินฝาก (deposit caps) โดยไม่มีระบบหยุดชั่วคราวยังคงทำให้เกิดเหตุการณ์ราคาที่บกพร่อง (impaired pricing events) และระบบหยุดชั่วคราวโดยไม่มีสถาปัตยกรรมการถอนที่สอดคล้องกันยังคงทำให้มูลค่ารั่วไหลเมื่อมีการไถ่ถอน
ผลิตภัณฑ์ไม่ใช่ EWMA ผลิตภัณฑ์ไม่ใช่การจำกัดวงเงินฝาก ผลิตภัณฑ์ไม่ใช่การทำบัญชีอัตโนมัติ
ผลิตภัณฑ์คือ Stack (The product is the stack)
ผู้จัดสรรเงินทุนของสถาบัน (Institutional allocators) ไม่ได้ประเมิน vaults โดยพิจารณาจากผลตอบแทนเพียงอย่างเดียว พวกเขาประเมินความสมบูรณ์ของการทำบัญชี (accounting integrity), การควบคุมการปฏิบัติงาน (operational controls), ความแม่นยำของการกำหนดราคา (pricing accuracy), และการออกแบบการบรรเทาผลขาดทุน (loss-mitigation design) นี่คือชั้นโครงสร้างพื้นฐานที่จำเป็นสำหรับ DeFi ในการเติบโตเกินกว่าการไหลของเงินทุนเชิงเก็งกำไร (speculative capital flows) และวิวัฒนาการไปเป็นโครงสร้างพื้นฐานทางการเงินที่ตั้งโปรแกรมได้ (programmable financial infrastructure) ที่สามารถรองรับเงินทุนระดับสถาบัน
ระบบของ Concrete ได้รับการออกแบบมาเพื่อให้การอัปเดต NAV ได้รับการตรวจสอบอย่างอิสระ ความผิดปกติของราคาถูกกรองก่อนการชำระบัญชี ความเสี่ยงในการฝากเงินถูกจำกัดแบบไดนามิก เหตุการณ์ขาดทุนที่มีนัยสำคัญกระตุ้นกลไกหยุดชั่วคราวสำหรับกระแสเงินเข้าใหม่ และการถอนเงินจะชำระตามสถานะบัญชีสด (live accounting states) แทนที่จะเป็นภาพรวมที่ล้าสมัย (stale snapshots) ระบบเหล่านี้ไม่ใช่คุณสมบัติเสริมที่ถูกเพิ่มเข้าไปใน vaults ภายหลัง แต่เป็นข้อกำหนดพื้นฐานสำหรับการทำให้การเงินที่ตั้งโปรแกรมได้มีความน่าเชื่อถือในระดับใหญ่
อนาคตของโครงสร้างพื้นฐานของ Vault
DeFi แก้ปัญหาเรื่องความโปร่งใสก่อนที่จะแก้ปัญหาการทำบัญชี ตอนนี้กำลังเปลี่ยนแปลง
ในขณะที่ vaults พัฒนาไปเป็นโครงสร้างพื้นฐานทางการเงินที่ตั้งโปรแกรมได้ซึ่งดำเนินการข้ามเชน, กลยุทธ์, และชั้นสภาพคล่อง คุณภาพของโครงสร้างพื้นฐานจึงมีความสำคัญมากกว่า APY ที่เป็นหัวข้อหลัก เฟสถัดไปของ DeFi จะไม่ได้ถูกกำหนดโดยว่าใครรายงานผลตอบแทนได้เร็วที่สุด แต่จะถูกกำหนดโดยว่าใครสามารถทำให้ตัวเลขเหล่านั้นน่าเชื่อถือได้
NAV แบบเรียลไทม์ไม่ใช่แค่การปรับปรุง UX แต่เป็นโครงสร้างพื้นฐานที่จำเป็นสำหรับเงินทุนของสถาบัน เพราะยิ่งเงินทุนเคลื่อนที่บนเชนได้เร็วเท่าไร ความสมบูรณ์ของการทำบัญชีก็ยิ่งสำคัญมากขึ้นเท่านั้น
Vaults ไม่ใช่เครื่องห่อหุ้มผลตอบแทนแบบพาสซีฟอีกต่อไป พวกมันคือระบบการเงินที่ตั้งโปรแกรมได้ และระบบการเงินที่ตั้งโปรแกรมได้ต้องการความน่าเชื่อถือที่ตั้งโปรแกรมได้ (programmable trust)
บทความนี้มีวัตถุประสงค์เพื่อให้ข้อมูลเท่านั้น และไม่ถือเป็นคำแนะนำด้านการลงทุน, กฎหมาย, ภาษี, การเงิน หรือการเสนอขายหรือชักชวนใดๆ คำอธิบายเกี่ยวกับสถาปัตยกรรม, การควบคุม และวัตถุประสงค์การออกแบบของ Concrete เป็นเพียงตัวอย่างเท่านั้น ไม่ได้ขจัดความเสี่ยงที่เกี่ยวข้องกับ smart contracts, โปรโตคอล DeFi, สภาวะตลาด, ความล้มเหลวของ oracle หรือข้อมูล, ความล้มเหลวในการปฏิบัติงาน, โครงสร้างพื้นฐานของบุคคลที่สาม, หรือประสิทธิภาพของคู่สัญญา Concrete ไม่รับประกันว่าผลตอบแทนเป้าหมาย, ความแม่นยำของ NAV, พฤติกรรมการหยุดชั่วคราว หรือผลลัพธ์อื่นๆ ของระบบใดๆ จะเกิดขึ้นจริง ข้อความที่เป็นการคาดการณ์ล่วงหน้าสะท้อนถึงความคาดหวังในปัจจุบันของ Concrete และไม่รับประกันผลลัพธ์ในอนาคต การเข้าร่วมใน vaults ของ Concrete มีความเสี่ยง รวมถึงความเสี่ยงที่จะสูญเสียทั้งหมด สำหรับการเปิดเผยความเสี่ยงโดยสมบูรณ์ โปรดดูที่ https://concrete.xyz/disclaimers
- ในบทความนี้ "NAV" หมายถึงมูลค่าการทำบัญชีในการดำเนินงาน (operational accounting value) ที่ใช้ในการกำหนดราคาหุ้นของ vault, เงินฝาก, การไถ่ถอน และการชำระบัญชีระดับกลยุทธ์ อาจแตกต่างจาก NAV ในงบการเงิน, บันทึกของผู้ดูแล, หรือค่าของโปรโตคอลบุคคลที่สาม และอาจขึ้นอยู่กับวิธีการและระยะเวลาที่เฉพาะเจาะจงของ vault
- ค่าเฉลี่ยเคลื่อนที่แบบถ่วงน้ำหนักเอ็กซ์โปเนนเชียล (Exponentially weighted moving average) จะให้น้ำหนักกับการสังเกตการณ์ล่าสุดมากขึ้น ในขณะที่ยังคงรวมข้อมูลที่เก่ากว่า พารามิเตอร์เฉพาะ รวมถึงอัตราการสลายตัว (decay rate) และหน้าต่างการสังเกตการณ์ (observation windows) จะถูกปรับเทียบต่อ vault และอาจได้รับการอัปเดตโดย Concrete เมื่อเวลาผ่านไปตามลักษณะของกลยุทธ์, สภาวะตลาด และข้อมูลการดำเนินงาน การปรับเรียบด้วย EWMA ช่วยลดอิทธิพลของความผิดปกติของราคาระยะสั้น แต่ไม่ได้ขจัดความเสี่ยงด้านราคา
- หน้าต่างความผันผวน, ความกว้างของเกณฑ์, และพารามิเตอร์การหยุดชั่วคราวได้รับการปรับเทียบต่อ vault, อาจมีการเปลี่ยนแปลงได้ตามดุลยพินิจของ Concrete และขึ้นอยู่กับความถูกต้องของข้อมูลนำเข้า ไม่มีแบบจำลองเกณฑ์ใดที่สามารถคาดการณ์ทุกสภาวะตลาดได้
- บทบาทที่อธิบายไว้ (Transaction Proposer, Independent Signer และการตรวจสอบบนเชน) ดำเนินการภายใน smart contracts ของ vault ของ Concrete และอยู่ภายใต้การควบคุมของ multisig และ timelock การตรวจสอบช่วยลดแต่ไม่ได้ขจัดความเสี่ยงของการอัปเดต NAV ที่ไม่ถูกต้อง รวมถึงความเสี่ยงที่เกิดจากคีย์ที่ถูกบุกรุก (compromised keys), ข้อมูลนำเข้าที่มีข้อบกพร่อง หรือช่องโหว่ของ smart contract ประวัติการตรวจสอบ (audit history) ของ Concrete มีอยู่ที่ docs.concrete.xyz/audits
- พฤติกรรมการหยุดชั่วคราวขึ้นอยู่กับการปรับเทียบเกณฑ์ที่แม่นยำและความถูกต้องของชั้นการสังเกตการณ์พื้นฐาน การหยุดชั่วคราวอาจไม่ถูกกระตุ้นในทุกสถานการณ์ที่ขาดทุน และการออกแบบมีจุดประสงค์เพื่อลด ไม่ใช่ขจัด ความเสี่ยงที่ผู้ฝากเงินรายใหม่ทำธุรกรรมในราคาที่ล้าสมัย
- Vaults ของ Concrete สร้างขึ้นตามมาตรฐาน vault ERC-4626 โดยมีส่วนขยายคิวการถอนแบบอะซิงโครนัสตาม epoch ที่นำไปใช้ในระดับสัญญา (contract level) ระยะเวลาการชำระบัญชีขึ้นอยู่กับโปรไฟล์สภาพคล่องของกลยุทธ์พื้นฐาน และอาจอยู่ภายใต้ข้อจำกัดระดับ vault, เหตุการณ์การระงับ และข้อกำหนดอื่นๆ ที่กำหนดไว้ในเอกสาร vault ที่เกี่ยวข้อง
