MetaLeX OS – Under the Hood
The heart of the machine…..
The heart of the machine…..
Today MetaLeX is proud to present version 1 of MetaLeX OS, a full software and legal suite designed to manufacture and design custom BORGs that are tailor made to create a full separation of powers between the real and digital world.
MetaLeX OS v.1 provides a powerful and customizable system for establishing, monitoring, and operating governance-accountable, trust-minimized, transaction-automated and legally optimized multisig smart contracts. This article breaks down MetaLeX OS’s architecture and key features. Because the protocol is designed primarily for use with cyBernetic ORGanizations—arrangements in which a multisig is ‘wrapped’ by a legal entity and specific legal contract terms govern the use of that multisig—we generally refer to the multisigs operated through MetaLeX OS as ‘BORGs’.
Background – SAFEs
MetaLeX OS is built around the standard SAFE protocol (among the most secure, battle-tested and audited protocols in all of crypto), leveraging the two important hooks for extending that code: “Guards” and “Modules”.
Guards.
SAFE Guards are smart contracts that constrain the functioning of an otherwise standard SAFE, providing controlled access to specific recipients and contracts. This is accomplished by imposing pre-transaction-checks and post-transaction-checks on the SAFE. Guards ‘safeguard the SAFE,’ as it were. If the checks are not satisfied by a given transaction, the transaction will not execute (aka ‘reversion’).
A Guard is added to a SAFE by calling the setGuard() function of the SAFE with the requisite majority or plurality of signatures, parametrized to the smart contract address of the Guard. A SAFE can manage multiple Guards through an intermediary GuardManager contract. A typical use-case would be only allowing ‘owners’ of the SAFE (denominated by address) to execute a transaction (useful forMEV protection) or to only allow the SAFE to interact with certain whitelisted smart contracts via certain whitelisted functions on those smart contracts (useful to prevent accidental transactions or to limit the use of funds).
Guards constrain SAFEs.
Modules.
Modules are smart contracts that extend or modify the functioning of an otherwise standard SAFE. They can execute transactions on the SAFE that have not been individually approved by the requisite majority or plurality of signatures. A Module is added to a SAFE by calling the enableModule() function of the SAFE with the requisite majority or plurality of signatures, parameterized to the smart contract address of the Module. A SAFE can manage multiple Modules through a ModuleManager contract. Typical use-cases would be giving another account a per-month ‘allowance’ it can spend out of the SAFE’s assets, timelocking an upgrade authority that may be exercised by the SAFE over a DeFi protocol, or facilitating Moloch-style ‘ragequit’ functionality where a signer can quit the multisig with a proportional share of its assets.
Modules expand SAFEs.
BORGcore - The Heart of all BORGs
Every BORG on MetaLeX OS has a BORGcore (https://github.com/MetaLex-Tech/borg-core) smart contract as its heart. A BORGcore is a SAFE Guard combined with a standard ERC 4824 DAO interface.
BORG Modes
BORGcores have three modes: whitelist, blacklist, and unrestricted, each with unique access rules and constraints, and each capable of supporting BORG implants (see below) and tracking the URIs of the legal documents that ‘wrap’ the BORG. For security reasons, modes are immutable–thus, each BORG’s mode is selected once and for all, at the time of deployment of the BORGcore contract.
Whitelist Mode
In whitelist mode, all transactions are prohibited–except those explicitly pre-permitted (i.e., whitelisted).
Only approved recipients can receive native gas transfers, subject to individual transaction limits.
Only whitelisted contracts can be interacted with, and each whitelisted contract's methods can have specific parameter constraints (including types (uint, int, address, string, bytes, bool), value ranges, and exact matches).
Whitelist mode is the most conservative and trust-minimized mode for DAO-adjacent BORGs. It enforces the rule that BORG transactions are unauthorized by default. Only whitelisted transactions (or transaction types) with whitelisted accounts (or account types) are allowed—allowances that may be thought of as enforcing the BORG’s ‘policies.’ In most recommended BORG configurations, these policies will be mandatory legal rules enforced by, or enforceable against, the legal entity ‘wrapper’ and its personnel.
As a result, the BORG can only transact with counterparties it’s supposed to transact with, in ways, amounts, and at times, that are consistent with the legal rules of the legal entity ‘wrapper’. In the case of a DAO-adjacent BORG, these legal rules will, in turn, reflect the expectations of, and be approved in advance by, the adjacent DAO. In the case of a standalone BORG, these legal rules will reflect the expectations of, and be approved in advance by, other classes of interested parties, such as stockholders, managers, a board of directors, etc.
Thus, in wishlist mode, the BORGcore creates a ‘can’t-be-evil’ implementation of multisigs to constrain legal entities and their agents as a part of the core trust-minimization and 'can't-be-evil' ethos of crypto.
This BORG mode is most suitable for BORGs handling large amounts of money–for example, a finBORG that is managing ‘protocol-owned’ or ‘protocol-beneficial’ value by moving liquidity among various whitelisted liquidity pools and DeFi protocols. It may also be used for a Grants BORG that is subject to strict rate-limits or DAO vetoes or DAO co-approvals.
Blacklist Mode
In blacklist mode, all transactions are permitted–except those explicitly pre-prohibited (i.e., blacklisted).
Recipients listed in the blacklist cannot receive native gas transfers.
Blacklisted contracts cannot be interacted with, or methods of these contracts are blocked unless they pass specified parameter constraints (including types (uint, int, address, string, bytes, bool), value ranges, and exact matches).
Blacklist mode is suitable for DAO-adjacent BORGs that are somewhat more trusted (or somewhat less risky, and therefore less trust-requiring) and therefore may have broad discretion and flexibility, but with respect to which the DAO wishes to constrain a short list of particularly risky, dangerous or prohibited transactions. For example, a group of friends managing a memecoin and is trusted to use presale proceeds well, but which requires a snapshot approval of the memecoin holders in order to increase the memecoin supply through a minting function on the token smart contract. In this case, the mint() function on that particular token contract would be blacklisted, and implants (explained below) would be used to only allow a mint() call if also approved by the required snapshot vote.
In both whitelist and blacklist mode, the BORG can be subject to cooldown periods for relevant method calls to prevent the equivalent of DoS attacks. For example, a cooldown can prevent a BORG from spamming a DAO with vetoable transactions in order to raise the DAO’s monitoring/voting costs in the hope of sneaking a transaction through that the DAO would otherwise be likely to veto. This complements recommended provisions in the BORG’s legal docs that also prohibit such abusive activities.
Unrestricted Mode
In unrestricted mode, all transactions and interactions are allowed without restrictions.
No constraints are applied to recipients or contracts.
All native gas transfers and contract interactions are permitted.
Unrestricted mode is suitable for highly ‘trusted’ BORGs where the multisig signers are intended to have full discretion over the BORG’s activity, but where there is a desire to use MetaLeX OS’s implant functionality (see below) and/or simply to use MetaLeX’s web interface and legal services to wrap an otherwise unmodified SAFE. For example, this could enable a BORG whose main difference from an ordinary SAFE is just that, unlike in a standard SAFE< signers can now resign instantly and unilaterally–see below under ‘ejectImplant.sol’.
BORGcore also manages access control via the `BorgAuth` contract, ensuring that only authorized addresses can modify the BORG’s smart contracts. For DAO-adjacent BORGs, this will typically be configured in one of three ways:
BorgAuth is set to a null address–i.e., it is immutable.
BorgAuth is set to the DAO (effectively, this makes the BORG into more of a subDAO-style arrangement, which is not legally recommended, but is possible).
BorgAuth is set to a custom contract that requires co-approval of the DAO and BORG for changes.
The third option (approval of DAO and BORG) is the most recommended and typical, and would mirror provisions in the BORG’s alegal agreements that require DAO approval for material amendments to the legal terms of the legal entity’s governance rules.
Directors & Guardians
BORGcore has the option to set “directors” of the BORG/multisig. This is meant to accommodate dual-class voting structures within a given BORG/multisig. An example would be a 4/8 multisig with membership consisting of 3 persons who constitute the Board of Directors of the BORG and 5 persons who are not on the Board of Directors but are signers on the multisig for security reasons (essentially, increasing the number of keys and therefore raising cost of a coordinated wrench attack etc.). In this circumstance, we would require that at least a majority of the directors approve every transaction, in addition to between one and two non-directors (which we refer to in the legal docs as “guardians”). This type of structure can also lower the administrative/process overhead for forming the legal entity, as directors have greater authority, more potential legal responsibility and therefore face higher KYC/AML/due diligence requirements than mere security contractors. The parameter is set via the ‘directorsRequired’ variable specifying a minimum number of directors that must approve every transaction.
BORG Implants - SAFE Customization Modules
Each BORG has cybernetic implants (https://github.com/MetaLex-Tech/borg-core/tree/main/src/implants) enhancing its abilities beyond those of a normal SAFE. Each Implant is a SAFE Module consisting of a ConditionManager, a BORGauth, and a set of more specific rules particular to that implant.
The BORGauth may, through a particular Implant, grant to some third party or extrinsic smart contract the authority to take actions such as vetoing a timelocked BORG transaction, revoking the BORG’s funds, or adding and removing the BORG’s signers. For a DAO-adjacent BORG, the BORGauth would grant authorities over the BORG to the adjacent DAO. For a standalone BORG, the BORGauth would grant authorities over the BORG to stockholders (represented through a voting contract of tokenized shares of stock) or a set of managers, board of directors, or similar body represented through another SAFE multisig.
The ConditionManager allows for the BORGauth’s authority to be programmatically modulated. Custom smart contracts can be added to handle any conditional logic required, including: signature/multiparty approval, time, balance, and external oracle inputs. This can accommodate any condition that is provable on chain or with a trusted oracle for unlocking milestones or releasing escrowed funds.
ConditionManager enables the relationship between the BORG and its adjacent authority to be tuned into a nuanced governmental ‘checks/balances’ dynamic rather than the BORG being simplistically controlled by or subservient to the authority. For a DAO-adjacent BORG, such as a Grants BORG, this might mean, for example, that the BORG can freely give grants up to some monthly cap (denominated in either dollars or tokens), but that the DAO must co-approve, or can veto, grants exceeding that cap. For a standalone BORG, such as a technology corporation, this might mean, for example, that the BORG’s signers are also the directors of the entity, that a smart contract for recording votes of the tokenized shares is the BORGauth, and that each director serves for a specific term-of-service (potentially ‘staggered’ against the terms of other directors) and is automatically removed if not reelected by tokenized share vote within 30 days of the end of the term.
This architecture and its intended uses are a key differentiator between MetaLeX OS and other DAO and SAFE meta-protocols. Many such protocols conceptualize DAO-adjacent multisigs as being “subDAOs,” “minions,” “avatars,” “squads” or similar constructs to be treated much like subsidiaries, agents, or representatives of a DAO. Still others treat such multisigs as being ‘councils’ that ‘manage’ the DAO via ‘delegation.’ While MetaLeX OS can certainly facilitate those same kinds of relationships, the BORG design-philosophy encourages, and MetaLeX OS facilitates, a more subtle check-and-balance dynamic between DAOs and BORGs—making them mostly autonomous from each other while still being mutually accountable. This is critical for implementing optimal legal strategies*.
*(See https://www.law.cornell.edu/wex/alter_ego. Such separation is also important from a tax perspective).
The first BORG-type fully implemented on MetaLeX OS, GrantsBORGs, can feature the following Implants:
OptimisticGrantImplant.sol
Enables the GrantsBORG to give out grants “optimistically” using funds granted by the adjacent DAO, subject to programmatic rate limitations and caps. The GrantsBORG may exceed the rate limitations and/or caps with DAO-co-approval or subject to a timelock + absence of DAO veto. In an ideal case, the legal entity wrapper would still constrain the optimistic grants to be within DAO-approved purposes (such as supporting the specific ecosystem involved) and to follow certain offchain rules (like not issuing a grant to the GrantsBORG personnel or their respective affiliates).
daoVETOGrantImplant.sol and vetoImplant.sol
Enables the aforementioned timelock + DAO veto pattern for exceptions to the GrantsBORG’s rate limits and caps. This also includes anti-DoS measures so that the BORG cannot overwhelm the DAO’s veto capacity via ‘spam’ proposals (which should ideally be complemented with anti-evasion legal rules in the BORG legal wrapper). Can also be configured to require pre-approval per token type and have a per-grant limit. The two contracts accomplish this for full DAOs and snapshot-style DAOs, respectively.
daoVoteGrantImplant.sol
Enables the aforementioned DAO co-approval pattern for exceptions to the GrantsBORG’s rate limits and caps.
ejectImplant.sol
Enables a GrantsBORG multisig signer to resign of their own accord or for the DAO to remove a GrantsBORG multisig signer. When combined with DAO control of a MetaVest instance used to pay GrantsBORG personnel, the resignation mechanic can be a powerful way for the DAO to exert influence over the BORG without actually having shareholder-like authority to add and remove BORG members. See “MetaVest” and “Checks & Balances” below.
failSafe.sol
Enables funds to revert to the DAO (or another address) on specified events—for example, if the number of BORG signers falls below the minimum threshold needed for approval of actions on the SAFE. The destination address (typically the DAO treasury) is set at deployment and immutable. Like with other Implants, this can be combined with the ConditionManager to allow for clawbacks triggered by DAO approval alone, or DAO approval + number of other conditions or approvals. This can lead to some interesting strategies for responding to adverse events—see “MetaVest” and “Game Theory for BORGs” below. However, DAO communities and related BORGs should be careful to understand the risks of a DAO maintaining a diversified treasury, such as falling under commodity pool or investment company regulations; therefore, this should be treated strictly as a security-of-funds measure and, if triggered, the DAO community should rally to create a replacement BORG to hold non-native assets that have reverted from the (likely defunct) BORG to the DAO.
LeXscroW - Cybernetic Escrows
LeXscroW (https://github.com/MetaLex-Tech/LeXscroW) is a critical component of MetaLeX OS, designed to provide immutable, non-custodial, and flexibly-conditioned smart contract escrows. These escrows are built with the MetaLeX OS team’s experience with real-world deals in mind, and the uses of escrow agents within them. LeXscroW enhances the MetaLeX OS ecosystem by ensuring secure, automated, and legally optimized transactions involving BORGs—enforcing “deal logic” that is ordinarily entrusted to verbose legal agreements and manual processes, to the blockchain instead.
The core features common to all LeXscroWs include:
Ownerless Deployment: Contracts are deployed without an ‘owner,’ ensuring that no single entity can alter the conditions once the contract is active.
Immutable Conditions: Execution conditions can include signatures, time constraints, oracle-fed data, and more. These conditions are immutable upon deployment, trust-minimizing enforcement of the deal logic.
Depositor Flexibility: Contracts can specify depositing parties or allow any address to deposit, supporting both negotiated agreements with specific prearranged counterparties and open offers (including with an option for the offeror to reject a would-be accepting party, on a post hoc basis).
LeXscroW offers various smart escrow contract types, each tailored to specific transaction needs.
1. DoubleTokenLexscroW
Bilateral Transactions: Designed for bilateral smart escrow transactions involving two different ERC20 tokens.
Execution Conditions: The contract executes and releases tokens to both parties if all conditions are met before expiration.
2. TokenLexscroW
Unilateral Transactions: Facilitates unilateral smart escrow transactions for a single ERC20 token.
Execution and Refunds: Tokens are released to the seller upon meeting conditions, or refunded to the buyer if the contract expires without execution.
Depositor Rejection: Sellers can reject depositors, triggering a withdrawal mechanism for rejected deposits.
3. EthLexscroW
Native Token Transactions: Handles escrow for native gas tokens (e.g., ETH) with similar conditions and functionalities as TokenLexscroW.
LeXscroW integrates seamlessly with the BORG architecture within MetaLeX OS, enhancing the trust-minimized, governance-accountable nature of BORG transactions. Each BORG on MetaLeX OS can incorporate LeXscroW contracts to manage escrowed funds, ensuring that transactions comply with both the smart contract conditions and the legal rules governing the BORG’s operations. This allows BORGs to be somewhat more flexible, while also remaining trust-minimized—transactions that could not have been anticipated when the DAO initially authorized the BORG can still be implemented in a way that automatically enforces the relevant deal logic.
For instance, a GrantsBORG could utilize LeXscroW to handle the conversion of some of its OpsBudget governance tokens into stablecoins via a TokenLeXscroW that offers to sell the governance tokens at a specified discount to market price, with a specified lockup–essentially a unilateral OTC token sale offer.
In addition to enhancing traditional BORG functions, LeXscroW significantly enhances the "deal technology" capabilities within MetaLeX OS, powering secure and transparent transactions between various entities:
BORG-to-BORG Transactions: LeXscroW enables BORGs to engage in complex transactions with one another, ensuring that funds are only released when specific conditions are met. This enhances trust and operational efficiency between different BORGs.
DAO-to-BORG Transactions: DAOs can use LeXscroW to securely fund BORGs, ensuring that the funds are utilized according to predefined conditions and milestones. This mechanism supports governance and accountability within the DAO, while also providing operational autonomy to the BORG.
DAO-to-DAO Transactions: LeXscroW facilitates secure and conditional transactions between different DAOs, enabling collaborative projects and funding initiatives. By ensuring that all conditions are met before funds are released, LeXscroW fosters trust and cooperation between separate DAOs.
Essentially it digitally bakes in a ruleset by which two entities can abide by, replicating the way regular companies and organizations craft deals and assurances while interacting with each other, but in a more trust-minimized and secure manner.
Interesting Use Cases
LeXscroW can be applied in various scenarios to enhance the functionality and trustworthiness of transactions within the MetaLeX OS ecosystem:
1. Mergers and Acquisitions (M&A) Escrows:
Scenario: Two DAOs or ‘protocols’ agree to merge, and the transaction involves a complex exchange of tokens and assets.
LeXscroW Solution: A DoubleTokenLexscroW contract can be set up to handle the token swap, with conditions that ensure all DAO votes, BORG actions, and other prerequisites are met before the tokens are exchanged. This ensures that both DAOs can trust the process without needing a central intermediary.
2. Trustless Token Swaps:
Scenario: Two BORGs or DAOs wish to swap tokens directly without relying on centralized exchanges.
LeXscroW Solution: Using DoubleTokenLexscroW, each party deposits their respective tokens into the contract. The swap executes only when both parties have deposited the required amounts and any additional conditions (such as oracle-confirmed price feeds) are satisfied. This creates a secure and trustless environment for token exchanges.
3. Project Funding Milestones:
Scenario: A DAO funds a project managed by a BORG, with funds released based on project milestones.
LeXscroW Solution: A TokenLexscroW contract can be used to hold the funds, releasing them incrementally as predefined milestones are achieved and verified, either through on-chain events or trusted oracles. This ensures that the project is progressing as planned before each tranche of funding is released.
4. Cross-DAO Collaborations:
Scenario: Multiple DAOs collaborate on a joint venture, with each contributing funds or resources.
LeXscroW Solution: EthLexscroW or TokenLexscroW contracts can be established to manage the pooled resources, releasing funds according to agreed-upon milestones, conditions that reflect the progress and contributions of each DAO or layered approvals (essentially approval by a virtual multisig-of-DAOs-and-BORGs). This fosters cooperation and ensures transparency in the management of shared resources.
5. Betting:
Scenario: Two Twitter KOLs bet $1M USDC that ETH will hit $10,000 by the end of 2024.
LeXscroW Solution: TokenLexscroW plugs into an oracle that tracks the price of ETH, and automatically releases the funds to the winner based on the oracle price.
By integrating immutable, condition-driven escrow contracts, LeXscroW ensures that transactions are secure, transparent, and efficient, thus reinforcing the reliability and functionality of MetaLeX OS. This integration is particularly powerful in facilitating complex, trust-minimized transactions between BORGs, DAOs, and other entities, driving forward the vision of legally optimized, governance-accountable cyBernetic ORGanizations.
MetaVesT - Advanced Trust-Minimized Vesting
‘Grants’ can be tricky to implement. The typical notion of a ‘grant’ is giving a bunch of money up-front to some trusted party, pursuant to a loose agreement that says they will use that money to fund some work that the grantor values. However, in practice, this often turns out to be too ‘trustful’—instead, it is common for grants to be paid in tranches based on the satisfaction of various milestones, or to be earned/vested over time based on the expectation of a continuous period of work, where the grantor may determine to cut that work off at any time—more like an employment or independent contractor relationship. For very large grants, it may also be necessary or desirable to put transfer restrictions on tokens even after they are fully ‘earned’ so that not too many tokens are getting sold on the market all at once. Grant recipients may also have various structuring requests related to their tax optimization strategies, such as making the token grant into a token purchase option or deeming the tokens fully earned-up-front, but subject to a right of repurchase at a low price if conditions are not fulfilled.
Accordingly, when building-out the GrantsBORG use-case of MetaLeX OS, we had to give thought to a number of issues related to grantees potentially earning tokens from the BORG over time rather than in a lump-sum:
how could a GrantsBORG easily implement and enforce arrangements where grantees earn tokens based on length of service, milestones, or both?
how could a GrantsBORG easily implement and enforce token-earning arrangements for its own personnel (grants ‘council’ members etc.)—including earning tokens over time, unlocking tokens over time, and earning tokens based on milestones?
how could a DAO easily implement and enforce token-earning arrangements for the GrantsBORG?
how could the above be made compatible with typical legal arrangements and tax optimization strategies?
how could we facilitate a trust equilibrium between grantor and grantee so that neither has to trust one another completely (i.e., no ‘rugging’ is possible) but there is still flexibility to change terms etc. if the right people agree?
what other kinds of uses may BORGs have for token agreements in the future (for example, handling token unlocking for SAFT or Token Warrant investors, or handling vesting and transfer restrictions for tokenized equity securities) and could we accommodate all such use cases under the same protocol?
We looked at existing token ‘vesting’ protocols and realized they lacked many of the features needed to accommodate a rich response to these design questions. Thus, was born MetaVesT.
MetaVesT (https://github.com/MetaLex-Tech/MetaVesT) is a BORG-compatible and legally optimizable (especially, tax-optimizable) token vesting/lockup protocol for ERC20-compatible tokens. Like other token ‘vesting’ protocols (Hedgey, etc.), it supports basic token allocations that are streamed to a grantee over time. However, MetaVesT also supports far more complex and sophisticated token grant arrangements that mirror how legal token agreements are drafted in the real world. These features include:
dual-curve token release mechanisms (supporting token grants that “vest” (i.e., are earned) and “unlock” (i.e., are released from transfer-restrictions) at different cadences, with each curve potentially having its own separate ‘cliff’;
token option award and token warrant mechanisms (supporting the setting of an exercise price at time of grant and the later payment of such exercise price in stablecoins by the grantee to purchase the ‘vested’ tokens—important for tax structuring when grants are given after a token is already liquid and high-priced);
restricted token award mechanisms (supporting the setting of a repurchase price at time of grant and the later payment of such repurchase price in stablecoins by the grantor to repurchase the ‘unvested’ tokens—important for tax structuring when grants are given when a token is pre-liquid and low-priced);
group amendment mechanics (majority-in-value of grantees + grantor can amend token grants for everyone in the same cohort—mirrors equity incentive plan amendment mechanics and venture investor SAFT/token warrant mechanics where not all employees/investors need to agree to the amendment for it to be effectuated);
“can’t be evil” /anti-rug vesting guarantees—when so configured, the only feature of the MetaVesT that can be unilaterally changed by the grantor is (where applicable) termination of vesting (mirroring “at will” termination of service of an independent contractor)—all other changes require using the consensual amendment mechanic, just as they would for legal agreements in the real world (and, of course, vested tokens cannot be rugged by the grantor);
pass-through DAO voting (unvested and/or locked tokens can still be staked and voted in a DAO)—important for restricted token award mechanisms where grantees are supposed to be the legal owners of tokens notwithstanding continuing lockups and/or repurchase rights;
milestones—allowing vesting to be events-based rather than passage-of-time based; and
DAO accountability—for example, allowing a DAO to either fire a worker or strongly encourage a worker to quit by terminating the vesting of the worker’s token grants.
MetaVesT can be used both to mediate the vesting of BORG personnel into their compensation received from the DAO, and to mediate the vesting of grants from the GrantsBORG to grants recipients. For instance, a GrantsBORG can utilize MetaVesT to handle the disbursement of a custom grant type with complex terms. By setting specific conditions for release, such as milestone achievements or time-based vesting, or a combination of the two, the GrantsBORG can ensure that funds are only released when the predefined criteria are met. This could include a mix of passage of time plus some oracle condition—like a token hitting a specific price—being satisfied. This mechanism not only automates the grant disbursement process but also ensures compliance with the DAO-approved purposes and off-chain rules. MetaVesT may also be paired with LeXscroW for additional programmability.
As compared to other token vesting/unlocking protocols, MetaVesT has different features more optimized for the cybernetic law philosophy, DAOs and BORGs. Also unlike some other such protocols, it is both source-available and open-source. It is intended to be a DeFi-style and governance-based solution to legal token vesting/unlocking arrangements–most similar to Hedgey, but with additional features optimized for our cybernetic law philosophy–as compared to a centralized ‘administrator-style’ solution such as Toku. We don’t believe token vesting/unlocking should depend on the whims of any central authority–whether it be a ‘devco’ or a SaaS company like MetaLeX. ‘Can’t be evil’ is preferable to ‘don’t be evil.’
Example Configuration – GrantsBORG
MetaLeX OS is a very feature-rich and ultra-customizable suite that lets you have essentially any customization a BORG would need. Having highlighted many of its features, it is now useful to lean into a more specific, opinionated implementation of a specific DAO-adjacent BORG, discuss how it is likely to be set up both on the technical and legal sides, and explore the ‘game theory’ of the resulting check/balance dynamic between the BORG and its adjacent/sponsoring DAO.
For this purpose, we will explore what we’d view as a typical/recommended DAO-adjacent GrantsBORG set up, depicted below. NOTE: This is just one ‘opinionated’ configuration we think is likely suitable for most projects’ purposes; we can of course work with clients to configure many alternative configurations, according to their individual community needs and governance philosophies. We highly recommend considering the needs of a BORG and customizing its setup rather than using this as a template
More verbally, the basic setup of a standard DAO-adjacent Grants BORG would be:
a DAO:
governing some onchain smart contract system—let’s assume, for the moment, a DeFi system—and
in control of some source of ‘money’—be it premined governance tokens, the governance token mint function, or tokens in a diversified ‘DAO treasury’ (note—this DAO could itself be ‘legally wrapped’ or not; it does not matter to the BORG model);
2. a memberless, beneficiary-less, no-tax, Caymans Foundation that, by virtue of the rules in its Memorandum of Association, Articles, and Bylaws, is expressly and solely devoted to giving grants in support of the DeFi system—a Grants Foundation;
3. ‘money’ (in the form of tokens) to be donated by the DAO to the Grants Foundation, via an approved DAO governance proposal (or a series of approved DAO governance proposals);
4. a division of that money into conceptual buckets—one intended to constitute the Grants Foundation’s operational budget for some period of time (say, two years)—and another intended to be used by the Grants Foundation fund the grants;
5. a separate SAFE multisig to hold each of these buckets—the Ops Multisig and the Grants Multisig;
6. legal documentation establishing that the Grants Foundation is the owner of these multisigs and the tokens they ‘control’ (or, more colloquially, ‘hold’);
7. election (or at least acceptance) of the initial signers of these multisigs by the DAO, as part of the aforementioned proposals;
8. documentation establishing that these signers, when it comes to these multisigs and related activities, are working for the Grants Foundation;
9. documentation making all or a subset of the signers into directors of the Grants Foundation (note—this is optional—alternatively, the Grants Foundation can have one or more ‘professional directors,’ though this adds expense and complexity, and the SAFE signers can be mere service providers of the Grants Foundation);
10. a target runtime for the Grants BORG before it would likely need a ‘top-up’ of funding from the DAO—let us suppose in this case the Grants BORG is meant to run for two years;
11. a target ‘strategy’ for the Grants BORG—let us say in this case it’s to make lots and lots of small ‘bootstrapping’ grants to promising builders;
12. connecting the Grants Multisig to MetaLeX OS:
BORGcore + OptimisticGrantImplant will allow the Grants BORG to operate freely within its determined rate limit—so, for example, if it had $50M worth of funds meant to last two years and was meant to divide that into roughly 200 grants of roughly $250k each, it could freely and ‘optimistically’ grant up to 4 grants of up to $250k each per month without needing any DAO approval or being subject to DAO veto;
BorgCore + OptimisticGrantImplant + DAO Veto Implant will allow the Grants BORG to exceed its rate limits, subject to a timelock and DAO veto in each case;
BORGCore + ejectImplant + failsafeImplant will allow multisig signers to resign from their roles, and if too many do so, will enable the funds to revert to the DAO (more on the reasons for this below);
MetaVesT will handle both:
the vesting of grant amounts to the grantees; and
the vesting of material governance incentive awards to the Grants BORG personnel (more on the reasoning for this below) (note--their ordinary cash compensation can be handled discretionarily out of the Ops Multisig).
Checks & Balances
MetaLeX’s design philosophy emphasizes check-and-balance dynamics using a mix of cryptoeconomic incentives and legal structures. Let’s consider in more detail how these shake out in the sample configuration summarized above:
The BORG is pretty much free to do its thing for two years, as long as it sticks to the rules the DAO wanted—give lots of modest bootstrapping grants to projects that might benefit the DeFi system governed by the DAO, spread out evenly over the two-year period.
The BORG has an Ops budget (decided in advance by the DAO) and needs to make that last the two years, but can basically do whatever it wants with it, as long as the uses supports the BORGs grant-giving mandate—so, it can use this to pay personnel, in whatever way is determined by the Board of Directors of the Grants Foundation. The DAO does not need to approve every little compensation or operational spending decision;
We assume in this case that the ‘big money’ for the Grants BORG personnel—their main upside and the reason they are spending at least two years on giving out grants for this ecosystem—is their upside in the governance token of the DAO. For this reason, the incentive token awards are set aside in a MetaVesT contract, where the vesting of each individual personnel:
can be tax-optimized as token options, restricted token awards or RTUs;
can be terminated by the Board of Directors (this would presumably be because the person has been ‘fired from’ or has ‘quit’ the Grants BORG); and
can be terminated by the DAO—although the DAO does not have the power to hire and fire the BORG’s personnel, this can be seen as a strong ‘invitation to leave’ from the DAO to one or more Grants BORG personnel—and since the Grants BORG Personnel can, in fact, unilaterally resign from the multisig via the ejectImplant, this could be quite effective.
In case of abandonment of the GrantsBORG (which could be triggered due to attrition among the GrantsBORG personnel, or even by an en masse resignation in the event of the GrantsBORG getting hit by some adverse legal action), the funds automatically revert to the DAO via failSafeImplant—this means the GrantsBORG personnel always have an ‘out’, but can exercise it without personally making a decision about where the money goes; it’s already been made for them, and programmed onchain.
Under this structure, the initial structure-specific legal rules and smart contracts–establish a baseline rule-enforcement mechanism, while the DAO acts rather like a fuzzier-logic accountability oracle to handle edge-cases. Together, these structures ensures that the BORG is following its own rules.
Conclusion & Future Releases
While MetaLeX v1.0 is now complete, the small number of use cases and configurations we have mentioned here (mainly focused on GrantsBORGs) are just the start of unlocking its potential. In the coming weeks and months, we will aim to release more and more ‘out-of-the-box’ configurations of MetaLeX OS, paired with a customized UI for each one on our web app–securityBORGs, finBORGs, lexBORGs, ventureBORGs and more. Additionally, we will be releasing standalone LeXscroW and MetaVesT apps with some commonly used patterns pre-configured–such as a ‘cloutScroW for KOL twitter bets and SAFT and token contributor grant configurations for MetaVesT.
Links
BORGcore:
LeXscroW:
MetaVesT:
Mixbytes Audit:
https://github.com/mixbytes/audits_public/tree/master/MetaLeX
Zellic Audit (MetaVesT only):
Cybernetic law is now.