YIP-87 Convert Ychad.ETH into a BORG

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.