Introduction
Whitelist the Aave Companies’ Gnosis Safe multisig, to vote-lock the B-80BAL-20WETH owned by the Aave Companies’ treasury into veBAL and participate in governance for the Balancer DAO.
Motivation
The Aave Companies are software developers who build open source, blockchain based software, including the Aave Protocol – an open source, decentralized, non-custodial liquidity protocol that allows users to supply and borrow crypto assets.
The Aave Companies have been a long-term user of the Balancer AMM, and currently hold the equivalent of ~252k BAL. This BAL was acquired through early investments and as rewards in exchange for participation in BAL boosted LPs.
Given this support, the Aave Companies would like to engage in Balancer DAO governance through veBAL.
Risks
The Aave Companies recognise the risk of allowing smart contacts to vote-lock veBAL, and commits to not using this safe for tokenizing veBAL. We understand that doing so will likely prompt the removal of the safe’s address from the AllowList.
Specification
Whitelist the Aave Companies’ Gnosis Safe multisig, 0xe8d4D93D9728bD673b0197673a230F62255C7846, to interact with the veBAL contract.
The concern with whitelisting Gnosis Safes is that, IIUC, there are no guarantees that a system cannot be built on top of it that tokenizes veBAL. In other words, trust considerations aside, it is equivalent to whitelisting a contract without seeing its source code first. Someone please correct me if I’m wrong.
Have you considered adopting a solution like Tribe’s?
there was a shared agreement that doing what you described is not allowed and;
if that agreement is broken then governance would immediately remove the contract from the allowList? This would mean the multisig would have no interest in breaking the agreement.
I think lots of projects and DAOs will be interested in using their safes out of the box without any changes.
But even if veBAL can still be used the use case of a contract meant to tokenize veBAL completely loses all attractiveness: no further BAL can be locked + over time the veBAL will decay to zero as the lock can’t be extended.
I would only be concerned if at some point a safe holds enough BAL to do a hostile attack on governance (which would be counter intuitive as that would cause the veBAL holder to suffer financially as it would very negatively impact BAL). But that is even tangent to it being possibly tokenized, it could happen with any EOA.
To me the advantage of increased amount of participation/activity by allowing safes of trusted DAOs/protocols by far outweighs the risks mentioned.
Curious to hear more opinions on this as this is a quite important subject.
I think it is beneficial to veBAL to have a diverse set of locking projects/protocols, rather than only allowing Aura for example and forcing projects like Aave to go through them. So I would be in favor of most proposals like this to authorize a gnosis safe to lock from a project we have a good relationship with.
Frankly I think there’s a strong argument to be made for going to a blacklist over a whitelist. Putting pressure on Balancer to say “this is a good contract, this is a bad one” is not an effective use of our time. There is also the reputational risk for us whitelisting a contract after we’ve reviewed it that ends up having a problem or acting maliciously.
With a blacklist, we only need to act to stop obvious bad actors. It’s not totally clear to me what a bad actor could do to harm the system anyway. If people want to deposit their BAL into shady contracts, they should be allowed to do so imo. This is the defi permissionless way. Let BAL holders decide (by where they put their money) what contracts are to be trusted - remove the burden from our engineers & governance.
I generally agree with this idea, as you pointed out creating a process around whitelisting isn’t very permissionless and creates overhead for the DAO. Those deciding on which addresses to approve vs not take on the full responsibility of what happens after. You will still have that contro layer via a blacklist.
I am also trying to think of what is the worst that can happen from allowing smart contracts to lock BAL BPT for veBAL (especially since veBAL will decay). In order to acquire veBAL you also had to have acquired 80/20 BPT, so risk seems lower to me. I am however not a smart contract expert, so would be curious to know if any devs have real concerns with any potential exploits.
Thanks for the comment @markus , we appreciate the opportunity to have an open discussion and appreciate TribeDAOs proposed solution to the potential risk you mentioned. However, we feel this solution adds unnecessary complexity and could potentially introduce smart contract risks. Multi-sigs reduce the risks that come with EOA’s, such that a boost delegation contract is not the right solution. Like @solarcurve , we also want to see as many DAOs, and protocols involved with governance as possible (across the entire ecosystem – this is a new kind of composability) and relying on creating custom code or a single EOA is a significant barrier to this goal.
We would be interested to see a draft agreement per @Fernando 's suggestion where there would be no tokenisation of veBAL deposits. Such a draft could become a template for future DAO participants.
We think that the community can also propose more long term solutions for BalancerDAO to remove the necessity of WLing Gnosis wallets and instead replace this with blacklisting as mentioned by @solarcurve . This may reduce complexity, help to bring in more liquidity to the Balancer ecosystem and reduce friction in the governance process. This is a far bigger strategic decision which needs to be discussed separately by the community.
I agree that the discussion about going to a BlockList as opposed to an AllowList is a separate discussion and has merit to it.
For us to move forward here I’d suggest you simply make an edit to the original proposal adding something like: “Aave Companies commits to not using this safe to tokenizing veBAL and we understand that doing so will likely prompt the removal of the safe’s address from the AllowList.”
This should be more than enough for the veBAL holders to feel safe about this.