# YIP-87 Convert Ychad.ETH into a BORG **URL:** \ **Category:** Protocol and Governance\ **Created:** [14 August 2025 01:38 UTC](https://gov.yearn.fi/t/yip-87-convert-ychad-eth-into-a-borg/14540 "2025-08-14T01:38:03Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![lex\_node](https://dub1.discourse-cdn.com/flex013/user_avatar/gov.yearn.fi/lex_node/32/2878_2.png) [@lex\_node](https://gov.yearn.fi/u/lex_node)\ **Post date:** [14 August 2025 01:38 UTC](https://gov.yearn.fi/t/yip-87-convert-ychad-eth-into-a-borg/14540/1 "2025-08-14T01:38:03Z")
## **Summary** This is a proposal by [MetaLeX 1](https://x.com/metalex_labs), prepared in informal consultation with ychad.eth signers and other Yearn contributors, to convert ychad.eth into a cybernetic organization ([BORG 2](https://delphilabs.medium.com/assimilating-the-borg-a-new-cryptolegal-framework-for-dao-adjacent-entities-569e54a43f83)) by: - “wrapping” ychad.eth’s multisignature smart contract and signers into an ownerless Cayman Islands Foundation Company to create legal personhood for ychad.eth, achieve jurisdictional clarity for purposes of taxes and regulations, and achieve limited liability for ychad.eth signers; - adding BORGs OS smart contracts to ychad.eth and connecting them to Yearn DAO in order to create clear onchain checks/balances between ychad.eth and Yearn DAO; and - creating a bespoke web application for managing information flows and relationships between Yearn DAO and ychad.eth and conveniently executing onchain check/balance dynamics. The BORGification project would be managed by MetaLeX, and Initial fees/costs would be covered out of Yearn’s prior contribution to the LeXpunK Builder Defense initiative in 2021 (see [https://snapshot.box/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE](https://snapshot.box/#/ybaby.eth/proposal/QmPK9AqeoV6v5xeuiTeFcj9Px7y87KMQ1gGhvHft2GMtqE)) . ## **Background - About Ychad.ETH** Ychad.eth is a 6/9 SAFE multisig smart contract on Ethereum mainnet (0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52) with a longstanding involvement in the Yearn ecosystem. Its current roles consist of: - executing proposals approved by Yearn DAO (since Yearn DAO voting currently uses veYFI-based-snapshot and lacks intrinsic executory power onchain), though this is currently done as a matter of custom and social consensus rather than a binding legal obligation or onchain mechanism; - serving as the “Protocol Guardian” with a veto role over Yearn DAO proposals (formalized by YIP-61 and YIP-81)—in effect, this legitimizes optionality Ychad would have anyway _not_ to execute proposals approved by Yearn DAO, and expresses this option as the possibility of a conscious “veto”; - having certain ministerial, coordination, or emergency powers relating Yearn end-user smart contracts (e.g., vaults) or over assigning such powers to other multisigs; and - receiving, holding and managing fees generated by Yearn end-user smart contracts (e.g., vaults) for the benefit of the Yearn ecosystem including by funding new R&D with grants, etc. The Ychad signers (except for one signer sourced from the contributor team) are ‘independent’ reputable DeFi community members with an interest in the Yearn community. There is also a ‘proposer’ role recognized by ychad.eth, which can propose actions to Ychad but not sign them and is held by a full-time Yearn contributor. Ychad.eth signer membership changes are supposed to be approved by Yearn DAO, but currently there is no legal or software mechanism to enforce this convention. For more on Ychad, see [https://docs.yearn.fi/developers/security/multisig](https://docs.yearn.fi/developers/security/multisig) ## **Background - About BORGs OS and MetaLeX** MetaLeX is made up of MetaLeX Labs, a venture-backed U.S. technology company, and MetaLeX Pro, a U.S. law firm, who together focus on delivering hybrid legal/tech solutions for crypto projects. MetaLeX’s offerings include designing, deploying and maintaining DAO-sponsored entities which we term ‘cybernetic organizations’, aka “BORGs”. BORGs are more modular, centralized entities than DAOs, but like DAOs are onchain and thus more transparent, efficient, accountable, and trust-minimized than traditional black-box legal entities. A deeper review of the general nature and raison d’etre of BORGs can be found at the links at the end of this proposal. Each MetaLeX BORG consists of the following components: - a tax-optimized, limited-liability legal entity (typically a Cayman Islands foundation company); - a standard SAFE multisignature smart contract owned by the entity and staffed by the entity’s personnel as signers, which holds any tokens owned or managed by the BORG (usually received from a DAO); - a set of entity Bylaws legally requiring that the SAFE and its assets to be managed in accordance with specific DAO-approved policies; - additional smart contract components engineered by MetaLeX, known as “implants” that, connect to the SAFE multisig to enforce the BORG policies onchain; - various offchain failsafe mechanisms, such as an authorized supervisor, to monitor and legally enforce any BORG policies that cannot be solely enforced onchain; and - a custom mini-app on metalex.tech, serving as a convenient hub for utilizing and monitoring the BORG. Every custom BORG deployed by MetaLeX receives the personal attention of a team of engineers and attorneys to ensure a seamless blend of law and technology which balances the BORG’s need for rapid and agile action against a DAO’s expectations for mission consistency and integrity. Our team has advised and assisted with mission-critical BORGs for the zkSync, Lido, Curve, Everclear, MetaCartel and Neutron communities. We utilize the highly respected and battle tested SAFE ‘smart account’ core code, without modification, which is currently responsible for over 127M transactions and $100B of value of assets stored on EVM chains. Our smart contract ‘implants’ plug into SAFE’s pre-defined ‘module’ and ‘guard’ hooks to safely constrain or expand the SAFE’s capabilities, and are open-source, audited and available for review at [MetaLex-Tech · GitHub](https://github.com/MetaLex-Tech). ## **Motivation** - Without a legal entity “wrapper:” - Currently, important yearn-related domain names, social media accounts ([x.com](http://x.com)), server accounts, and SaaS subscriptions related to the yearn ecosystem are held by heterogenous Yearn contributors with handshake arrangements about how they are to be used in relation to Yearn. These types of assets need to be registered in the name of a particular entity as their ownership is ‘registered’ rather than ‘bearer’. With the Yearn BORG, we can work on getting all these assigned to the legal entity and making them clearly subject to general rules about being used for the Yearn community’s benefit. - Ychad.eth signers largely serve a ‘community service’ for the Yearn community. They should not be exposed to personal liability at all, unless they commit crimes or similar (more on that below)—no less potentially unlimited/uncapped personal liability. Wrapping ychad.eth in a legal entity and having each signer enter into an agreement saying they act for this entity will typically mean the entity is liable for any issues, not the individuals. - Yearn DAO and ychad.eth have a putative understanding of their respective roles and check/balance relationship: - Yearn governance is intended to move to be more onchain but currently is not set up well for this transition. (See YIP 81—Prepare for Full On-Chain Governance). By putting the ruleset into code and legal agreements through the BORG approach, we can pave the way for full onchain governance. ## **Specification** The Ychad.eth BORG would continue with the same SAFE multisig smart contract, ychad.eth signers, and relationship to the DAO. _Legal Details_ - Tax-free non-profit Cayman Islands foundation company with no “members” or “beneficiaries”. - The purposes of the Foundation are to support the Yearn smart contract systems and related community, in light of the principles (decentralization/autonomy principles together with the Yearn Manifesto and Yearn BluePill). The Foundation is not permitted to pursue any unrelated purposes or to operate for the personal benefit of ychad.eth signers. - The company is legally required to perform its operations through specific smart contracts—the ychad.eth multisig and BORGs OS implants into it that give powers to the DAO—as well as a specific snapshot configuration honoring veYFI voting power (the “Mandatory Autonomous Systems”). Material changes to the Mandatory Autonomous Systems would require both ychad.eth approval and Yearn DAO approval. - Each ychad.eth signer executes a “BORG Participation Agreement” (onchain) so that the actions they undertake on ychad.eth are “wrapped” in the foundation company. - For compliance reasons, there is a single professional director (currently being hired) who will be identified by name in the Cayman registrar and has very limited authorities and almost no unilateral authorities: - For compliance reasons (since the Foundation company has no legal owners or beneficiaries), there is a “supervisor” who is empowered to monitor the adherence of the BORG to its own rules. In practice, this is a passive role, because the rules are largely embedded in the Mandatory Autonomous Systems and thus effectively cannot be violated. However, in case the DAO believes an egregious violation of the BORG’s rules or applicable criminal law has occurred, the DAO may pass a vote to temporarily give the Supervisor “Emergency Powers,” which can include ordering multisig member changes, hiring/firing directors, initiating lawsuits, participating in lawsuits, etc. This is a ‘nuclear option’ not to be used lightly. MetaLeX would be the Supervisor. - The meta-rules set forth in the Foundation company bylaws require that any material changes to material provisions require the approval of both ychad.eth and the DAO—this prevents changing fundamental rules (such as the rule that ychad must use the Mandatory Autonomous Systems). - Updated 8.13.2025–key yearn web2 accounts would be handled by a single ‘custodian’ during 3-month contracts with the BORG, see [Offchain Accounts Admin Terms - HackMD](https://hackmd.io/G5U6MuDKSrmKAFWW57ntvQ?view) _Onchain/Code Details:_ - onchain-enforced rules through the Mandatory Autonomous Systems: - Due to yearn DAO currently using snapshot (an offchain voting solution), the configuration cannot be completely decentralized/autonomous. The DAO voting ruleset is measured by an oracle that points to the current snapshot space for veYFI, and in theory this oracle could be changed to point to some other ruleset, since it is centralized. However, we seek to trust-minimize it as much as possible as follows: ---
**Author:** ![lex\_node](https://dub1.discourse-cdn.com/flex013/user_avatar/gov.yearn.fi/lex_node/32/2878_2.png) [@lex\_node](https://gov.yearn.fi/u/lex_node)\ **Post date:** [14 August 2025 01:38 UTC](https://gov.yearn.fi/t/yip-87-convert-ychad-eth-into-a-borg/14540/2 "2025-08-14T01:38:34Z")
**PART 2 OF PROPOSAL** ## **Specification** The Ychad.eth BORG would continue with the same SAFE multisig smart contract, ychad.eth signers, and relationship to the DAO. _Legal Details_ - Tax-free non-profit Cayman Islands foundation company with no “members” or “beneficiaries”. - The purposes of the Foundation are to support the Yearn smart contract systems and related community, in light of the principles (decentralization/autonomy principles together with the Yearn Manifesto and Yearn BluePill). The Foundation is not permitted to pursue any unrelated purposes or to operate for the personal benefit of ychad.eth signers. - The company is legally required to perform its operations through specific smart contracts—the ychad.eth multisig and BORGs OS implants into it that give powers to the DAO—as well as a specific snapshot configuration honoring veYFI voting power (the “Mandatory Autonomous Systems”). Material changes to the Mandatory Autonomous Systems would require both ychad.eth approval and Yearn DAO approval. - Each ychad.eth signer executes a “BORG Participation Agreement” (onchain) so that the actions they undertake on ychad.eth are “wrapped” in the foundation company. - For compliance reasons, there is a single professional director (currently being hired) who will be identified by name in the Cayman registrar and has very limited authorities and almost no unilateral authorities: - For compliance reasons (since the Foundation company has no legal owners or beneficiaries), there is a “supervisor” who is empowered to monitor the adherence of the BORG to its own rules. In practice, this is a passive role, because the rules are largely embedded in the Mandatory Autonomous Systems and thus effectively cannot be violated. However, in case the DAO believes an egregious violation of the BORG’s rules or applicable criminal law has occurred, the DAO may pass a vote to temporarily give the Supervisor “Emergency Powers,” which can include ordering multisig member changes, hiring/firing directors, initiating lawsuits, participating in lawsuits, etc. This is a ‘nuclear option’ not to be used lightly. MetaLeX would be the Supervisor. - The meta-rules set forth in the Foundation company bylaws require that any material changes to material provisions require the approval of both ychad.eth and the DAO—this prevents changing fundamental rules (such as the rule that ychad must use the Mandatory Autonomous Systems). _Onchain/Code Details:_ - onchain-enforced rules through the Mandatory Autonomous Systems: - Due to yearn DAO currently using snapshot (an offchain voting solution), the configuration cannot be completely decentralized/autonomous. The DAO voting ruleset is measured by an oracle that points to the current snapshot space for veYFI, and in theory this oracle could be changed to point to some other ruleset, since it is centralized. However, we seek to trust-minimize it as much as possible as follows: ---
**Author:** ![lex\_node](https://dub1.discourse-cdn.com/flex013/user_avatar/gov.yearn.fi/lex_node/32/2878_2.png) [@lex\_node](https://gov.yearn.fi/u/lex_node)\ **Post date:** [14 August 2025 01:39 UTC](https://gov.yearn.fi/t/yip-87-convert-ychad-eth-into-a-borg/14540/3 "2025-08-14T01:39:02Z")
**PART 3 OF PROPOSAL** ### _Deeper Technical Dive_ (see [borg-core/README-yearnBorg.md at feat/yearnBorg · MetaLex-Tech/borg-core · GitHub](https://github.com/MetaLex-Tech/borg-core/blob/feat/yearnBorg/README-yearnBorg.md) for a better-formatted version of this section, including diagrams) # Yearn BORG ## BORG Architectures | **Entity** | **Descriptions** | | --- | --- | | BORG Core | A Safe Guard contract restricting ychad’s administrative authority | | Eject Implant | A Safe Module contract for ychad member management, integrated with Snapshot Executor to enforce DAO co-approval | | Sudo Implant | A Safe Module contract for ychad Guard/Module management, integrated with Snapshot Executor to enforce DAO co-approval | | Snapshot Executor | A smart contract enabling co-approval between a DAO and ychad | | oracle | A MetaLex service for coordinating Yearn Snapshot voting and recording results on-chain. It is set to be replaced by Yearn’s own on-chain governance contract in the future | ```auto graph TD ychad[ychad.eth
6/9 signers] ychadSigner[Signer EOA] yearnDaoVoting[Yearn DAO Voting Snapshot] oracleAddr[oracle] borg{{Yearn BORG
BORG Core}} subgraph implants["Implants (Modules)"] ejectImplant{{Eject Implant}} sudoImplant{{Sudo Implant}} end snapshotExecutor[Snapshot Executor] borg -->|"guard"| ychad %% implants -->|modules| ychad ychadSigner -->|signer| ychad ychadSigner -->|"selfEject()"| ejectImplant oracleAddr -->|"oracle
propose(admin operation)"| snapshotExecutor oracleAddr -->|monitor| yearnDaoVoting ychad -->|"owner
execute(proposalId)"| snapshotExecutor snapshotExecutor -->|"owner
policy operation()"| borg snapshotExecutor -->|"owner
guard & module management operation()"| sudoImplant snapshotExecutor -->|"owner
member management operation()"| ejectImplant %% Styling (optional, Mermaid supports limited styling) classDef default fill:#191918,stroke:#fff,stroke-width:2px,color:#fff; classDef borg fill:#191918,stroke:#E1FE52,stroke-width:2px,color:#E1FE52; classDef yearn fill:#191918,stroke:#2C68DB,stroke-width:2px,color:#2C68DB; classDef safe fill:#191918,stroke:#76FB8D,stroke-width:2px,color:#76FB8D; classDef todo fill:#191918,stroke:#F09B4A,stroke-width:2px,color:#F09B4A; class borg borg; class ejectImplant borg; class sudoImplant borg; class snapshotExecutor borg; class oracleAddr borg; class ychad yearn; class ychadSigner yearn; class yearnDaoVoting yearn; ``` ## Initial BORGing of ychad To implement the BORG, ychad unilaterally: - determines initial signer set (i.e., keep existing signers) - approves/adopts legal agreements (Cayman Foundation) - installs SAFE modules (BORG implants) and guard (BORG core) If desired, can seek prior DAO social approval for these changes (and this is likely best for legitimacy), but no DAO onchain actions or legal actions are required. ## Restricted Admin Operations Once ychad is “BORGed”, the following operations will require bilateral approval of the DAO and ychad. Onchain, this means ‘blacklisting’ certain unilateral SAFE operations that would otherwise be possible, instead requiring DAO/ychad co-approval of such actions: - Add / remove / swap signers / change threshold - Add / disable Modules - Set Guards ### Co-approval Workflows The process for bilateral ychad / DAO approvals will be as follows: 1. Operation is initiated on the MetaLeX OS webapp 2. A Snapshot proposal will be submitted via API using Yearn’s existing voting settings 3. MetaLeX’s Snapshot oracle (`oracle`) will submit the results on-chain to an executor contract (`Snapshot Executor`), which will have the proposed transaction pending for co-approval 4. After a waiting period, ychad can co-approve it by executing the operation through the MetaLeX OS webapp 5. After an extra waiting period, anyone can cancel the proposal if it hasn’t been executed This essentially means that ychad cannot ‘breach’ its basic ‘agreement’ with the DAO by changing the meta-governance rules (ychad signer membership, ychad approval threshold). It also adds an extra security layer as ychad members cannot collude to change these fundamental rules. All other operations would remain under ychad’s sole discretion. ### Future On-chain Governance Transition Yearn’s Snapshot governance will be replaced with an on-chain governance at some point (ex. `YearnGovExecutor`). Technically, the transition is done by having `YearnGovExecutor` serve as the new `oracle`. Therefore, `YearnGovernance` must meet the following requirements: - `YearnGovernance` can call `SnapShotExecutor.propose(target, value, cdata, description)`, which contains the instructions of the admin operation The transition process from Snapshot to on-chain governance is listed as follows: 1. A final Snapshot proposal will be submitted to assign `YearnGovExecutor` as the new oracle of `Snapshot Executor` 2. Once co-approved and executed by ychad, the transition process is complete After the transition, the co-approval process will become: 1. Operation is initiated on the MetaLeX OS webapp, or, alternatively, through a third-party UI if the calldata is prepared 2. An on-chain proposal will be submitted to `YearnGovExecutor` 3. Once the vote passed, `YearnGovExecutor` will propose the results to the executor contract (`Snapshot Executor`), which will have the proposed transaction pending for co-approval 4. After a waiting period, ychad can co-approve it by executing the operation through the MetaLeX OS webapp 5. After an extra waiting period, anyone can cancel the proposal if it hasn’t been executed ### Module Addition New Modules grant ychad privileges to bypass Guards restrictions, therefore it requires DAO co-approval via [Co-approval Workflows](https://gov.yearn.fi/t/yip-xx-convert-ychad-eth-into-a-borg/14531/3#co-approval-workflows). ### Guard & Module Updates In exceptional circumstances, ychad can propose the removal of the Guard via [Co-approval Workflows](https://gov.yearn.fi/t/yip-xx-convert-ychad-eth-into-a-borg/14531/3#co-approval-workflows). Upon DAO co-approval and execution, ychad will no longer face any restriction on administrative operations. Likewise, ychad can propose adding or removing Modules through [Co-approval Workflows](https://gov.yearn.fi/t/yip-xx-convert-ychad-eth-into-a-borg/14531/3#co-approval-workflows) as well. For safety, it cannot remove the `SudoImplant` Module itself. ## Member Self-resignation A ychad member can unilaterally resign by calling `EjectImplant.selfEject(false)` without approval. The Safe contract ensures threshold validity. Members are prohibited from calling `EjectImplant.selfEject(true)` as it would alter the multisig threshold. Consequently, they cannot self-resign when the remaining member count equals the threshold. ## Restricted Advanced Operations Once ychad is “BORGed,” the following operations are restricted for security reasons unless explicitly whitelisted: - Transactions executed in `DelegateCall` mode However, to ensure a seamless user experience, commonly used advanced operations are preemptively whitelisted, including: - Batch Transactions (via `MultiSendCallOnly`) Note: `MultiSendCallOnly` is whitelisted, but `MultiSend` is not, as it permits arbitrary `delegatecall`, posing security risks. Operations relying on `MultiSend`, such as manual fund distributions, can typically be performed using safer alternatives, like custom vetted contracts. ## Key Parameters | **ID** | **Value** | **Descriptions** | | --- | --- | --- | | `borgIdentifier` | Yearn BORG | BORG name | | `borgMode` | blacklist | Every operation is allowed unless blacklisted | | `borgType` | 3 | Dev BORG | | `snapShotWaitingPeriod` | 3 days | Waiting period before a proposal can be executed | | `snapShotCancelPeriod` | 7 days | Extra waiting period before a proposal can be cancelled | | `snapShotPendingProposalLimit` | 3 | Maximum pending proposals | | `snapShotTtl` | 30 days | Duration of inactivity before an oracle is deemed expired and can be replaced by ychad | | `oracle` | `address` | MetaLeX Snapshot oracle (or Yearn on-chain governance contract after [transition](https://gov.yearn.fi/t/yip-xx-convert-ychad-eth-into-a-borg/14531/3#future-on-chain-governance-transition)) | ## Deployment 1. Run the deploy script 2. If got the following errors, force clean the cache with flag `--force` 3. Take notes of the output Safe TXs (for setting guard & adding modules), for examples: 4. Ask ychad to sign and execute the Safe TXs ## Tests ### Integration Tests Test the deployment scripts and verify the results. ```auto forge test --optimize --optimizer-runs 200 --use solc:0.8.20 --via-ir --fork-url --fork-block-number 22268905 --mc YearnBorgTest ``` ### Acceptance Tests Verify a specific deployment results. ```auto forge test --optimize --optimizer-runs 200 --use solc:0.8.20 --via-ir --fork-url --fork-block-number --mc YearnBorgAcceptanceTest ``` ## **Implementation** The project is fully specced and nearly fully implemented in: - the legal docs here: [publicDocs/BORG-legal-docs/ychad-BORG/proposal-drafts-7.30.25 at main · MetaLex-Tech/publicDocs · GitHub](https://github.com/MetaLex-Tech/publicDocs/tree/main/BORG-legal-docs/ychad-BORG/proposal-drafts-7.30.25) - the code here: [GitHub - MetaLex-Tech/borg-core at feat/yearnBorg](https://github.com/MetaLex-Tech/borg-core/tree/feat/yearnBorg) - verified Base test deployment here: [https://basescan.org/address/0x0c05bf611b4f3769e8bf3714c0aeedb965bea40c#code](https://basescan.org/address/0x0c05bf611b4f3769e8bf3714c0aeedb965bea40c#code) - video demo of web app here (video showing member management features): [https://x.com/MetaLeX\_Labs/status/1950657512749093373](https://x.com/MetaLeX_Labs/status/1950657512749093373) ## **Project Costs** - One-Time Fees/Costs: - Recurring Fees/Costs (funded from ychad/Yearn treasury in future years): ## **Risks** Below are the risks we can see with the proposal. We believe many of the risks are either outweighed by greater risks associated with the status quo (see “Motivation” above) or have been sufficiently mitigated, but will not note counterarguments to every risk in this section as they should be fairly obvious in most cases. - Creating an identifiable legal entity for ychad also makes that legal entity the natural target for lawsuits, governmental investigations, etc., as opposed to the current ‘chaotic landscape’ a litigator or government would face in identifying and subpoenaing dispersed individuals or ‘the unincorporated association’ of ychad. This is, in effect, intentional, to limit the exposure of any given individual. - Forming a legal entity creates jurisdiction for the government where the entity is incorporated (Cayman Islands)—this particular jurisdiction might not otherwise have jurisdiction and choosing this jurisdiction does not preclude the possibility that other governments may still assert jurisdiction (e.g., based on yearn having users in other jurisdictions, based on residences or citizenships of ychad.eth signers, etc.). - Cayman Islands is currently regarded as ‘crypto friendly’ but its laws could change. - Ychad.eth signers will have clear limited liability and carefully prescribed (limited) contractual duties under the BORG structure, whereas there could be greater room to argue that they have broader liability and duties under the current unincorporated arrangement—this may limit legal remedies on the part of yearn community members who view ychad.eth signers adversely. - MetaLeX will run a centralized webapp and snapshot oracle service related to the BORG and will serve as Supervisor to the BORG. Mitigations for the oracle centralization are described above, but an interruption to MetaLeX’s operations (whether due to insolvency, regulatory issues in the United States, malfeasance, or any other factor) could result in interruptions of service: (1) the oracle service could stop, and ychad.eth would not be able to unilaterally change it until it had been dead for 14 days; and (2) the web application could cease to function, making interaction with the relevant smart contracts less convenient but not impossible. Fallback options include snapshot’s standard third-party UI, the official SAFE web app, Etherscan, command line interfaces, etc.—these would need to use manually constructed JSON blobs to make relevant smart contract calls instead of MetaLeX’s web app constructing these calls. - The legal structuring around BORGs—including “qualified code deference” in which the entity’s legal agreements largely defer to onchain outcomes—is untested in courts of law. If challenged, a court could find the arrangements unenforceable or only partially enforceable and order restructuring of the BORG or decline to honor the results of its normal operations. - The ‘offchain’ assets to be held by the BORG (e.g., the yearn [X.com](http://x.com/) account, vercel accounts, etc.) have different trust assumptions that could be abused. For example, a director of the entity could ‘go rogue’ and seek to sell yearn’s [X.com](http://x.com/) account to a third party. There are legal protections for these assets, but no onchain protections. - Adding the role of managing offchain assets such as social media accounts to ychad, in a single entity, could be viewed as ‘centralizing’ and may marginally increase ychad’s legal risks as it now manages additional items. However, ychad could already been seen as having significant influence over these items through social conventions regarding how they are used, and as Yearn’s planned transition to onchain governance proceeds, ychad’s other powers will be reduced in favor of Yearn DAO. - MetaLeX will serve as Supervisor to the BORG, but MetaLeX has many clients, projects, and activities, and may have conflicts of interest. The director ultimately hired to serve on the board of directors of the BORG may also have many clients, projects and activities, and may have conflicts of interest. - The relevant smart contract code (standard SAFE + MetaLeX’s BORGs OS) is audited ([https://github.com/mixbytes/audits\_public/tree/master/MetaLeX](https://github.com/mixbytes/audits_public/tree/master/MetaLeX)) and open source, but this is no guarantee of being free from bugs or potential exploits. - Wrapping ychad.eth in an entity may require additional legal formalities as part of ychad.eth’s operations—for example, new signers must sign BORG Participation Agreements to join ychad.eth, and it may be advisable that ychad.eth sign certain ‘written consents’ documenting their legal decisions on certain matters (e.g., appointing or removing a new professional director), even if these would not ordinarily require an onchain transaction. ## **Additional Reading** - Articles, Blogs, Etc. - Other Noteworthy BORGs MetaleX has worked on: ## **Voting** **For** : Yes, convert ychad into a BORG as described in this proposal, with any non-material discretionary changes recommended by MetaLeX and approved by ychad multisig signers during the implementation phase **Against** : No, do not convert ychad into a BORG as described in this proposal ---
**Author:** ![dudesahn](https://dub1.discourse-cdn.com/flex013/user_avatar/gov.yearn.fi/dudesahn/32/4350_2.png) [@dudesahn](https://gov.yearn.fi/u/dudesahn)\ **Post date:** [14 August 2025 14:50 UTC](https://gov.yearn.fi/t/yip-87-convert-ychad-eth-into-a-borg/14540/4 "2025-08-14T14:50:56Z")