feat(`forge script`): preview, batch, and execute Gnosis Safe transactions (ape-safe)

[Anish-Agnihotri]

Component

Forge

Describe the feature you would like

Description:

My favorite tool from the Brownie/Vyper ecosystem is ape-safe. It lets you:

1. Setup some actions (calling various functions, piping data together in Python)
2. Preview the side effects, running those actions via a Brownie mainnet fork
3. Once everything looks good, batch all the actions via MultiSend and send as one transaction for signers to approve

Now that Foundry is adding support for a local node and deploy scripts, it would be useful to have similar functionality out of the box.

Example:

I'm not sure what this looks like practically yet, but it might just be an executable Solidity script (transcribing the ape-safe Python example):

function script() public {
  Safe gnosis = Safe(0xfeb4acf3df3cdea7399794d0869ef76a6efaff52);

  ERC20 public dai = ERC20(0x6B175474E89094C44Da98b954EedeAC495271d0F);
  yVault public vault = yVault(0x19D3364A399d251E894aC732651be8B0E4e85001);

  uint256 amount = dai.balanceOf(address(gnosis));
  dai.approve(vault, amount);
  vault.deposit(amount);

  // Generate preview transaction
  cheats.preview();
  // Batch transaction
  cheats.batch();
  // Broadcast transaction
  cheats.broadcast(address(gnosis));
}

Potential use-cases:

Some potential applications:

• Automating contract setups or common governance actions
• Using like Hardhat tasks, see example in dYdX repo
• Using like optimism's chug-splash as a mass-deployment system

Additional context

No response

[onbjerg]

Can you expand on cheats.preview/cheats.batch?

[gakonst]

Can you expand on cheats.preview/cheats.batch?

I think cheats.preview() is unneeded given we have traces?

cheats.batch() would probably convert all transactions into a gnosis safe execTransaction? might need a better name

[Anish-Agnihotri]

Thanks for bump—yes, cheats.batch() is just generating a multi-call transaction.

[onbjerg]

Is there a standard for that we can use? @gakonst mentioned Gnosis Safe, but I wonder if cheats.batch would be general enough. Alternatively, this should(?) be solveable using utility libraries (perhaps we can add it in forge-std) by encoding the transactions into e.g. a Gnosis Safe transaction and broadcasting that

[Oighty]

Is there interest in supporting this feature? I think it's a natural extension to scripting and would help teams avoid manual Gnosis Transaction Builder inputs or relying on another tech stack (e.g. python with ape-safe) for setting up MS transactions. forge script currently is good for deployment and setup, but breaks down if you change over the admin address to a MS contract (which you can't send txns from with vm.broadcast()).

An initial version could be similar to the first iteration of CREATE2, hardcode the MultiSend contract from Gnosis and use their format for encoding transactions. The user would provide their safe address and a API call could be sent to the Gnosis Transaction Service to initiate the transaction.

API could mirror broadcasting with something like vm.startBatch() and vm.stopBatch(). The CLI could reuse the --broadcast flag and call the script in the same manner as existing ones.

I looked through the codebase a bit to see where it could naturally fit in, but I don't have a strong grasp of the existing scripting architecture. I am willing to work on this, but am not very experienced with Rust so I would need some pointers.

[gakonst]

Yep I think that's valuable. Motivation makes sense.

Can you give a description of how you imagine the API working and then how a list of transactions would get encoded internally into a gnosis safe TX?

[eboadom]

+1 on this, would really improve the developers' experience of interacting with Safe, without going out of Solidity code, which is a quite typical use case.

Regarding the API, maybe following the approach of other tx sender types like --ledger. So something like --safe-multisig and setting --sender as the specific Safe instance.

[mds1]

Here's a potential UX: First, we add logic to scripting so that it can take the gas estimates and split all broadcasted txs into chunks of 30M (or whatever the gas limit is per-chain). This has two use cases: (1) batching multi-sig txs into a single tx, and (2) batching flashbots txs into a single bundle.

For (2), we use that logic when the flashbots RPC (or --flashbots?) is passed, and automatically split the script broadcast into as few bundles as possible

For (1), if you pass --sender <address>, use the RPC to check if that's a known contract wallet (gnosis safe being the main one we should support first, maybe expanding to argent and DSProxy later). If so, bundle the txs into as few txs as possible. Then for each, either:

1. Print the tx calldata so it can be copy/pasted into the UI
2. Not sure if this is doable, but open the UI to the gnosis safe tx page with the multisig loaded and calldata automatically prefilled
3. Use the Safe tx service @Oighty mentioned above. I'm not familiar with this but it sounds like it might be the best option if it lets you initiate the tx

For dry runs, you might not have an RPC provided which means you can't infer that it's a multisig tx that needs bundling, so perhaps there's also a --multisig <walletType> to force this instead of relying on inference

[Oighty]

API

An alternative to passing the safe address to --sender or another CLI param could be to include it in the forge-std API, e.g. vm.startBatch(safeAddress). My thoughts on the Solidity API were to be able to create different batches in one function with blocks of vm.startBatch() and vm.stopBatch() bounding them. @mds1 makes a good point about the transaction gas limit which should be checked for each batch.

A rough example would be:

function swap(uint256 amountIn) public {
  address safe = vm.envAddress("MS_ADDRESS");

  // Get amount out for swap
  uint256 minAmountOut = router.getAmountOut(path, amountIn);

  // Start batch
  vm.startBatch(safe);

  // Approve the router for the swap token
  token1.approve(router, amountIn);
  
  // Execute swap
  uint256 amountReceived = router.swap(...);
  
  // Stake tokens received in a contract
  token2.approve(staking);
  staking.stake(amountReceived);

  vm.stopBatch();
}

Transaction Encoding

The MultiSend contract expects the transaction batch to be encoded as follows:

    /// @dev Sends multiple transactions and reverts all if one fails.
    /// @param transactions Encoded transactions. Each transaction is encoded as a packed bytes of
    ///                     operation as a uint8 with 0 for a call or 1 for a delegatecall (=> 1 byte),
    ///                     to as a address (=> 20 bytes),
    ///                     value as a uint256 (=> 32 bytes),
    ///                     data length as a uint256 (=> 32 bytes),
    ///                     data as bytes.
    ///                     see abi.encodePacked for more information on packed encoding

Gnosis has implemented logic to batch transactions in this format in ethers-multisend, which should provide a good starting point.

Transaction Submission

The Safe Transaction Service allows Safe owners and their delegates to initiate transactions, which will appear in Safe app for signers to execute. In this context, --broadcast or another flag could be used to designate whether the batch is sent to the service for execution.