xVault: The Omnichain DAO Treasury

I submitted a grant to Gitcoin’s GR14 earlier this year for Sporos DAO. What should have been a straightforward process with providing an address for Sporos to receive donations turned into a convoluted and irritating exercise. To add insult to injury, I still got it wrong after countless double checking. Some of that is on me. But a lot of it is not.

Here’s where things went sideways. The Sporos DAO treasury is on Arbitrum. However, Gitcoin only accepts donations from Polygon and zkSync. I originally provided our Arbitrum address thinking it would work on Polygon, etc. because I’m used to my personal MetaMask working across all chains — but that’s not the case with our DAO treasury address created through KaliDAO (more info below).

Ivelin and I ended up creating a multi-sig to accept donations on Polygon but for whatever reason the Gitcoin application didn’t update with the multi-sig address when I edited it. As is probably obvious by now, I didn’t catch that fact until the round was over and funds were sent.

The result? Our funding went to addresses on Polygon and zkSync that we couldn’t access. Brutal. Fortunately, it wasn’t a huge amount of money, but it didn’t matter. Dozens of people donated to us and might as well have flushed that money down the toilet. I feel terrible it happened.

Google Image Result for https://y.yarn.co/d3cfd0c5-9faf-4dfc-8fa2-35e1bce7b63e_text.gif

No Standard for Omnichain DAO Addresses

The story above is a small anecdote and doesn’t even address all the issues at hand however. For example, had funds actually hit the multi-sig, it would have triggered a taxable event for me and Ivelin personally. Then there likely would have been another taxable event for Sporos when we sent the funds to the Sporos address on Arbitrum. What a mess.

What about the Optimism snafu from a few months ago? Remember when Wintermute accidentally sent 20M $OP tokens to an L2 address Optimism hadn’t deployed yet? That scenario is a bit more extreme than my Gitcoin experience but hits at the exact same issue.

There is no standard way for a DAO to deploy an address across multiple chains with the exact same deployment address. We need a way for DAOs to directly control their assets using a single convenient address, similar to Externally Owned Accounts (EOAs) created via MetaMask or Ledger wallets, but without the liability associated with individual and multi-sig custodians of DAO assets.

Enter xVault.

What is xVault?

xVault is just a concept for now. The purpose of this post is to socialize our initial thinking around it and motivate interested devs to join us to build it out.

xVault is a smart contract that provides a deterministic address on ETH L1 and EVM equivalent L2s (Arbitrum One, Optimism, etc.). DAOs can receive funds on the same xVault address across multiple chains and control the funds in each vault from their main KaliDAO smart contract deployment on an ETH L1 or EVM-equivalent L2 chain. In the Sporos example, we could use our Arbitrum address on all EVM compatible chains. All good if people want to send us funds to 0x28FEac06Dc72188b385478b507f7c7a39a7026d5 on Polygon, Optimism, zkSync, etc. — we control that address across all chains.

The following diagram illustrates the key concepts of xVault.

Requirements — Exclusive DAO Ownership

This section outlines what we believe the meets-minimum requirements should include.

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

• 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 the xVault contract is not deployed on that chain.
• The address must be deterministic and practically impossible for anyone to front-run and steal funds.

The 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 able 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 the initial bridge provided in deployment constructor to a new bridge provider.

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

• Proposal parameters such as a) xVault seed phrase, and b) 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 the 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

Lastly, yet importantly, the DAO should be able to pause/unpause their xVault via proposal on any and all chains where xVault is already deployed.

Requirements — Guardians, Upgradeability, and Bridging

Exclusive DAO ownership and control across EVM compatible chains is the core of xVaults. However, there are additional features that should be considered requirements based on what we’ve learned about vulnerabilities, attack vectors, and defensibility.

Guardians

A designated xVault Guardian should be able to pause/unpause xVault via signatures (similar to a Chief Financial Officer role). This is useful in cases when there is a known issue with an xVault contract or cross chain bridge contract and can allow time for the social layer to fix underlying issues and then unpause the xVault. DAOs should be able to elect, remove and replace xVault guardian(s) via proposal vote, and xVault guardian(s) should not be able to transfer funds. They can only pause/unpause and switch bridges.

Upgradeability

The xVault can be upgraded only by the DAO that owns and controls the address. This allows preserving the same EMV address while future-proofing xVault functionality. In effect, this acts similarly to EOA addresses where users benefit from wallet upgrades without changing the address.

Bridging Providers

It’s important to allow DAOs to enable a fallback bridge provider in case the main bridging provider is compromised. Additionally, xVaults should enable Guardian(s) to switch from the main bridge to a backup bridge or vice versa.

Possible xVault Solution

One way forward seems to include the following steps:

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.

1. Some security traps with CREATE2 implementations are discussed here and here.
2. Thorough review of main CREATE2 use cases here
3. EIP-2470: Singleton Factory using Create2
4. Minimal Proxy Contract pattern to save gas on deploying the same contracts to multiple addresses.
5. xdeployer a Hardhat plugin for safe use of CREATE2.
6. create2deployer smart contract deployed across 20 EVM chains to help with CREATE2 deployments.

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:

1. Transferring 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).
2. Bridging assets from a DAO vault on one chain to a DAO vault on another chain.
3. Staking assets from a DAO vault.
4. 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.

Our Ask

If this interests you, feel free to join our discord and let us know. We have multiple firsthand experiences with this issue, and it’s been validated by dozens of people we’ve spoken with in the industry. We’re now looking for passionate builders that want to step up and help us create a solution.

Most of the credit for the xVault concept and this post goes to Ivelin for his innovative and creative thinking. You can checkout more in our wiki here.