Skip to content

xVault: Omnichain DAO Treasury

Jump to bottom
Ivelin Ivanov edited this page Aug 31, 2022 · 2 revisions

xVault

xVault is a smart contract that provides a deterministic address on ETH L1 and EVM equivalent L2s (Arbitrum One, Optimism, etc.). DAOs can deploy xVault across multiple chains with the exact same deployment address. Consequently DAOs can receive funds on the same xVault address across multiple chains and control the funds in each vault from their main Kali smart contract deployment on an ETH L1 or EVM-equivalent L2 chain.

It provides DAOs with direct control of their assets using a single convenient address, similar to Extenally Owned Accounts created via MetaMask or Ledger wallets, but without the liability associated with individual and multisig custodians of DAO assets.

The Problem

How does a DAO (and specifically a KaliDAO) manage a treasury assets across multiple ETH secured chains. There are several issues related to that as described in this thread. Related discord discussion in public Kali channel here.

Known Issues & User Stories

  • A KaliDOA cannot accept direct payments to its treasury address on chains other than its native DAO native. Users may have to bridge and then send payment.
  • Receiving money into EOA works on any EVM chain, but entangles personal with DAO/company assets.
  • Receiving Gitcoin awards in a DAO vault instead of a personal externally owned address or a multi-sig.
    • Receving funds in a personal EOA triggers income tax event for the recipient. The person has to deduct income tax before forwarding the funds to the DAO that they are inteded for. After forwarding the funds to the DAO , that may trigger another tax event for the DAO itself.
    • Receiving funds in non-multi-chain contract address such as a Gnosis-safe leads to lost funds. If the Gnosis Safe is deployed on L1, and donors send funds to L2s (zkSync, Arbitrum One, Polygon), then the funds on L2s are lost unless the Gnosis-safe safe has been deployed on the exact same address on all L2s. As of July 2022, it is not straightforward to deploy a Gnosis safe on multiple chains with the same address.
    • Receiving funds in a DAO's main contract address also leads to lost funds. If the DAO contract is deployed on Arbitrbum One and donors send funds to L1 or another L2, there is no way for the DAO to control these funds.
  • Real world Sporos DAO example with gitcoin funding.
    • Funds from the example above were sent to the correct DAO address 0x28feac06dc72188b385478b507f7c7a39a7026d5 but not on the DAO native chain where the DAO smart contract was deployed (Arbitrum One). Instead funds were sent to L1, zkSync and Polygon. None of the funds can be accessed by the DAO now.
  • LexDAO discussion on shuffling funds from multi-sigs to DAO governed contracts on multiple chains.
  • Optimism to Wintermute transaction lost 20M.
  • User on-ramp providers such as Coinbase Pay and Ramp from traditional finance to web3 is only available on some L2 chains. This prevents DAOs hosted on other L2 chains from easily onramping trad fiat users.

The following diagram illustrates the key concepts of xVault.

xVault - Omnichain DAO Treasury drawio

Requirements

Same deterministic address on all EVM chains

  • Same xVault address on all EVM chains. Users with EOAs expect this feature.

Exclusive DAO Ownership

  • Each DAO deploys its own proxy instance with xVault instance state entirely owned by the DAO itself. Reduces risk exposure. Vaults that hold state (assets) of many DAOs have a higher incentive for hackers to attack and less likely to refund stolen funds.

  • DAO can deploy xVault on new EMV chains as needed.

    • No need to deploy on all possible EVM chains from the start.
    • DAO can deploy on a new chain only when it needs to transact on that chain.
    • DAO can receive funds on the xVault address on any EVM chain even if xVault contract is not deployed on that chain.
    • Address must be deterministic and practically impossible for anyone to front-run and steal funds.
    • xVault address hash must be based on:
      • Seed phrase provided in DAO proposal to deploy xVault
      • DAO EIP155 home address (chain ID: contract local chain address) AND
      • A deployment ABI block that includes DAO's home EIP 155 address as a deployment constructor parameter that initializes the xVault deployment with the DAO's home address as the only owner of the xVault contract. The owner must not be possible to change after deployment.
      • The cross chain CREATE2 deterministic address of the bridge provider(s) contracts. New bridge provider address(es) may be possible to change after deployment. However only xVault guardian(s) can switch from initial bridge provided in deployment constructor to a new bridge provider.

  • UI should offer a flow for DAO to propose, vote and deploy an xVault on designated chains.

    • Proposal parameters:
      • xVault seed phrase
      • initial bridge CREATE2 address
    • Users should be able to see the deterministic xVault address
    • Users should be alerted whether xVault is already deployed on target chains
    • Users should be informed which chains this xVault (with same deterministic address) is already deployed on.
    • Users should be alerted if the proposed xVault address does not match previously deployed DAO xVault address due to difference in seed phrase.
    • Users should be able to reuse seed phrase from a previous deployment of their xVault on other EVM chains.

  • DAO should be able to pause/unpause their xVault via proposal on any and all chains where xVault is already deployed.

Clean Separation from Personal Assets and Liability

  • No xVault transactions must require funds to go through EOAs or multisigs. All transactions should show be easily traceable on-chain as originated and terminated into DAO owned contract addresses. This maintains a clean chain of custody and prevents entanglement between personal and company assets.

Designated Guardian(s)

  • Allow a designated xVault guardian to pause/unpause xVault via signature (similar to Chief Financial Officer role). This is in cases when there is a known issue with xVault contract or cross chain bridge contract. Should allow time for social layer to fix underlying issue and then unpause the xVault.
    • Should pausing be time bound? Pause expires after a timeout to prevent losing all DAO funds in case of guardian loses keys or becomes permanently unavailable.
    • Should pausing allow multi-sigs? Smart contract guardian instead of an EOA signatory?
  • DAOs should be able to elect, remove and replace xVault guardian(s) via proposal vote.
  • xVault guardian(s) should not be able to transfer funds. Only pause/unpause and switch bridges.

Upgreadability

  • xVault can be upgraded only by the owning DAO. Allows preserving same EMV address while future proving xVault functionality. Similar to EOA addresses where users benefit from wallet upgrades without changing the address.

Bridging Providers

  • Allow DAO to enable a fallback bridge provider in case main bridging provider is compromised.
  • Allow guardian(s) to switch from main to backup bridge or from backup to main.

Asset Management Functionality

  • core xVault contract methods
    • v1
      • same chain transactions
        • transfer
        • transferTo
        • receive
        • support any ERC20, ERC721, ERC1155 tokens
      • bridge to/from same xVault address on other chains
    • v2
      • stake?
      • interact with yield vaults (https://eips.ethereum.org/EIPS/eip-4626)
      • Enable DAOs to authorize a Project Manager to use a budget of up to X tokens of a certain kind within a project deadline. When project manager initiates payments from the budget, the transactions should be directly between the DAO and contributor. No funds should be going through the project manager address. The transaction trace on-chain should show that the project manager approved a payment as per the DAO authorization, but the funds move from DAO xVault to an individual contributor (or a service provider company/DAO address) directly.

Known Risks

  • !Risk - xVault guard may potentially extort DAO by blocking funds.

    • DAO can mitigate risk by:
      • Authorizing multiple guards.
      • Rotating guards periodically.
      • Authorize different guards for different xVault chains.
      • Compensate guards for the job with a legally binding performance agreement.
      • Design an incentive mechanism that gives guards ability to stake assets on DAO's home chain. Assets can be slashed if guard does not perform xVault duties on target chain. Respectively guard gets compensation if they perform as agreed.

  • Eventually xVault guardians can be specialized agencies that act as traditional custodians with assumed liability. Except their responsibilities will be limited to guarding without any ability to access funds.

  • In order to minimize attack surface, xVault should not delegate arbitrary calls. It is possible that a compromised bridge may use xVault delegated generic calls to commit DAO to unintended obligations. That is a potentially unlimited risk exposure.

Possible Solution

One way forward seems to include the following steps:

  1. Develop an xVault contract and allow DAOs to deploy it via extension proposal on the exact same address on all ETH secured chains. Possibly using CREATE2 (as suggested by @2d_eddie) or this EIP-1820 method.
  2. Use Layer0, Connext/Nomad or Multichain cross chain messaging to enable a DAO to initiate transactions from its native deployment chain (e.g. Arbitrum One) to any of its vaults deployed on other (not its native) ETH secured chains. (DAO to xVault on same native chain do not need a bridge.) Specifically enable:
    • Transfering assets from any DAO vault (e.g. Optimism) to any address on the same chain (Optimism) or (optional) other ETH secured chains (e.g. zkSync).
    • Bridging assets from a DAO vault on one chain to a DAO vault on another chain.
    • Staking assets from a DAO vault.
    • DAO would fund these transactions with the native gas of the chain it's deployed on. Bridge provider will handle payments to relayers and bridges to complete the transactions on target chains.

Downstream Applications

TaxVault

One possible downstream benefit includes implementing 21% tax withholding for treasury assets of for-profit DAOs with c-corp tax treatment. For example a TaxVault contract can be given 21% stake in all DAO's cross-chain vaults. Periodically (once a month or quarter) the tax vault contract can automatically redeem, lock or stake assets of the DAO vaults to ensure there is enough available to pay taxes at the end of the year.

DataRoom

DataRooms are one of the blocking steps in an investment transaction. Typically compiling all financial data about a startup into one place (data room) is a messy process that requires executives, accountants and attorneys to dig up in their archives of company documents. Usually takes weeks and is never quite finished.

If a DAO has the flexibility to operate across multiple chains with all financial and contractual transactions traceable back to the DAO home chain address, then it is conceivable that a full data room report can be pulled with an automated data query.

Clone this wiki locally