forge script json trace does not respect vm.startPrank for caller.

[jbrower95]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

1.0.0-stable

What version of Foundryup are you on?

1.0.0

What command(s) is the bug in?

forge script

Operating System

macOS (Apple Silicon)

Describe the bug

See the following script:

 // SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Script.sol";

contract EmptyContract {
    uint256 public counter;
    function increment() public {
        counter += 1;
    }
}

contract DeployAndTest is Script {
    function run() external {
        vm.startBroadcast();

        // Deploy EmptyContract
        EmptyContract empty = new EmptyContract();

        vm.stopBroadcast();

        // Arbitrary address A
        address A = address(0x1234);

        // Prank as A
        vm.startPrank(A);
        empty.increment();
        vm.stopPrank();
    }
}

Should the trace for empty.increment show the caller as A, or the deployed address of DeployAndTest?

To repro the trace: forge script script/releases/v1.2.0-genesis/bug.sol --tc DeployAndTest -vvvv --json | jq

IMO, it should be A. This is confusing and counter-intuitive, and is breaking a tool that I'm building. Am I missing something?

[jbrower95]

NOTE that using function startPrank(address msgSender, address txOrigin) external; also does not affect the trace.

[grandizzy]

hey @jbrower95 thanks for your report! yeah, the --json flag is not fully supported for script, see #10019 will look into polishing this

[jbrower95]

For the use-case:

I've built zeus a deployments manager that allows expressing transactions meant to be sent to a multisig. We use forge's prank, and then inspect the logs to reverse-engineer what the transaction the user meant to send was... we're then able to form a Gnosis payload from that.

Transaction detection is a bit more difficult with the traces not respecting the prank, but not impossible.

Thanks!

[grandizzy]

hey @jbrower95 on the second thought, there are entries for for start/stop prank (cheatcodes address is 0x7109709ecfa91a80626ff3989d68f67f5b1dd12d which you can check), so for startPrank/increment/stopPrank sequence entries are like below, would that help?

      {
            ...
            "trace": {
            ...
              "caller": "0x9f7cf1d1f558e57ef88a59ac3d47214ef25b6a06",
              "address": "0x7109709ecfa91a80626ff3989d68f67f5b1dd12d",
            ...
              "kind": "CALL",
              "value": "0x0",
              "data": "0x06447d560000000000000000000000000000000000000000000000000000000000001234",
            ...
            },
            ...
          },
          {
            ...
            "trace": {
            ...
              "caller": "0x9f7cf1d1f558e57ef88a59ac3d47214ef25b6a06",
              "address": "0x7fa9385be102ac3eac297483dd6233d62b3e1496",
            ...
              "kind": "CALL",
              "value": "0x0",
              "data": "0xd09de08a",
            ...
            },
            ...
          },
          {
            ...
            "trace": {
            ...
              "caller": "0x9f7cf1d1f558e57ef88a59ac3d47214ef25b6a06",
              "address": "0x7109709ecfa91a80626ff3989d68f67f5b1dd12d",
            ...
              "kind": "CALL",
              "value": "0x0",
              "data": "0x90c5013b",
            ...
            },
            ...
          }
        ]
      }

[zerosnacks]

You could use the function signatures of startPrank and stopPrank (and its overrides) to detect this

➜ keccak256("startPrank(address)")
Type: bytes32
└ Data: 0x06447d56...

➜ keccak256("stopPrank()")
Type: bytes32
└ Data: 0x90c5013b...