YIP-XX Convert Ychad.ETH Into a BORG

Proposals Protocol and Governance
1

YIP-XX Convert Ychad.ETH into a cyBernetic ORGanization (BORG)

This proposal is divided into multiple parts due to forum sizing limits

Part 1

Intro

This is a proposal by MetaLeX 1, prepared in informal consultation with ychad.eth signers and other Yearn contributors, to convert ychad.eth into a cybernetic organization (BORG 2) 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) .

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

About BORGs, 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.

Motivation

  • Without a legal entity “wrapper:”

    • It is unclear what type of ‘legal thing’ ychad.eth is and what role the ‘signers’ play on it. It could be an “unincorporated association,” a “partnership,” a “tenancy of property in common,” a “joint venture” or something else. Most of the potential ‘implied classifications’ have much worse legal implications than being a Foundation company.
    • It is unclear what jurisdiction ychad.eth is “in” and therefore what laws apply, including tax laws. Arguably, without picking a specific jurisdiction, ychad could be subject to the laws of any/all jurisdictions where a signer resides.
    • It is unclear what the duties and liabilities of the ychad.eth signers are. For example, if ychad.eth is a common law partnership, ychad.eth signers could have “joint and several personal liability” in certain scenarios if they were sued. Ychad signers could arguably have implied “fiduciary duties” to users, tokenholders, governance participants, etc.—but such duties are more suited for the offchain TradFi world, and, even then, have largely been eroded through exculpation and insurance schemes that are unavailable to ychad.
    • It is unclear who owns the ychad.eth “treasury”—this could raise issues under MSB/VASP laws (rules are different for an entity managing its own money vs. managing on behalf of others), as well as ordinary property laws (do all ychad.eth signers own the ychad.eth treasury as ‘tenants in common’—one would hope not, but without an entity there could be gray areas!).
    • There is no clear ability to hold or manage “offchain assets” such as domain names, github accounts, etc.—an entity can own these kinds of things, it is not clear that a ‘multisig’ per se can.

  • Currently, important yearn-related domain names, social media accounts (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:

    • Ychad.eth serves as “Guardian” and may veto proposals approved by the DAO.
    • Ychad.eth membership changes should be subject to DAO approval.
    • The DAO uses snapshot voting and does not directly control any onchain smart contracts or resources, therefore Ychad.eth must effectively co-approve DAO proposals (as the DAO cannot actually fulfill a proposal without Ychad.eth’s execution/implementation, which amounts to an implicit co-approval).

However, this understanding is not formalized in any legal agreement or software. With a BORG, we can implement this understanding both in code and legal agreements. For example, any membership changes to Ychad will require both Ychad and DAO co-approval, and this rule will be embedded in the code modules (“BORG implants”) installed into Ychad’s SAFE.

  • 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.

2 Likes
2

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:

    • required to approve a liquidation of the entity (but cannot unilaterally approve such a liquidation—ychad.eth and Yearn DAO must also approve it); and
    • would be authorized to sign legal documents, government filings, etc. on behalf of the entity.

  • 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:

    • ychad.eth membership changes require approval of both ychad and the DAO, except for unilateral resignation by a ychad member (no resignation allowed if doing so would drop membership below signature threshold)
    • DAO proposals are subject to ychad veto

  • 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:

    • MetaLeX (as relatively neutral third party) maintains the oracle to listen to the standard veYFI snapshot space for DAO proposals made on our webapp (example—a proposal to remove a ychad.eth signer).
    • There is a transferOracle function in the snapShotExecutor smart contract that needs to be approved by both ychad.eth and the Yearn DAO to transfer to a new oracle in the typical case—e.g., an agreed-upon transition to purer onchain governance.
    • There is a ‘heartbeat’ function such that if the oracle is inactive too long ( 14 days), ychad.eth can set a new oracle unilaterally. This scenario is unlikely but could occur due to some security incident with MetaLeX (loss of keys) or adverse corporate event of MetaLeX.
1 Like
3

PART 3 OF PROPOSAL

Deeper Technical Dive

(see borg-core/README-yearnBorg.md at feat/yearnBorg · MetaLex-Tech/borg-core · GitHub 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 
graph TD
    ychad[ychad.eth<br/>6/9 signers]
    ychadSigner[Signer EOA]
    yearnDaoVoting[Yearn DAO Voting Snapshot]
    
    oracleAddr[oracle]
    
    borg{{Yearn BORG<br>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<br>propose(admin operation)"| snapshotExecutor      
    oracleAddr -->|monitor| yearnDaoVoting
    
    ychad -->|"owner<br>execute(proposalId)"| snapshotExecutor
    
    snapshotExecutor -->|"owner<br>policy operation()"| borg
    snapshotExecutor -->|"owner<br>guard & module management operation()"| sudoImplant
    snapshotExecutor -->|"owner<br>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.

Guard & Module Updates

In exceptional circumstances, ychad can propose the removal of the Guard via 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 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)

Deployment

  1. Run the deploy script

    forge script scripts/yearnBorg.s.sol --rpc-url <RPC URL> --optimize --optimizer-runs 200 --use solc:0.8.20 --via-ir --broadcast

  2. If got the following errors, force clean the cache with flag --force

    Error: buffer overrun while deserializing

  3. Take notes of the output Safe TXs (for setting guard & adding modules), for examples:

    Safe TXs:
 # 0
   to: 0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52
   value: 0
   data:
0x610b59250000000000000000000000006faa027c062868424287af2faef3ddaca802bff7

 # 1
   to: 0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52
   value: 0
   data:
0x610b5925000000000000000000000000a21f6d7aa0b320b8669caef53f790b1a2ac838d7

 # 2
   to: 0xFEB4acf3df3cDEA7399794D0869ef76A6EfAff52
   value: 0
   data:
0xe19a9dd9000000000000000000000000bc19387f5b8ae73fad41cd2294f928a735c60534

  4. Ask ychad to sign and execute the Safe TXs

Tests

Integration Tests

Test the deployment scripts and verify the results.

forge test --optimize --optimizer-runs 200 --use solc:0.8.20 --via-ir --fork-url <eth-mainnet-archive-endpoint> --fork-block-number 22268905 --mc YearnBorgTest

Acceptance Tests

Verify a specific deployment results.

forge test --optimize --optimizer-runs 200 --use solc:0.8.20 --via-ir --fork-url <eth-mainnet-archive-endpoint> --fork-block-number <deployment-block-number> --mc YearnBorgAcceptanceTest

Implementation

The project is fully specced and nearly fully implemented in:

Project Costs

  • One-Time Fees/Costs:
  • Recurring Fees/Costs (funded from ychad/Yearn treasury in future years):
    • ~$12k per year to Cayman Islands to maintain the legal entity in good standing (starts in year 2)
    • ~$5k per year to non-U.S. professional director (starts in year 1)

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 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 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) 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

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

Poll

  • yes, convert ychad to a BORG as described
  • no, do not convert ychad to a BORG as described
0 voters

4

my biggest concern (the concernoooor) with this proposal is the security of offchain assets such as domains and hosts

today this stays within yearn contributors which are alligned fully by yearn’s incentives, and this method has proven to never have had a security breach before in our dao, I’m afraid moving domains and hosts to a legal entity that is further away from yearn incentives than an internal contributor and put it in the hands of a non-yearn-contributor in a third-party company will push bad incentives for the security of these assets which can lead to millions being extracted by bad actors in a single leak

down the line there must be a trusted person accessing web2 admin pannels and this person has personal access to them, not an entity, and I see nothing here in this YIP that describes how will these assets be better secured with an external company rather than with yearn itself

I would like to see more guarantees for these assets than just the ones about legal risk in this YIP, for example I would like to see how exactly are you handling the real tech and security risks of this part, which if ignored may lead to a disaster scenario for our brand and dao

As you said: ”The ‘offchain’ assets to be held by the BORG (e.g., the yearn 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 account to a third party. There are legal protections for these assets, but no onchain protections."

I don’t think this is just a small risk to be shrugged off in the name of legal compliance

1 Like
5

Thanks for this proposal!

Are all the current ychad signers ok with the proposed setup, or will this lead to a signer’s rotation?

6

based on a chat poll they are all okay with it and it would not lead to a rotation

7

interesting, so you view the contributors who hold these accounts currently as more incentive-aligned than ychad signers and prefer to lean on that as opposed to actual legal protections?

if so, there are certainly ways we could achieve a ‘best of both worlds’ effect here…for example, we could create a separate BORG entity for the IP/accounts and have that entity run by ‘contributors’ rather than ychad signers or we could wrap a contributor council inside the same BORG as ychad, and have that contributor council be in charge of IP/accounts rather than ychad being so

either way, personally I would say the current arrangement is pretty far toward the riskier end of the spectrum as it relies purely on incentive ‘alignment’ and gives no actual rights to the DAO and has no legal protections for anyone…but it’s totally possible that putting ychad in charge of this could not be optimal and I’d love to brainstorm alternative structures

2 Likes
8

ychad is already on charge of this, my issue is with execution, because down the line someone needs to have personal access to the web2 admin panels and do what ychad has decided, and this already works very well today and never had any real issues even in the worse times of the SEC

I think moving this to a “professional director" (a term which I thought I would never have to hear in yearn) with no other disclosures in how this director incentives are alligned with yearn incenvies is a very bad move for the security of the offchain assets, it’s exactly how coinbase ended up having their leak: pushing important data and access outside it’s core team until it falls in the hands of people with wrong incentives

and yes I believe the way that it works today is better alligned for the yearn brand than pushing it away from contributors that have proven to have cared for these assets just for the sake of “legal risks" we never really had any issues with even in the worse time for crypto in the US

I am the person responsible for this today, and in case yearn wants to move it away from me to another person I will do it, but I will be very sad to see that yearn became a place where security of important digital assets is compromised for the sake of politics, as yearn to me was always a security-first place and it’s one of the things that drawn me as a contributor

Also I raised this concern before to Pickles in yearn chats made to chat about this, I’m sorry if he hasn’t forwarded them over to you, but it was raised in yearn chats before this YIP was done as a concern I had for this part of yearn, this exact same concern

1 Like
9

I think we can figure this out here. Practically speaking, the director should have no operational controls–they are in a purely legal/administrative role.

There would actually be no blocker to you continuing to serve an operational role with these accounts through a contract with the BORG entity–I’d suggest we open up a chat with the right people to hash this out.

2 Likes
10

thanks, I’m open to discussing this in any other chat, I don’t have strong opinions about any other points but this one!

1 Like
13

Final proposal posted here: YIP-87 Convert Ychad.ETH into a BORG

Discussion with Worms above was resolved through introduction of this spec for an ‘accounts custodian’, added to the final proposal:

1 Like