search

safe-global / safe-transaction-service

Keeps track of transactions sent via Safe contacts and confirmed transactions. It also keeps track of Ether and ERC20 token transfers to Safe contracts.
MIT License
190 stars 259 forks source link

After Proposing a transaction via delegate account, my safe is on "This Safe couldn't be loaded" #780

Closed eddieran closed 2 years ago

eddieran commented 2 years ago

Describe the bug we are in order to set up a sign bot to call our own smart contract's external function from our owner account on safe. we propose a transaction on rinkeby via delegate account, then we queued our transaction successfully, we signed the transaction on safe's front-end webpage, transaction was executed, then our safe is gone (literally)

To Reproduce Steps to reproduce the behavior:

  1. i have a safe wallet on rinkeby, safe address: 0x06b56Fbca4288bF036DB874bE316122cCaba0278
  2. i propose a transaction via delegate account , through the API : https://safe-transaction.rinkeby.gnosis.io/api/v1/safes/0x06b56Fbca4288bF036DB874bE316122cCaba0278/transactions
  3. we signed our queue transaction by hands, pending, suceess, then gg. transaction: https://rinkeby.etherscan.io/tx/0x919aeca414cbf1659aad47e187136c81544e0d243e51dd0d24e2bc0b8a3943f4

Expected behavior we expected the transaction could be executed, and in our own contract's function should be called but

  1. our owne contract's function was not called
  2. our safe is gone

Environment (please complete the following information):

Additional context Safe address: 0x06b56Fbca4288bF036DB874bE316122cCaba0278 Delegate Address: 0x3fd7716fcb0768f86937e85f7Dd20562aDd8d9af one of Owner address(delegated): 0x3e17178E073Ffc2A998a2d47c1C98E2aa2268DDb transaction that messed up: https://rinkeby.etherscan.io/tx/0x919aeca414cbf1659aad47e187136c81544e0d243e51dd0d24e2bc0b8a3943f4

and my co-worker got a reply from team:

"Hi there, just got a response from the team. The transaction you did basically messed up Safe contract storage by sending a delegatecall transaction that overwrote the address of the implementation contract in the Safe proxy. Essentially you have bricked the safe and unfortunately it's non-recoverable. 🙁"

but i want to know some more details about this problem.

  1. can the team show the details about how things messed up
  2. Is this a bug? or did we do something wrong? plz tell us more. We are also dev, want to figure out how to solve this problem
  3. What's the next step on safe's side ? how to avoid the same problem on the mainnet? if this problem happened on the mainnet, which would be a disaster
rmeissner commented 2 years ago

This is displayed in the interface and there is a warning that you are performing a delegate call to an unknown contract.

When you propose a transaction the operation should be 0 (CALL).

You can debug/simulate the transaction on tenderly to get more details.

Closing this, since this is not a bug and is also not related to the transaction service.

eddieran commented 2 years ago

thank you for your reply 

operation = 0

means (CALL), but we are going to queue a transaction from delegate account, so should I use operation = 1 or not? but i am still not sure why a not correnct transaction would make the whole safe couldn't be loaded?

by the way, if this is not related to the transaction service, which section should i go to get help?

rmeissner commented 2 years ago

The operation is completely unrelated to how you submit it (either via a delegate or as a owner).

You can read more about delegatecall here or here

As this is more a general question on how the contracts work and not something where the code of the service has to change you can either go to our discord or post on the Ethereum Stackexchange

eddieran commented 2 years ago

Thanks for you reply, i'll go through the link you posted!