Cybernetic Legal Agreements -
A New Drafting & Legal Templating Technique
At MetaLeX, our mission is to make organizations and agreements cybernetic. In pursuing this mission over the last year, we have invented a new technique for handling the 'legal side' of law/tech dyads to optimize them for our applications--we call the resulting legal texts "cybernetic law templates".
The Current State of Things
Automated contract generation and contract management are mainstays of the legal tech industry, but currently suffer from three major flaws or limitations.
Walled Gardens.
Contract generation/management tools are currently dominated by enterprise cloud SaaS platforms operating as "walled gardens". These suffer from all the drawbacks and adverse incentives of web2 solutions in general:
centralized
intermediated/rent-seeking
closed-access
closed-source
non-interoperable
non-composable
passive/static
2. Human-Optimized Instead of Systems-Optimized
The phenomenology of these applications is implicitly skeuomorphic--viewing legal agreements as statically ordered piles of paper full of statically sequenced words designed for human beings to sit down and read and interpret. Thus, users are walked through "questionnaires"--as if dialoguing with a lawyer--and the software then invisibly uses the "answers" to generate a PDF or similar document file, which is then graphically signed (as if with a pen) in an e-signature application and stored in the cloud, as if in a file cabinet.
What this approach ignores is that we now have autonomous technologies that can make most reading and interpretation of legal documents irrelevant, since automated performance through code is possible. Legal agreements, and how we express them, now need to be optimized primarily for autonomous execution within systems and only secondarily for human reading/interpretation--human hermeneutics will become a mere backup system.
3. Template Invisibility
Under the current legal doc automation approach, legal agreement templates are non-public outside of individual orgs, and often even invisible and untouchable except for a small handful of admins within a given org.
When the only 'document' seen by a user is a version that has been fully customized in response to a user's answers to questions, and the underlying 'legal template' and all its parameters remain hidden to the user (they are essentially an unreadable JSON blob), important choices, details, and opportunities for creativity are obscured.
In contrast, the history of the evolution of agreements is driven by standardization within a framework of debate and visibility. Famous "standard forms" with menus of parameters include the Y-Combinator SAFE, the National Venture Capital Association Model Legal Documents for venture financings, the Waypoint NDA, and the American Bar Association Model Legal Agreements. These agreement templates are powerful because they provide open standards that have continued to be debated and improved upon in a close-to-open-source manner (albeit still with some legal professional gatekeeping), in some cases over the course of decades.
A hidden "data object" within a walled garden, tied in somewhat opaque ways into an evanescent questionnaire logic, is unlikely become or result in contributions to any such standards.
To summarize: current contract management solutions are designed to take humans out of the loop in ways they should remain in the loop, and designed to leave humans in the loop in ways they should be out of the loop. A deeply flawed dynamic, all around.
The MetaLeX Approach
MetaLeX envisions a new era of onchain standard legal agreements that are modular, composable, interoperable and systems-friendly and can evolve based on the open-source ethos.
To start getting there, we have begun styling standardized legal agreement templates that directly reference onchain data structures in their text. This makes the templates easily usable with Ricardian Triplers that can deploy smart contracts to enforce the legal agreements and enables anyone to enter into an agreement onchain without generating a new legal 'text'. If the selected parameters for the template's variables are stored on a public blockchain, it also means there is no 'vendor lock-in' or 'walled-gardening' for legal tech, as anyone can build a web app that displays anyone's agreements for them in a more convenient, traditional format--e,g, by combining an IPFS-stored template with onchain data objects to display a legal agreement text that looks more traditional. An internet of agreements.
A very simple example is a BORG Participation Agreement we prepared for the Curve emergency multisig to 'wrap' it in a Cayman Islands Foundation. This enabled the existing multisig members to sign an agreement whereby they would join a Cayman Islands Foundation and conduct their future activities for that multisig in service to that entity:
As you can see, the text here is a template rather than trying to be the final agreement. To generate a final agreement, a user selects values for the template's variables (like those for the individual signing party and the party's contact details for legal notices, etc.) and stores these onchain with a signature, through another smart contract (referred to here as the Ricardian Tripler--more info on that here). The template should be stored on a decentralized storage solution like IPFS to allow for hash verification.
Another example comes from our recent CyTE app, which uses the Cybernetic Token Exchange Agreement (CyTEA).
The actual agreement of a given party is the combination of this template with the parameter selections and signatures that are stored onchain. Although smart contracts are not not the same as legal agreements, and we are not fans of conflating the two, we do believe some logic can be learned from smart contracts by legal agreement drafters. Just like there is one .sol source code file that can get *deployed* as many identical instances--individual smart contracts--so, too, cybernetic legal agreements are legal 'source code' (templates) that get instantiated as individual agreements by setting the parameters and signing onchain.
As a result, the agreement can be confirmed, performed, and interpreted by any person or system. For example, in our Cybernetic Token Exchanger app, a cybernetic legal agreement's parameters are shared with a smart contract token escrow that enforces the agreement's terms and conditions.
Importantly, the fact that a given agreement conforms to a particular template standard is completely verifiable. In contrast, to confirm that a particular document called a "SAFE" conforms to the Y-Combinator "SAFE" template, it's necessary to manually run redlines between the two texts. Any venture capital lawyer will know that deviations are in fact very common--and can be insidious!
Any agreement template can be adapted to use this technique with immediate gains in openness, composability, automation, and verifiability.
Limitations & Improvements for Future Versions
Privacy. Our current technique results in agreements that are public by default, as anyone can identify the template and the parameters selected by parties and their signatures to infer the full agreement. DAOs are ideal playgrounds for public solutions, as their dealmaking should generally be transparent. But to scale beyond DAOs, privacy will be needed. Obviously, not all legal agreements can or should be public. For example, you probably don't want your Last Will & Testament or your Prenuptial Agreement to be public! Luckily, our technique lends itself well to adding privacy in the future, as it enables a legal template to remain public and evolve over time, while any given agreement formed from that template could remain private (by making the parameters and signatures private)--despite the privacy of the data, the the fact that the agreement is an instance of the template should be easily verifiable by anyone who has a reason to care (think about third-party due diligence, as in prospective venture financings or M&A transactions). These combinations of privacy with verifiability can be achieved in the future through some combination of using encrypted rollups, ZK-proofs and/or offchain data processed by a restaking-secured AVS.
Tokenization . Cybernetic legal agreements should allow the parties to toggle a variable that elects that the agreement be represented by tokens (likely NFTs) that serve as potentially transferable legal instruments., and such tokens should be automatically generated during the agreement signing process (probably through a Ricardian Tripler). For example, in a bilateral agreement between Party A and Party B, Party A would receive an NFT representing Party A's rights under the agreement and an NFT representing Party B's obligations/liabilities under the agreement, and Party B would receive an NFT representing Party B's rights under the agreement and an NFT representing Party A's obligations/liabilities under the agreement. These tokens could be programmed with their own dividend and claims logic to help automate the agreement performance lifecycle, could have toggles for transferability based on mutual agreement or events like the bankruptcy of a party, and could form a foundation for new onchain cybernetic law solutions like breach insurance and lending arrangements collateralized by future performance obligations. Tokenization is a massive feature unlock.
Naturalness/Legibility. Future cybernetic agreement templates can likely be made more legible/natural-looking than our current versions, by removing code and data object references from the main body of the agreement text and adding more defined terms (tied to such code and data objects) in the definitions section at the back. This has only been done partially in this version, not universally--in part this was because cybernetic agreements are a new primitive and we want to highlight rather than hide how they actually work, at least until people get more used to them. Also, there is an alternative approach that would lean more heavily on our web application (see next bullet) and so it makes sense to leave some room for that possibility.
Reconstruction to Natural Language. Cybernetic legal agreements should have no worse UX than traditional legal contract assembly tools. A web application specialized for managing cybernetic legal agreements should have the ability to do 'just-in-time' display of normal-looking legal agreements by combining the IPFS-stored template with the onchain data that records the actual variable selections for a specific agreement between parties to provide TradLaw agreement UX. For the user, this would feel the same as reading an old-school contract--the smart contract variables in the template would be replaced by words, optionally with the ability to toggle them back to a display of underlying the smart contract variables with a mouse hover or highlight.
Legal Formalism. Cybernetic law agreements should not just have a few machine-readable variables, but should be completely machine-readable, machine-generatable, and formalized. Efforts in this direction include research into
composable contracts and computational law by projects such as ContractCheck, Common Form andLegalese. At some point, we could incorporate these tools into our solution for increased machine-readability and to give users the power to generate custom cybernetic agreements on the fly rather than just rely on templates--importantly, without reliance on third-party enterprise solutions.
MetaLeX plans to add more and more features like the above as we evolve.
Links
Cybernetic Token Exchange Agreement (CyTEA) https://ipfs.io/ipfs/bafybeigly6iaehdyzyyhrleu3e6yveum2v2gyczkrvmqpjtaty2wp424ti
MetaLeX Cybernetic Token Exchange App (CyTEA), using CyTE https://app.metalex.tech/lexscrow
Credits