When we try to enact we get "The action failed to execute. You may not have the required permissions."

We are using the Aragon Dandelion template. We put in the request for a withdrawal, voted and reached quorum, and waited for the timeline to expire. The vote is passed and in pending state. When we click enact, we get this error: “The action failed to execute. You may not have the required permissions.”.

We have done withdrawals like this in the past with no issues.

Here is a link to our DAO: Aragon. It is vote #100 giving us the issue. Please help us ASAP as this is time sensitive. I have also posted on the discord #support channel.

Hi there :wave: Isabella from Aragon here - I’ve just checked our Discord channel and it seems your question has been cleared, can you please confirm?

Thanks!

Thanks for your response. I’m still having the same issue.

Someone had suggested that the issue might be because we are withdrawing to a contract wallet. The recipient is a Gnosis Safe. Is this not supported?

Hey @funkyengineer, thanks for the update and sorry for the trouble caused. I asked our team to check this info for you - will keep you posted.

So I tested it on rinkeby where I did a withdrawal to a gnosis wallet and a withdrawal to a regular wallet. I only got the error for the withdrawal to the gnosis wallet. So, I assume this is the issue. However, the DAO members have paid a lot of gas in aggregate to vote on this. My question for the team is, can you fix this so that it is possible for me to execute the transfer to a Gnosis Safe multisig wallet?

Hi there, we had a closer look at the problem you have reported.

Because the Gnosis multisig doesn’t have the receive or fallback method accordingly implemented for a simple address.send call does it not work as expected.

The OOG error is due to the fact the transfer was done over the contract with the address.send call who strictly forwards 2300 gas.

I’m afraid that we’re unable to retrieve this action on our end - I suggest you to contact Gnosis and report the issue to them.

1 Like

So the issue is that since the Berlin hardfork the gas costs have increased and therefore it is not possible to widthraw ETH to a contract via send or transfer that has not been accessed in this transaction before (aka a cold address). (See EIP-2929 for details).

The solution is to make sure that the target address (in this case the MultiSig) is “warm”. There are 2 ways for this:

  1. Execute the proposal via the target address: the address of the MultiSig has been used when calling the contract that triggers the sending of ETH, therefore it is “warm”
  2. Use the access list feature to add mark the address as “warm” ahead of time (see EIP-2930). An example how this could look like with Ethers for a Gnosis Safe contract can be found here)

Hope this helps

Thank you for the reply. I assume you are from the Gnosis team @rimeissner?

I just want to clarify exactly what we are doing to make sure what you are saying still applies:

  1. Authenticate into Aragon using a hot wallet via metamask
  2. Enact the transaction
  3. Get error on the UI

It seems like you are referring to executing a transaction from the Gnosis safe, however we are just executing it from a regular hot wallet, and sending it to the Gnosis safe. @nivida is saying Gnosis can’t receive the funds because “Gnosis multisig doesn’t have the receive or fallback method accordingly implemented for a simple address.send call does it not work as expected”. Is there anything Gnosis can do to resolve the issue?

Yes, I am working on the Safe team.

So actually it doesn’t matter if you trigger the withdrawal from a private key based account (e.g. MetaMask) or a contract account (e.g. a Safe). Since the hardfork it became a little tricky if you try to withdraw to ANY contract account (as mentioned above because of EIP-2929). This is because the gas gosts have been increased when accessing an account for the first time in a transaction.

Therefore one solution would be to trigger the withdrawal from the reveiving contract if that is possible (e.g. if it is a Safe and you control the Safe that you want to withdraw to).

The other solution is to use the access list feature introduced with EIP-2930, to “pre-load” the contract of the account you want to withdraw to (therefore the gas costs are lower during runtime again).

The second solution is currently not possible with MetaMask afaik (they should be working on it, as this will become the new standard in the long run). You would have to use an extra tool with your private key to make this work.

Edit: if you prefer a more direct communication you can hop to chat.gnosis.io and join the #safe channel. I would later cross post the solution here :wink:

Edit 2: Gnosis multisig doesn’t have the receive or fallback method accordingly implemented for a simple address.send call does it not work as expected . The Safe implements a payable fallback function, so this is not the cause. I am very sure that this is related to EIP-2929 and can be solved using EIP-2930

The issue I see is that the Aragon interface even does some check beforehand (either itself or because of the used web3 lib) and therefore it doesn’t even get to the execution/ signing dialog of MM for me.

E.g. if eth_estimateGas is used then this will always fail right now, unless you provide the correct access list. (See Understanding gas costs after Berlin - HackMD for more information)

@nivida could you point to a resource that outlines how to enact a vote on contract level. This would allow to create a tx that can be executed that with the required access list.

Edit: In a perfect case Aragon would upgrade their contract to not use send or transfer :wink: but this might not be feasible right now

Hi Richard…

This is the contract that where executeVote function gets called. Since it’s a proxy, you can still easily see the actual contract behind it which has executeVote - DandelionVoting | 0x417c5ec1e30d37f1d3d54a974e2f384e640046e5

Though: I think @funkyengineer already solved it by calling execTransaction .

If so, we can close this issue.

1 Like