MetaLeX OS v.1 cung cấp một hệ thống mạnh mẽ và có thể tùy chỉnh để thiết lập, giám sát và vận hành các hợp đồng thông minh đa chữ ký có trách nhiệm quản trị, được tối thiểu hóa sự tin cậy, tự động hóa giao dịch và được tối ưu hóa về mặt pháp lý. Bài viết này phân tích kiến trúc và các tính năng chính của MetaLeX OS. Vì giao thức này được thiết kế chủ yếu để sử dụng với các anization ORG cy Bernetic —các sắp xếp trong đó một đa chữ ký được 'gói' bởi một thực thể pháp lý và các điều khoản hợp đồng pháp lý cụ thể chi phối việc sử dụng đa chữ ký đó—chúng tôi thường gọi các đa chữ ký được vận hành thông qua MetaLeX OS là ' BORG '.
Bối cảnh – SAFEs
MetaLeX OS được xây dựng dựa trên giao thức SAFE chuẩn (một trong những giao thức an toàn nhất, được thử nghiệm thực tế và kiểm toán trong toàn bộ lĩnh vực tiền mã hóa), tận dụng hai móc quan trọng để mở rộng mã đó: “Guards” và “Modules”.
Người bảo vệ.
SAFE Guards là hợp đồng thông minh hạn chế hoạt động của một SAFE chuẩn, cung cấp quyền truy cập được kiểm soát cho những người nhận và hợp đồng cụ thể. Điều này được thực hiện bằng cách áp đặt các kiểm tra trước giao dịch và kiểm tra sau giao dịch lên SAFE. Guards 'bảo vệ SAFE', như nó vốn có. Nếu các kiểm tra không được thỏa mãn bởi một giao dịch nhất định, giao dịch sẽ không được thực hiện ( hay còn gọi là 'hoàn nguyên').
Guard được thêm vào SAFE bằng cách gọi hàm setGuard() của SAFE với đa số hoặc số nhiều chữ ký cần thiết, được tham số hóa theo địa chỉ hợp đồng thông minh của Guard. SAFE có thể quản lý nhiều Guard thông qua hợp đồng GuardManager trung gian. Một trường hợp sử dụng điển hình sẽ chỉ cho phép 'chủ sở hữu' của SAFE (được xác định theo địa chỉ) thực hiện giao dịch (hữu ích cho việc bảo vệ MEV ) hoặc chỉ cho phép SAFE tương tác với một số hợp đồng thông minh được liệt kê trắng thông qua một số hàm được liệt kê trắng trên các hợp đồng thông minh đó (hữu ích để ngăn chặn các giao dịch vô tình hoặc để hạn chế việc sử dụng tiền ).
Các bảo vệ hạn chế SAFE .
Mô-đun.
Mô-đun là hợp đồng thông minh mở rộng hoặc sửa đổi chức năng của một SAFE tiêu chuẩn. Chúng có thể thực hiện các giao dịch trên SAFE chưa được đa số hoặc số lượng chữ ký cần thiết chấp thuận riêng lẻ. Một Mô-đun được thêm vào SAFE bằng cách gọi hàm enableModule() của SAFE với đa số hoặc số lượng chữ ký cần thiết, được tham số hóa thành địa chỉ hợp đồng thông minh của Mô-đun. Một SAFE có thể quản lý nhiều Mô-đun thông qua hợp đồng ModuleManager . Các trường hợp sử dụng điển hình sẽ là cấp cho một tài khoản khác một 'khoản trợ cấp' hàng tháng mà tài khoản đó có thể chi tiêu từ tài sản của SAFE, khóa thời gian cho quyền nâng cấp mà SAFE có thể thực hiện qua giao thức DeFi hoặc tạo điều kiện cho chức năng 'ragequit' theo kiểu Moloch , trong đó người ký có thể thoát khỏi đa chữ ký với một phần tài sản tương ứng.
Các mô-đun mở rộng SAFE.
BORGcore - Trái tim của tất cả BORG
Mỗi BORG trên MetaLeX OS đều có hợp đồng thông minh BORGcore ( https://github.com/MetaLex-Tech/borg-core ) làm trái tim. BORGcore là SAFE Guard kết hợp với giao diện ERC 4824 DAO chuẩn.
Chế độ BORG
BORGcore có ba chế độ: danh sách trắng, danh sách đen và không hạn chế, mỗi chế độ có các quy tắc và ràng buộc truy cập riêng, và mỗi chế độ có khả năng hỗ trợ các cấy ghép BORG ( xem bên dưới ) và theo dõi URI của các tài liệu pháp lý 'gói' BORG. Vì lý do bảo mật, các chế độ không thể thay đổi - do đó, mỗi chế độ của BORG được chọn một lần và mãi mãi, tại thời điểm triển khai hợp đồng BORGcore.
Chế độ danh sách trắng
Ở chế độ danh sách trắng, mọi giao dịch đều bị cấm – ngoại trừ những giao dịch được cho phép rõ ràng trước (tức là danh sách trắng).
Chỉ những người nhận được chấp thuận mới có thể nhận chuyển khoản khí đốt tự nhiên, tùy thuộc vào giới hạn giao dịch của từng cá nhân.
Chỉ có thể tương tác với các hợp đồng được liệt kê trong danh sách trắng và mỗi phương thức của hợp đồng được liệt kê trong danh sách trắng có thể có các ràng buộc tham số cụ thể (bao gồm các kiểu (uint, int, address, string, bytes, bool), phạm vi giá trị và các giá trị khớp chính xác).
Chế độ danh sách trắng là chế độ bảo thủ nhất và giảm thiểu sự tin cậy đối với BORG liền kề DAO. Nó thực thi quy tắc rằng các giao dịch BORG là không được phép theo mặc định. Chỉ các giao dịch (hoặc loại giao dịch) được liệt kê trắng với các tài khoản (hoặc loại tài khoản) được liệt kê trắng mới được phép—các khoản trợ cấp có thể được coi là thực thi 'chính sách' của BORG. Trong hầu hết các cấu hình BORG được khuyến nghị, các chính sách này sẽ là các quy tắc pháp lý bắt buộc được thực thi bởi hoặc có thể thực thi đối với 'wrapper' của thực thể pháp lý và nhân viên của thực thể đó.
Do đó, BORG chỉ có thể giao dịch với các bên đối tác mà nó được cho là phải giao dịch, theo cách thức, số lượng và thời điểm phù hợp với các quy tắc pháp lý của 'wrapper' pháp nhân. Trong trường hợp BORG liền kề DAO, các quy tắc pháp lý này sẽ phản ánh kỳ vọng của DAO liền kề và được chấp thuận trước. Trong trường hợp BORG độc lập, các quy tắc pháp lý này sẽ phản ánh kỳ vọng của các nhóm bên liên quan khác, chẳng hạn như cổ đông, nhà quản lý, hội đồng quản trị, v.v.
Do đó, ở chế độ danh sách mong muốn, BORGcore tạo ra một triển khai 'không thể xấu xa' của đa chữ ký để hạn chế các thực thể pháp lý và tác nhân của họ như một phần của bản chất cốt lõi là giảm thiểu sự tin cậy và ' không thể xấu xa ' của tiền mã hóa.
Chế độ BORG này phù hợp nhất với các BORG xử lý số tiền lớn - ví dụ, một finBORG đang quản lý giá trị 'thuộc về giao thức' hoặc 'có lợi cho giao thức' bằng cách di chuyển thanh khoản giữa nhiều nhóm thanh khoản được liệt kê trắng và các giao thức DeFi. Nó cũng có thể được sử dụng cho một BORG Tài trợ phải tuân theo các giới hạn tỷ lệ nghiêm ngặt hoặc quyền phủ quyết của DAO hoặc sự đồng chấp thuận của DAO.
Chế độ danh sách đen
Ở chế độ danh sách đen, tất cả các giao dịch đều được phép – ngoại trừ những giao dịch bị cấm rõ ràng trước (tức là danh sách đen).
Người nhận có tên trong danh sách đen không thể nhận được chuyển khoản khí đốt bản địa.
Không thể tương tác với các hợp đồng bị đưa vào danh sách đen hoặc các phương thức của các hợp đồng này sẽ bị chặn trừ khi chúng vượt qua các ràng buộc tham số đã chỉ định (bao gồm các kiểu (uint, int, địa chỉ, chuỗi, byte, bool), phạm vi giá trị và các kết quả khớp chính xác).
Chế độ danh sách đen phù hợp với các BORG liền kề DAO đáng tin cậy hơn một chút (hoặc ít rủi ro hơn một chút và do đó ít yêu cầu sự tin tưởng hơn) và do đó có thể có sự tùy ý và linh hoạt rộng rãi, nhưng liên quan đến điều này, DAO muốn hạn chế một danh sách ngắn các giao dịch đặc biệt rủi ro, nguy hiểm hoặc bị cấm. Ví dụ: một nhóm bạn quản lý một memecoin và được tin tưởng sử dụng trước khi bán diễn ra tốt đẹp, nhưng yêu cầu sự chấp thuận của người nắm giữ memecoin để tăng nguồn cung memecoin thông qua chức năng đúc trên hợp đồng thông minh mã thông báo. Trong trường hợp này, chức năng mint() trên hợp đồng mã thông báo cụ thể đó sẽ bị đưa vào danh sách đen và các cấy ghép (được giải thích bên dưới) sẽ được sử dụng để chỉ cho phép lệnh gọi mint() nếu cũng được chấp thuận bởi phiếu bầu chụp nhanh bắt buộc.
Trong cả chế độ danh sách trắng và danh sách đen, BORG có thể phải chịu thời gian chờ để gọi phương thức có liên quan nhằm ngăn chặn các cuộc tấn công DoS tương đương. Ví dụ, thời gian chờ có thể ngăn BORG gửi thư rác đến DAO với các giao dịch có thể phủ quyết để tăng chi phí giám sát/bỏ phiếu của DAO với hy vọng lén lút đưa một giao dịch mà nếu không thì DAO có thể phủ quyết. Điều này bổ sung cho các điều khoản được khuyến nghị trong các tài liệu pháp lý của BORG, trong đó cũng cấm các hoạt động lạm dụng như vậy.
Chế độ không hạn chế
Ở chế độ không hạn chế, mọi giao dịch và tương tác đều được phép mà không có hạn chế.
Không có ràng buộc nào được áp dụng cho người nhận hoặc hợp đồng.
Mọi hoạt động chuyển giao khí đốt tự nhiên và tương tác hợp đồng đều được phép.
Chế độ không hạn chế phù hợp với BORG có độ 'tin cậy' cao, trong đó người ký đa chữ ký được cho là có toàn quyền quyết định đối với hoạt động của BORG, nhưng có mong muốn sử dụng chức năng cấy ghép của MetaLeX OS ( xem bên dưới) và/hoặc chỉ sử dụng giao diện web và dịch vụ pháp lý của MetaLeX để đóng gói một SAFE không được sửa đổi. Ví dụ, điều này có thể cho phép BORG có điểm khác biệt chính so với SAFE thông thường chỉ là, không giống như trong SAFE tiêu chuẩn, người ký hiện có thể từ chức ngay lập tức và đơn phương - xem bên dưới trong phần 'ejectImplant.sol'.
BORGcore cũng quản lý quyền kiểm soát truy cập thông qua hợp đồng `BorgAuth`, đảm bảo rằng chỉ những địa chỉ được ủy quyền mới có thể sửa đổi hợp đồng thông minh của BORG. Đối với BORG liền kề DAO, điều này thường sẽ được cấu hình theo một trong ba cách sau:
BorgAuth được đặt thành địa chỉ null–tức là không thể thay đổi.
BorgAuth được thiết lập thành DAO (trên thực tế, điều này biến BORG thành một kiểu sắp xếp theo kiểu subDAO, điều này không được khuyến khích về mặt pháp lý nhưng vẫn khả thi).
BorgAuth được thiết lập theo hợp đồng tùy chỉnh yêu cầu phải có sự chấp thuận chung của DAO và BORG đối với các thay đổi.
Lựa chọn thứ ba (sự chấp thuận của DAO và BORG) là lựa chọn được khuyến nghị và phổ biến nhất, đồng thời sẽ phản ánh các điều khoản trong thỏa thuận pháp lý của BORG yêu cầu DAO chấp thuận các sửa đổi quan trọng đối với các điều khoản pháp lý trong quy tắc quản trị của pháp nhân.
Giám đốc & Người giám hộ
BORGcore có tùy chọn thiết lập "giám đốc" của BORG/đa chữ ký. Điều này nhằm mục đích hỗ trợ các cấu trúc bỏ phiếu hai lớp trong một BORG/đa chữ ký nhất định. Ví dụ, đa chữ ký 4/8 có thành viên bao gồm 3 người tạo thành Hội đồng quản trị của BORG và 5 người không nằm trong Hội đồng quản trị nhưng là người ký vào đa chữ ký vì lý do bảo mật (về cơ bản là tăng số lượng khóa và do đó tăng chi phí cho một cuộc tấn công cờ lê phối hợp, v.v.). Trong trường hợp này, chúng tôi sẽ yêu cầu ít nhất phần lớn các giám đốc phải chấp thuận mọi giao dịch, ngoài ra còn có một đến hai người không phải giám đốc (mà chúng tôi gọi trong các tài liệu pháp lý là "người giám hộ"). Loại cấu trúc này cũng có thể giảm chi phí hành chính/quy trình để thành lập pháp nhân, vì các giám đốc có thẩm quyền lớn hơn, trách nhiệm pháp lý tiềm ẩn lớn hơn và do đó phải đối mặt với các yêu cầu KYC/AML/thẩm định cao hơn so với các nhà thầu bảo mật đơn thuần. Tham số được thiết lập thông qua biến 'directorsRequired' chỉ định số lượng giám đốc tối thiểu phải chấp thuận mọi giao dịch.
BORG Implants - Mô-đun tùy chỉnh SAFE
Mỗi BORG đều có các cấy ghép điều khiển học ( https://github.com/MetaLex-Tech/borg-core/tree/main/src/implants ) giúp tăng cường khả năng của nó vượt xa khả năng của một SAFE thông thường. Mỗi Implant là một SAFE Module bao gồm một ConditionManager, một BORGauth và một bộ các quy tắc cụ thể hơn dành riêng cho implant đó.
BORGauth có thể, thông qua một Implant cụ thể, cấp cho một bên thứ ba hoặc hợp đồng thông minh bên ngoài quyền thực hiện các hành động như phủ quyết giao dịch BORG bị khóa thời gian, thu hồi tiền của BORG hoặc thêm và xóa người ký BORG. Đối với BORG liền kề DAO, BORGauth sẽ cấp quyền đối với BORG cho DAO liền kề. Đối với BORG độc lập, BORGauth sẽ cấp quyền đối với BORG cho các cổ đông (được đại diện thông qua hợp đồng bỏ phiếu của các cổ phiếu được mã hóa) hoặc một nhóm các nhà quản lý, hội đồng quản trị hoặc cơ quan tương tự được đại diện thông qua một đa chữ ký SAFE khác.
ConditionManager cho phép quyền hạn của BORGauth được điều chỉnh theo chương trình. Có thể thêm hợp đồng thông minh tùy chỉnh để xử lý bất kỳ logic có điều kiện nào được yêu cầu, bao gồm: phê duyệt chữ ký/nhiều bên, thời gian, số dư và đầu vào oracle bên ngoài. Điều này có thể đáp ứng bất kỳ điều kiện nào có thể chứng minh được trên chuỗi hoặc với một oracle đáng tin cậy để mở khóa các mốc quan trọng hoặc giải phóng tiền ký quỹ.
ConditionManager cho phép mối quan hệ giữa BORG và cơ quan có thẩm quyền liền kề được điều chỉnh thành động lực 'kiểm tra/cân bằng' của chính phủ sắc thái thay vì BORG bị kiểm soát đơn giản bởi hoặc phục tùng cơ quan có thẩm quyền. Đối với BORG liền kề DAO, chẳng hạn như BORG Grants, điều này có thể có nghĩa là, ví dụ, BORG có thể tự do cấp các khoản tài trợ lên đến một số giới hạn hàng tháng (được tính bằng đô la hoặc mã thông báo), nhưng DAO phải đồng chấp thuận hoặc có thể phủ quyết các khoản tài trợ vượt quá giới hạn đó. Đối với BORG độc lập, chẳng hạn như một tập đoàn công nghệ, điều này có thể có nghĩa là, ví dụ, những người ký BORG cũng là giám đốc của tổ chức, rằng hợp đồng thông minh để ghi lại phiếu bầu của các cổ phiếu được mã hóa là BORGauth và mỗi giám đốc phục vụ trong một nhiệm kỳ công tác cụ thể (có khả năng 'so le' với các nhiệm kỳ của các giám đốc khác) và sẽ tự động bị loại bỏ nếu không được bầu lại bằng phiếu bầu cổ phiếu được mã hóa trong vòng 30 ngày kể từ ngày kết thúc nhiệm kỳ.
Kiến trúc này và mục đích sử dụng của nó là một điểm khác biệt chính giữa MetaLeX OS và các siêu giao thức DAO và SAFE khác. Nhiều giao thức như vậy khái niệm hóa các đa chữ ký liền kề DAO là "subDAO", "minion", "avatar", "squad" hoặc các cấu trúc tương tự được xử lý giống như các công ty con, tác nhân hoặc đại diện của DAO. Một số khác lại coi các đa chữ ký như vậy là 'hội đồng' 'quản lý' DAO thông qua 'ủy quyền'. Trong khi MetaLeX OS chắc chắn có thể tạo điều kiện cho những mối quan hệ tương tự như vậy, thì triết lý thiết kế BORG khuyến khích và MetaLeX OS tạo điều kiện cho một động lực kiểm tra và cân bằng tinh tế hơn giữa DAO và BORG—khiến chúng chủ yếu độc lập với nhau trong khi vẫn chịu trách nhiệm lẫn nhau. Điều này rất quan trọng để triển khai các chiến lược pháp lý tối ưu*.
*( Xem https://www.law.cornell.edu/wex/alter_ego . Sự tách biệt như vậy cũng quan trọng xét về góc độ thuế).
GrantsBORGs, loại BORG đầu tiên được triển khai đầy đủ trên MetaLeX OS, có thể có các tính năng sau:
OptimisticGrantImplant.sol
Cho phép GrantsBORG trao các khoản tài trợ "một cách lạc quan" bằng cách sử dụng các quỹ do DAO liền kề cấp, tùy thuộc vào các giới hạn và mức trần theo chương trình. GrantsBORG có thể vượt quá các giới hạn và/hoặc mức trần với sự chấp thuận chung của DAO hoặc tùy thuộc vào thời gian khóa + không có quyền phủ quyết của DAO. Trong trường hợp lý tưởng, lớp vỏ pháp nhân vẫn sẽ hạn chế các khoản tài trợ lạc quan nằm trong các mục đích được DAO chấp thuận (chẳng hạn như hỗ trợ hệ sinh thái cụ thể liên quan) và tuân theo một số quy tắc ngoài chuỗi nhất định (chẳng hạn như không cấp tài trợ cho nhân viên GrantsBORG hoặc các chi nhánh tương ứng của họ).
daoVETOGrantImplant.sol và vetoImplant.sol
Cho phép mẫu khóa thời gian + phủ quyết DAO đã đề cập ở trên cho các trường hợp ngoại lệ đối với giới hạn và mức trần tỷ lệ của GrantsBORG. Điều này cũng bao gồm các biện pháp chống DoS để BORG không thể áp đảo khả năng phủ quyết của DAO thông qua các đề xuất 'thư rác' (lý tưởng nhất là nên bổ sung các quy tắc pháp lý chống trốn tránh trong trình bao bọc pháp lý của BORG). Cũng có thể được định cấu hình để yêu cầu phê duyệt trước cho mỗi loại mã thông báo và có giới hạn cho mỗi lần cấp. Hai hợp đồng thực hiện điều này cho DAO đầy đủ và DAO theo kiểu ảnh chụp nhanh.
daoVoteGrantImplant.sol
Cho phép áp dụng mô hình đồng chấp thuận DAO đã đề cập ở trên đối với các trường hợp ngoại lệ đối với giới hạn và mức trần tỷ lệ của GrantsBORG.
ejectImplant.sol
Cho phép người ký đa chữ ký GrantsBORG từ chức theo ý muốn của họ hoặc để DAO xóa người ký đa chữ ký GrantsBORG. Khi kết hợp với quyền kiểm soát DAO của phiên bản MetaVest được sử dụng để trả lương cho nhân viên GrantsBORG, cơ chế từ chức có thể là một cách mạnh mẽ để DAO gây ảnh hưởng đến BORG mà không thực sự có thẩm quyền giống như cổ đông để thêm và xóa thành viên BORG. Xem “MetaVest” và “Kiểm tra & Cân bằng” bên dưới.
failSafe.sol
Cho phép tiền quay trở lại DAO (hoặc một địa chỉ khác) khi có các sự kiện cụ thể—ví dụ: nếu số lượng người ký BORG giảm xuống dưới ngưỡng tối thiểu cần thiết để phê duyệt các hành động trên SAFE. Địa chỉ đích (thường là kho bạc DAO) được đặt ở chế độ triển khai và không thể thay đổi. Giống như các Implant khác, điều này có thể được kết hợp với ConditionManager để cho phép thu hồi được kích hoạt chỉ bằng phê duyệt DAO hoặc phê duyệt DAO + số lượng điều kiện hoặc phê duyệt khác. Điều này có thể dẫn đến một số chiến lược thú vị để ứng phó với các sự kiện bất lợi—xem “MetaVest” và “Lý thuyết trò chơi cho BORG” bên dưới. Tuy nhiên, cộng đồng DAO và BORG liên quan nên cẩn thận để hiểu các rủi ro của DAO khi duy trì kho bạc đa dạng , chẳng hạn như nằm trong các quy định của nhóm hàng hóa hoặc công ty đầu tư; do đó, điều này phải được coi là biện pháp bảo mật quỹ nghiêm ngặt và nếu được kích hoạt, cộng đồng DAO nên tập hợp lại để tạo BORG thay thế để nắm giữ các tài sản không phải gốc đã quay trở lại từ BORG (có khả năng không còn tồn tại) sang DAO.
LeXscroW - Ký quỹ Cybernetic
LeXscroW ( https://github.com/MetaLex-Tech/LeXscroW ) là một thành phần quan trọng của MetaLeX OS, được thiết kế để cung cấp các hợp đồng thông minh ký quỹ bất biến, không lưu ký và có điều kiện linh hoạt. Các hợp đồng ký quỹ này được xây dựng dựa trên kinh nghiệm của nhóm MetaLeX OS với các giao dịch thực tế và việc sử dụng các tác nhân ký quỹ trong đó. LeXscroW tăng cường hệ sinh thái MetaLeX OS bằng cách đảm bảo các giao dịch an toàn, tự động và được tối ưu hóa về mặt pháp lý liên quan đến BORG—thực thi “logic giao dịch” thường được giao phó cho các thỏa thuận pháp lý dài dòng và các quy trình thủ công, thay vào đó là cho blockchain.
Các tính năng cốt lõi chung cho tất cả LeXscroW bao gồm:
Triển khai không có chủ sở hữu : Hợp đồng được triển khai mà không có 'chủ sở hữu', đảm bảo rằng không một thực thể nào có thể thay đổi các điều kiện sau khi hợp đồng có hiệu lực.
Điều kiện không thay đổi : Điều kiện thực hiện có thể bao gồm chữ ký, ràng buộc thời gian, dữ liệu do oracle cung cấp, v.v. Các điều kiện này không thay đổi khi triển khai, giảm thiểu sự tin cậy khi thực thi logic thỏa thuận.
Tính linh hoạt của người gửi tiền : Hợp đồng có thể chỉ định các bên gửi tiền hoặc cho phép bất kỳ địa chỉ nào gửi tiền, hỗ trợ cả các thỏa thuận đã đàm phán với các bên đối tác cụ thể được sắp xếp trước và các đề nghị mở (bao gồm cả tùy chọn cho bên gửi tiền từ chối một bên chấp nhận tiềm năng, trên cơ sở sau đó ).
LeXscroW cung cấp nhiều loại hợp đồng ký quỹ thông minh, mỗi loại được thiết kế riêng theo nhu cầu giao dịch cụ thể.
1. DoubleTokenLexscroW
Giao dịch song phương: Được thiết kế cho các giao dịch ký quỹ thông minh song phương liên quan đến hai mã thông báo ERC20 khác nhau.
Điều kiện thực hiện: Hợp đồng sẽ được thực hiện và giải phóng mã thông báo cho cả hai bên nếu tất cả các điều kiện được đáp ứng trước khi hết hạn.
2. TokenLexscroW
Giao dịch đơn phương: Tạo điều kiện cho các giao dịch ký quỹ thông minh đơn phương cho một mã thông báo ERC20 duy nhất.
Thực hiện và hoàn tiền: Mã thông báo được trả cho người bán khi đáp ứng các điều kiện hoặc được hoàn lại cho người mua nếu hợp đồng hết hạn mà không được thực hiện.
Từ chối người gửi tiền: Người bán có thể từ chối người gửi tiền, kích hoạt cơ chế rút tiền đối với khoản tiền gửi bị từ chối.
3. EthLexscroW
Giao dịch mã thông báo gốc: Xử lý ký quỹ cho mã thông báo gas gốc (ví dụ: ETH) với các điều kiện và chức năng tương tự như TokenLexscroW.
LeXscroW tích hợp liền mạch với kiến trúc BORG trong MetaLeX OS, tăng cường bản chất tối thiểu hóa sự tin cậy, chịu trách nhiệm quản trị của các giao dịch BORG. Mỗi BORG trên MetaLeX OS có thể kết hợp các hợp đồng LeXscroW để quản lý các quỹ ký quỹ, đảm bảo rằng các giao dịch tuân thủ cả các điều kiện hợp đồng thông minh và các quy tắc pháp lý chi phối hoạt động của BORG. Điều này cho phép BORG linh hoạt hơn một chút, đồng thời vẫn duy trì được sự tin cậy tối thiểu—các giao dịch không thể lường trước được khi DAO ban đầu ủy quyền cho BORG vẫn có thể được triển khai theo cách tự động thực thi logic giao dịch có liên quan.
Ví dụ, GrantsBORG có thể sử dụng LeXscroW để xử lý việc chuyển đổi một số token quản trị OpsBudget thành stablecoin thông qua TokenLeXscroW cung cấp dịch vụ bán token quản trị với mức chiết khấu cụ thể so với giá thị trường, kèm theo mức khóa cụ thể - về cơ bản là một đề nghị bán token OTC đơn phương.
Ngoài việc tăng cường các chức năng BORG truyền thống, LeXscroW còn cải thiện đáng kể khả năng "công nghệ giao dịch" trong MetaLeX OS, hỗ trợ các giao dịch an toàn và minh bạch giữa nhiều thực thể khác nhau:
Giao dịch BORG-to-BORG: LeXscroW cho phép các BORG tham gia vào các giao dịch phức tạp với nhau, đảm bảo rằng tiền chỉ được giải ngân khi các điều kiện cụ thể được đáp ứng. Điều này tăng cường sự tin tưởng và hiệu quả hoạt động giữa các BORG khác nhau.
Giao dịch DAO-to-BORG: DAO có thể sử dụng LeXscroW để tài trợ an toàn cho BORG, đảm bảo rằng các khoản tiền được sử dụng theo các điều kiện và mốc thời gian được xác định trước. Cơ chế này hỗ trợ quản trị và trách nhiệm giải trình trong DAO, đồng thời cung cấp quyền tự chủ hoạt động cho BORG.
Giao dịch DAO-to-DAO: LeXscroW tạo điều kiện cho các giao dịch an toàn và có điều kiện giữa các DAO khác nhau, cho phép các dự án hợp tác và sáng kiến tài trợ. Bằng cách đảm bảo rằng tất cả các điều kiện được đáp ứng trước khi giải ngân, LeXscroW thúc đẩy sự tin tưởng và hợp tác giữa các DAO riêng biệt.
Về cơ bản, nó tích hợp kỹ thuật số vào một bộ quy tắc mà hai thực thể có thể tuân thủ, mô phỏng cách các công ty và tổ chức thông thường tạo ra các thỏa thuận và đảm bảo khi tương tác với nhau, nhưng theo cách an toàn và giảm thiểu sự tin cậy hơn.
Các trường hợp sử dụng thú vị
LeXscroW có thể được áp dụng trong nhiều tình huống khác nhau để nâng cao chức năng và độ tin cậy của các giao dịch trong hệ sinh thái MetaLeX OS:
1. Ký quỹ trong sáp nhập và mua lại (M&A):
Kịch bản: Hai DAO hoặc 'giao thức' đồng ý sáp nhập và giao dịch liên quan đến việc trao đổi mã thông báo và tài sản phức tạp.
Giải pháp LeXscroW: Có thể thiết lập hợp đồng DoubleTokenLexscroW để xử lý việc hoán đổi token, với các điều kiện đảm bảo tất cả các phiếu bầu DAO, hành động BORG và các điều kiện tiên quyết khác được đáp ứng trước khi các token được trao đổi. Điều này đảm bảo rằng cả hai DAO đều có thể tin tưởng vào quy trình mà không cần trung gian.
2. Hoán đổi mã thông báo không cần tin cậy:
Kịch bản: Hai BORG hoặc DAO muốn trao đổi token trực tiếp mà không cần thông qua các sàn giao dịch tập trung.
Giải pháp LeXscroW: Sử dụng DoubleTokenLexscroW, mỗi bên gửi token tương ứng của mình vào hợp đồng. Việc hoán đổi chỉ được thực hiện khi cả hai bên đã gửi số tiền cần thiết và bất kỳ điều kiện bổ sung nào (chẳng hạn như nguồn cấp giá được xác nhận bởi oracle) đều được đáp ứng. Điều này tạo ra một môi trường an toàn và không cần tin cậy cho các giao dịch token.
3. Các mốc quan trọng về tài trợ dự án:
Kịch bản: DAO tài trợ cho một dự án do BORG quản lý, với số tiền được giải ngân dựa trên các mốc quan trọng của dự án.
Giải pháp LeXscroW: Hợp đồng TokenLexscroW có thể được sử dụng để giữ tiền, giải phóng chúng theo từng bước khi đạt được và xác minh các mốc được xác định trước, thông qua các sự kiện trên chuỗi hoặc các oracle đáng tin cậy. Điều này đảm bảo rằng dự án đang tiến triển theo đúng kế hoạch trước khi giải phóng từng đợt tiền tài trợ.
4. Hợp tác giữa các DAO:
Kịch bản: Nhiều DAO hợp tác trong một liên doanh, mỗi DAO đóng góp tiền hoặc nguồn lực.
Giải pháp LeXscroW: Có thể thiết lập hợp đồng EthLexscroW hoặc TokenLexscroW để quản lý các nguồn tài nguyên chung, giải ngân theo các mốc đã thỏa thuận, các điều kiện phản ánh tiến độ và đóng góp của từng DAO hoặc phê duyệt theo lớp (về cơ bản là phê duyệt của một đa chữ ký ảo của DAO và BORG). Điều này thúc đẩy sự hợp tác và đảm bảo tính minh bạch trong việc quản lý các nguồn tài nguyên được chia sẻ.
5. Cá cược:
Kịch bản: Hai KOL trên Twitter đặt cược 1 triệu đô la Mỹ rằng ETH sẽ đạt 10.000 đô la vào cuối năm 2024.
Giải pháp LeXscroW: TokenLexscroW kết nối với một oracle theo dõi giá ETH và tự động giải ngân cho người chiến thắng dựa trên giá của oracle.
Bằng cách tích hợp các hợp đồng ký quỹ bất biến, điều khiển theo điều kiện, LeXscroW đảm bảo các giao dịch an toàn, minh bạch và hiệu quả, do đó củng cố độ tin cậy và chức năng của MetaLeX OS. Sự tích hợp này đặc biệt mạnh mẽ trong việc tạo điều kiện cho các giao dịch phức tạp, giảm thiểu sự tin cậy giữa BORG, DAO và các thực thể khác, thúc đẩy tầm nhìn về các Tổ chức cyBernetic được tối ưu hóa về mặt pháp lý, chịu trách nhiệm quản trị.
MetaVesT - Quyền sở hữu được tối thiểu hóa sự tin cậy nâng cao
MetaVesT ( https://github.com/MetaLex-Tech/MetaVesT ) là một giao thức khóa/phân bổ token tương thích với BORG và có thể tối ưu hóa về mặt pháp lý (đặc biệt là tối ưu hóa về mặt thuế) cho các token tương thích với ERC20. Giống như các giao thức 'phân bổ' token khác (Hedgey, v.v.), nó hỗ trợ các phân bổ token cơ bản được truyền trực tuyến đến người được cấp theo thời gian. Tuy nhiên, MetaVesT cũng hỗ trợ các thỏa thuận cấp token phức tạp và tinh vi hơn nhiều, phản ánh cách các thỏa thuận token hợp pháp được soạn thảo trong thế giới thực. Các tính năng này bao gồm:
cơ chế giải phóng mã thông báo đường cong kép (hỗ trợ các khoản trợ cấp mã thông báo được “trao” (tức là được kiếm được ) và “mở khóa” (tức là được giải phóng khỏi các hạn chế chuyển nhượng) ở các nhịp khác nhau, với mỗi đường cong có khả năng có 'vực thẳm' riêng biệt;
cơ chế trao thưởng quyền chọn mã thông báo và lệnh chứng quyền mã thông báo (hỗ trợ việc thiết lập giá thực hiện tại thời điểm cấp và việc thanh toán sau đó giá thực hiện đó bằng stablecoin của bên được cấp để mua các mã thông báo 'đã được trao'—điều quan trọng đối với cơ cấu thuế khi các khoản tài trợ được trao sau khi một mã thông báo đã thanh khoản và có giá cao);
cơ chế trao thưởng token bị hạn chế (hỗ trợ việc thiết lập giá mua lại tại thời điểm cấp và việc thanh toán sau đó giá mua lại đó bằng stablecoin của bên cấp để mua lại các token 'chưa được trao'—điều quan trọng đối với việc xây dựng cơ cấu thuế khi các khoản tài trợ được trao khi token ở trạng thái trước thanh khoản và có giá thấp);
cơ chế sửa đổi nhóm (phần lớn giá trị của người được cấp + bên cấp có thể sửa đổi các khoản tài trợ tượng trưng cho mọi người trong cùng một nhóm—phản ánh cơ chế sửa đổi kế hoạch khuyến khích vốn chủ sở hữu và cơ chế chứng quyền SAFT/token của nhà đầu tư mạo hiểm trong đó không phải tất cả nhân viên/nhà đầu tư đều cần phải đồng ý với sửa đổi để có hiệu lực);
“không thể xấu xa” /bảo đảm chống lại việc trao quyền sở hữu thảm—khi được cấu hình như vậy, tính năng duy nhất của MetaVesT có thể được bên cấp quyền thay đổi đơn phương là (nếu có thể) chấm dứt việc trao quyền sở hữu (phản ánh việc chấm dứt dịch vụ “tùy ý” của một nhà thầu độc lập)—tất cả các thay đổi khác đều yêu cầu sử dụng cơ chế sửa đổi theo sự đồng thuận, giống như đối với các thỏa thuận pháp lý trong thế giới thực (và tất nhiên, bên cấp quyền không thể tùy ý thay đổi các mã thông báo đã trao quyền);
bỏ phiếu DAO thông qua (các mã thông báo chưa được trao và/hoặc bị khóa vẫn có thể được đặt cược và bỏ phiếu trong DAO)—quan trọng đối với các cơ chế trao thưởng mã thông báo bị hạn chế, trong đó người được trao tặng được cho là chủ sở hữu hợp pháp của các mã thông báo bất chấp việc tiếp tục khóa và/hoặc quyền mua lại;
các mốc quan trọng—cho phép việc trao quyền dựa trên sự kiện thay vì dựa trên thời gian trôi qua; và
Trách nhiệm giải trình của DAO—ví dụ, cho phép DAO sa thải một nhân viên hoặc khuyến khích mạnh mẽ một nhân viên nghỉ việc bằng cách chấm dứt quyền sở hữu các khoản trợ cấp mã thông báo của nhân viên đó.
MetaVesT có thể được sử dụng để làm trung gian cho việc trao quyền cho nhân viên BORG vào khoản bồi thường mà họ nhận được từ DAO, và để làm trung gian cho việc trao quyền cho các khoản tài trợ từ GrantsBORG cho người nhận tài trợ. Ví dụ, GrantsBORG có thể sử dụng MetaVesT để xử lý việc giải ngân một loại tài trợ tùy chỉnh với các điều khoản phức tạp. Bằng cách đặt các điều kiện cụ thể để giải ngân, chẳng hạn như các thành tựu quan trọng hoặc trao quyền theo thời gian, hoặc kết hợp cả hai, GrantsBORG có thể đảm bảo rằng các khoản tiền chỉ được giải ngân khi các tiêu chí được xác định trước được đáp ứng. Điều này có thể bao gồm sự kết hợp giữa thời gian trôi qua cộng với một số điều kiện của oracle — như một mã thông báo đạt đến một mức giá cụ thể — được đáp ứng. Cơ chế này không chỉ tự động hóa quy trình giải ngân tài trợ mà còn đảm bảo tuân thủ các mục đích đã được DAO chấp thuận và các quy tắc ngoài chuỗi. MetaVesT cũng có thể được ghép nối với LeXscroW để có khả năng lập trình bổ sung.
So với các giao thức mở khóa/trao quyền token khác, MetaVesT có các tính năng khác nhau được tối ưu hóa hơn cho triết lý luật điều khiển học, DAO và BORG. Ngoài ra, không giống như một số giao thức khác, nó vừa có sẵn mã nguồn vừa là mã nguồn mở. Nó được thiết kế để trở thành giải pháp theo phong cách DeFi và dựa trên quản trị cho các thỏa thuận mở khóa/trao quyền token hợp pháp - tương tự nhất với Hedgey, nhưng có thêm các tính năng được tối ưu hóa cho triết lý luật điều khiển học của chúng tôi - so với giải pháp 'theo phong cách quản trị viên' tập trung như Toku. Chúng tôi không tin rằng việc mở khóa/trao quyền token nên phụ thuộc vào ý thích của bất kỳ cơ quan trung ương nào - cho dù đó là 'devco' hay công ty SaaS như MetaLeX. 'Không thể xấu xa' vẫn tốt hơn 'không được xấu xa'.
Cấu hình ví dụ – GrantsBORG
MetaLeX OS là một bộ công cụ cực kỳ giàu tính năng và có thể tùy chỉnh cực cao, cho phép bạn có về cơ bản bất kỳ tùy chỉnh nào mà BORG cần. Sau khi đã nêu bật nhiều tính năng của nó, giờ đây, việc nghiên cứu sâu hơn về triển khai cụ thể, có ý kiến của một BORG liền kề DAO cụ thể, thảo luận về cách nó có thể được thiết lập cả về mặt kỹ thuật và pháp lý, và khám phá 'lý thuyết trò chơi' về động lực kiểm tra/cân bằng kết quả giữa BORG và DAO liền kề/tài trợ của nó là rất hữu ích.
Với mục đích này, chúng tôi sẽ khám phá những gì chúng tôi coi là thiết lập GrantsBORG liền kề DAO điển hình/được khuyến nghị, được mô tả bên dưới. LƯU Ý: Đây chỉ là một cấu hình 'có ý kiến' mà chúng tôi nghĩ là có thể phù hợp với mục đích của hầu hết các dự án; tất nhiên chúng tôi có thể làm việc với khách hàng để cấu hình nhiều cấu hình thay thế, theo nhu cầu cộng đồng và triết lý quản trị của từng cá nhân. Chúng tôi thực sự khuyên bạn nên cân nhắc nhu cầu của BORG và tùy chỉnh thiết lập của nó thay vì sử dụng điều này làm mẫu
Nói một cách chính xác hơn, thiết lập cơ bản của một Grants BORG chuẩn liền kề DAO sẽ là:
5. một chữ ký đa SAFE riêng biệt để chứa từng nhóm này—Ops Multisig và Grants Multisig;
12. Kết nối Grants Multisig với MetaLeX OS:
Kết luận & Phiên bản trong tương lai
LeXscroW:
MetaVesT:
Kiểm toán Mixbytes:
https://github.com/mixbytes/audits_public/tree/master/MetaLeX
Zellic Audit (chỉ dành cho MetaVesT):
Luật điều khiển học hiện nay.
