[RFC] The dxVault - Increased Reserve Security

The Problem

The dxDAO needs a safer contract to keep the majority of the dxDAO’s funds in…

  • The current wallet (DAOstack’s Avatar contract) is at risk of being drained by any scheme or voting machine that is malicious or configured incorrectly.

The Solution

I propose the dxDAO does the following…

  • Deploy an immutable Reputation contract, using REP values from the current dxDAO Reputation contract (a snapshot).
  • Deploy a Gnosis Safe wallet to be used as the dxVault.
  • Create a Gnosis Safe module called “WithdrawRequest”.
  • WithdrawRequest will allow anyone to create a withdraw proposal, which all REP holders present in the immutable Reputation contract will be able to vote on.
  • These proposals should use relative majority, as we need to ensure that a request can be passed / failed even if there is low voter turn out.
  • WithdrawRequest can also allow for updating the static reputation contract to a new more up to date one, by way of proposal of course. Maybe the dxDAO does this quarterly, biyearly, or yearly.

Any and all thoughts welcome! This is also a great proposal for any interested developer to make to the DAO as I will not be able to follow through with this project’s execution.

11 Likes

Would “WithdrawRequests” only be allowed to send funds back to the DXdao?

1 Like

No, any address. This way if the dxDAO in its current form gets hacked, a new one can be stood up and the funds be sent there.

1 Like

Would WithdrawRequests show up on Alchemy?

Are these proposals relative majority by default?

This makes sense. But since this is a security solution, wouldn’t it make sense to have a voting threshold that creates more of a barrier than using relative majority?

I don’t feel that having a snapshot of the REP holders will necessarily make things any more secure. For example, in the future, someone could potentially have REP taken away, but using this system they would still be allowed to vote to withdraw funds after such an occurrence. If security is a concern, then yes, increasing the voting threshold makes sense. E.g. 2x a relative majority.

Nope, this is a problem. We would need an specific scheme for that…

BUT there is a solution.

We can design the contract in a way to execute functions depending on the amount of ETH you sent, so, If you send 666 wei form the avatar to the dxVault, it will withdraw the ETH.

This way the process would be:

  1. Deploy the dxVault
  2. Assign the rep holders, and lock the rep.
  3. Send the funds you want to lock.
  4. Remove the funds by sending 666 wei to the vault, the vault will see it received 666 wei and it will execute the withdraw of all funds to avatar immediately.

This process can be repeated, allthough it is far far from the ideal “vault mechanism” we should be using, but is a good solution for now.

I don’t think this is necessary if you allow anyone to create withdraw proposals…

The reason for the snapshot is that the current Reputation contract is very dynamic, and can be hacked at any moment. The attacked would then mint themselves >99% REP, and have the ability to instantly pass a proposal to withdraw funds.

If the scenario you’re talking about happens, the DAO could just vote to update the snapshot to a new one that doesn’t have this malicious member.

Also I agree, having relative majority with at least 2x majority in the winning direction sounds like a great idea.

I think an improved relative majority could be the 2x relative majority @frootloopsbird described.

For example, this would succeed:
10.1% YES vs 5% NO

This would fail:
9% YES vs 5% NO

1 Like

This is extremely important, thank you for the write up. I too feel current conditions make things dangerous, it should be a priority to ensure what I feel is a timebomb, doesn’t get exploited.

2 Likes

+1 This was the reasoning behind my recent proposal. Protecting the Dao from malicious actors is essential. It is often good to assume the worst possible scenarios. Hopefully a different dev can lead this effort. Thank you for bringing awareness.

1 Like

A couple questions-

  1. Do we put all assets into dxVault, or do we put all assets minus say 3 months of projected expenditures?
  2. Should we remove inactive members? Specifically members who have never voted in the previous quarter. This would allow a 2/3 absolute majority instead of a 2/3 relative majority (2:1).
  3. Do we want a feature for quickly voting to transfer funds in case of an emergency? For instance a 4/5 absolute majority on a 24 hour timescale versus a standard 2 week timescale.

My initial reactions are
(1) Not all funds, but leave 3 months of expenses in Avatar. This means dxVault votes will be infrequent (1x/month) reducing cognitive load for devs.
(2) Removing inactive members for dxVault voting increases security and greatly reducing risk without the disadvantages of slashing REP in the main contract (cognitive load, punishing members on vacation, punishing members who see no need to constantly vote on issues that will pass with a relative majority anyway).
(3) Yes, emergency expenditures are likely to be required at some point and there should be a mechanism for such. With a high enough absolute majority requirement and removing inactive members, dxVault could rapidly respond to fluid situations that require deploying capital.

Responses:

  1. Not all of the funds, just a bulk amount the DAO wants to keep safe. Think of hot & cold wallets. Your example of 3 months expenditures is a good rule of thumb I think.
  2. I am personally in favor of keeping the existing REP contract, but just using relative majority. This way if something important takes place in the future, and inactive members want to become active to help get a vote passed or declined, they can log on and vote.
  3. This is an interesting point. Maybe there are 2 different types of proposals, with 2 different speeds & voting criteria.
1 Like

I do not think going this route would improve security or reduce attack surface. This adds additional contracts that need to be written and audited, and an additional place to monitor for malicious proposals.

There would also be no easy way to slash rep holders who vote for malicious proposals on the safe. You would need to migrate to a new safe, or slash the rep holder(s) on the dao, then update the safe’s static rep contract.

This might just add confusion, cognitive overhead, and gas expenditure for Rep holders, since they now have to monitor and vote down any proposals on the safe.

Overall I think it’s a dangerous route, as it essentially is forking the DAO, splitting its funds and attention between two divergent sets of voters.

4 Likes

Good points, I agree.

A few pointed responses:

splitting its funds and attention between two divergent sets of voters.

The idea is to have the “REP Snapshot” trail behind the “master” REP contract the dxDAO uses & modifies on a daily basis. It’s like having a release branch in Git. The REP snapshot could easily be updated through a single proposal, so this could be done at will by the DAO.

Additionally I think it’s important to have 2 sets of “dashboards”, one for daily low security things, and one for high security longer term things. I almost think it’s more dangerous mixing them in a single interface.

This might just add confusion, cognitive overhead, and gas expenditure for Rep holders, since they now have to monitor and vote down any proposals on the safe.

This is a good point, since anyone can create proposals in the dxVault. Voters in the dxDAO would constantly have to vote them down to ensure they don’t pass.

A way you can get around this is to have a minimum quorum needed for a vote to be considered valid.

There would also be no easy way to slash rep holders who vote for malicious proposals on the safe.

In order to do so, you’d have to slask them in the dxDAO’s “main” Reputation contract, then update the snapshot.

I do not think going this route would improve security or reduce attack surface. This adds additional contracts that need to be written and audited, and an additional place to monitor for malicious proposals.

The key piece that’s reducing the attack surface is having the funds spread accross two different wallets with different security models. One more secure than the other (ideally). We’re heavily riding on two factors here to make the dxVault as secure as possible:

  • Gnosis Safe’s Security
  • Static REP
    • hacker cannot mint millions of REP and pass a proposal in a single transaction. This could currently happen if a scheme added to the dxDAO has malicious code or is misconfigured.
1 Like

+1 for quorom. Agree with orishim we want to reduce cognitive load for REP holders, not increase it. Based on current activity, I’d suggest a quorum of 20%. With the current design plus quorum, the load would be:

  • 1 proposal every 3 months to update the REP snapshot.
  • 1 proposal every 3 months to rebalance DXVault and treasury.

If this load is too high, its possible to slow down the REP snapshot and hold hold more funds in the treasury. The tradeoff is higher risk the more funds are in the treasury as opposed to the vault. If there’s some debate on what those numbers should be, might make sense to take an informal poll here.

3 Likes

Altogether, this seems like a risk management issue — wouldn’t the most obvious solution be buying a Nexus Mutual policy to cover the treasury?

Paging @koeppelmann

1 Like

I think you need both, insurance & better security practices, if we’re trying to be “serious”.

We can insure the funds, but we cannot insure the very real infrastructure the dxDAO manages (ENS, dApps, Protocols).

It’s for this reason that I think any improvement to security is necessary to improve the dxDAO’s viability for future success.

1 Like