-
Notifications
You must be signed in to change notification settings - Fork 16
xVault: Multi chain DAO Treasury Vault
Ivelin Ivanov edited this page Aug 30, 2022
·
13 revisions
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.
- 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.
One way forward seems to include the following steps:
- Develop a
TreasuryVault
contract and allow DAOs to deploy it via extension proposal on the exact same address on all ETH secured chains. Possibly usingCREATE2
(as suggested by @2d_eddie) or this EIP-1820 method.- Some security traps with CREATE2 implementations are discussed here and here.
- Thorough review of main CREATE2 use cases here
- EIP-2470: Singleton Factory using Create2
- Minimal Proxy Contract pattern to save gas on deploying the same contracts to multiple addresses.
- xdeployer a Hardhat plugin for safe use of CREATE2.
- create2deployer smart contract deployed across 20 EVM chains to help with CREATE2 deployments.
- Potentially implement ERC 4626 as a Tokenized Vault Standard that allows integrating the vault on each chain with other apps.
- 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.
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.