Device is already in use by another transport when deploying a contract and then propose a tx

[bugduino]

I'm running into an issue while using a script really similar to the following:

pragma solidity >=0.8.28 <0.9.0;

import { Contract } from "../src/Contract.sol";
import { Script } from "forge-std/Script.sol";
import { console } from "forge-std/console.sol";
import { Upgrades, Options } from "@openzeppelin/foundry-upgrades/Upgrades.sol";
import { Safe } from "safe-utils/Safe.sol";
import { IProxyAdmin } from "@openzeppelin/foundry-upgrades/internal/interfaces/IProxyAdmin.sol";

contract DeployScript is Script {
  using Safe for *;
  error Invalid();

  string public constant BUILD_INFO_DIR = "old-build-info/";

  // Gnosis Safe instance
  Safe.Client safe;

  // Optimism test contracts
  string public constant network = "optimism";
  address public constant SAFE_ADDRESS = address(2); // CHANGE THIS
  address public constant PROXY = address(1); // CHANGE THIS 

  function run() public {
    vm.createSelectFork(network);
    vm.startBroadcast();
    console.log('Upgrading in', network);
    _upgradeContractMultisig();
    vm.stopBroadcast();
  }

  // Methods to propose an upgrade to the proxy implementation
  function _upgradeContractMultisig() internal {
    _upgradeViaMultisig(PROXY, "Contract");
  }
  
  /// @notice Prepares the upgrade of the proxy implementation to a new version.
  /// @param proxy The address of the proxy contract to upgrade.
  /// @param oldContract The name of the old contract to upgrade.
  function _upgradeViaMultisig(address proxy, string memory oldContract) public {
    if (proxy == address(0) || bytes(oldContract).length == 0) {
      revert Invalid();
    }
    safe.initialize(SAFE_ADDRESS);

    // https://github.com/OpenZeppelin/openzeppelin-foundry-upgrades?tab=readme-ov-file#upgrade-a-proxy-or-beacon
    Options memory opts;
    opts.referenceBuildInfoDir = string(abi.encodePacked(BUILD_INFO_DIR, network));
    opts.referenceContract = string(abi.encodePacked(network, ":", oldContract));
    string memory contractFile = string(abi.encodePacked(oldContract, ".sol"));

    // Validate and deploy new implementation
    address newImpl = Upgrades.prepareUpgrade(contractFile, opts);
    // Propose upgrade tx with multisig
    safe.proposeTransaction(
      Upgrades.getAdminAddress(proxy), 
      abi.encodeCall(IProxyAdmin.upgradeAndCall, (proxy, newImpl, "")), 
      DEPLOYER,
      "m/44'/60'/0'/0/0"
    );
  }
}

In my script I am deploying a new contract (in this case via Upgrades.prepareUpgrade(contractFile, opts) to deploy a new implementation contract for a proxy) and then I'm trying to propose a tx in the multisig to update the proxy. What I see is that it first triggers an error like below (I guess during the simulation step)

stating that the Ledger is already in use basically.
What happens next is that the new implementation contract is deployed and verified normally but there is no prompt to sign the multisig tx and so the tx is not posted on the Safe.

Any idea why? Seems like some sort of race condition where the Ledger is used both for deploying and signing the Safe tx at the same time

[aviggiano]

Hey

Any idea why? Seems like some sort of race condition where the Ledger is used both for deploying and signing the Safe tx at the same time

I believe this might be the case.

In my tests, I always deployed with one account (created with cast wallet) and proposeed the multisig tx with another account (using ledger), so I never had this issue.

I think this PR foundry-rs/foundry#10330 will solve your problem, as we'd be using ledger natively through Foundry, not with cast and FFI. I'll try to test foundry's PR so that we can get it merged as soon as possible.

Meanwhile, if that's not too disruptive to your workflow, can you try the following?

1. In one foundry script, deploy the contract you need (reference)
2. In another foundry script, propose the multisig tx with the contract already deployed (reference)

[bugduino]

I tried replacing in my script the line

address newImpl = Upgrades.prepareUpgrade(contractFile, opts);

with

address newImpl = 0x12345....

which should have the same effect of just proposing the tx this time using a contract already deployed but got the same result actually.

I'm running the script via

forge script ./script/Upgrade.s.sol --ledger --broadcast --optimize --optimizer-runs 99999 --verify --sender \"0x123456\" --slow -vvv

[aviggiano]

@bugduino once again, thanks for your patience in helping debug this and trying this repo out. I understand that if third-party libs don't "just work," it's easier to fall back to what we're used to 😆. I've done that many times, so I know it can be frustrating. But bear with me, I'm very bullish safe-utils is worth it in the long run. Spoiler alert: I'm working on a blog post advocating for why protocols should migrate from UI-based multisig proposals to Foundry script-based proposals (feedbacks are welcome)

Anyway, back to the issue.

I was reading your error message more attentively, and it says:

Make sure it's connected and unlocked

Have you opened the Ethereum app on your Ledger? If you did, then I think we should wait for vm.signTypedData to be merged.

[bugduino]

No problem thanks to you for support with the issues, it's rare to see such fast replies 🥇 Will check the blog post soon!

The Ledger is connected, unlocked and in the Ethereum app in fact I was able to deploy the contract with the same script, prior to replacing address newImpl = Upgrades.prepareUpgrade(contractFile, opts); with the actual deployed address

[bugduino]

It's strange that even if there are no other uses of the Ledger in the script it's not working, did you got the chance to try it with a Ledger in general?

[aviggiano]

@bugduino I am using ledger in this script https://github.com/SizeCredit/size-solidity/blob/main/script/ProposeSafeTxDeployPTMarkets.s.sol

my Foundry command is

forge script script/ProposeSafeTxDeployPTMarkets.s.sol --rpc-url $RPC_URL --gas-limit 30000000 --sender $DEPLOYER_ADDRESS --account $DEPLOYER_ACCOUNT --ffi --slow -vvvvv

[bugduino]

Ok will do some more tests tomorrow, maybe it could be related to the derivation path

[bugduino]

If I do the command in the screenshot manually so cast wallet sign --ledger --mnemonic-derivation-path "m/44'/60'/0'/0/0" --data "..." it works and I'm able to sign (and cast wallet address --ledger --mnemonic-derivation-path "m/44'/60'/0'/0/0" gives the correct address). So derivation path is correct, I guess there is something wrong the in underlying implementation somewhere

[bugduino]

@aviggiano do you have any other ideas about this or should we wait for foundry-rs/foundry#10330 to be merged? Do you still think that the culprit lies there?

[aviggiano]

@bugduino I don't have any other ideas, I think we should wait for vm.signTypedData unfortunately. Maybe @grandizzy knows what might be the root cause?

[aviggiano]

fyi @bugduino I created this POC for this week's presentation on governance proposals using Safe Utils. I think it may not necessarily solve your problem, but it can be used as a reference implementation.

[bugduino]

Thanks for sharing. One interesting thing I see in the script for ledger here https://github.com/Recon-Fuzz/governance-proposals-done-right/blob/main/script/ProposeSafeTxUpgradeCounterV4WithLedger.s.sol is that you do the safe.proposeTransaction outside the vm.startBroadcast() (so you stopped the broadcast before doing the proposeTransaction). I think this could be relevant. I'll try to test this as soon as I have some time and get back

[bugduino]

I've stripped the code down to the bare minimum

but it still fails, this time with no specific message, it just reverts after getting the nonce from the safe

logs that I set are all correct, but I don't get any prompt in the Ledger to sign.

I'm running the script via

forge script ./script/Upgrade.s.sol --ledger --broadcast --verify --sender \"0x1234...\" --slow --ffi -vvvv

and DEPLOYER is the ledger address of the first account

[bugduino]

I tried to debug a bit

it logs the Sign but it does not log the Sign post nonce

Added a log also here

but it does not log the nonce (even though on the forge trace I see the staticcall to nonce method to be successful, see screen on the prev message). Not really sure what's going on here