Skip to content

xVault: Multi chain DAO Treasury Vault

Jump to bottom
Ivelin Ivanov edited this page Aug 30, 2022 · 13 revisions

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.

  • Funds lost - sent to the correct address but on the wrong chain. 
  • Gnosis Multisigs have the same problem. Not available on all EVM chains as EOAs are. See OP issue.
  • Cannot accept direct payments on chains other than 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.
  • Issue recognized in the DAO community. See interest in topic at NYC Hack 2022, Connext panel announcement on twitter.

Requirements

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

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

  • Allow a designated xVault guardian to pause/unpaus 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 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.

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

  • xVault guardian(s) should not be able to transfer funds. Only pause/unpause and switch bridges.

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

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

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

  • core xVault contract methods

  • 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 a TreasuryVault 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. Potentially implement ERC 4626 as a Tokenized Vault Standard that allows integrating the vault on each chain with other apps.
  3. Use Connext/Nomad or Layer0 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 the same or other ETH secured chains. 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. Connext will handle payments to relayers and bridges to complete the transactions on target chains.

Downstream Applications

One possible downstream benefit includes implementing 21% tax withhodling 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.

Clone this wiki locally