Contract has non-empty code in body of a script but not in a constructor of another contract

[hacker-DOM]

I am encountering a very strange issue. I have

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Script} from "forge-std/Script.sol";
import {Counter, HasNonEmptyCode} from "../src/Counter.sol";

contract CounterScript is Script {

    function setUp() public {}

    function run() public {

        vm.createSelectFork(getChain("mainnet").rpcUrl);

        vm.startBroadcast();
        address counter = address(new Counter());
        // Here, the counter has non-empty code:
        require(counter.code.length > 0, "Counter has empty code");

        // But here, it reverts:
        // contract HasNonEmptyCode {
        //     constructor(address target) {
        //         require(target.code.length > 0, "Target has empty code");
        //     }
        // }
        //
        new HasNonEmptyCode(counter);
        vm.stopBroadcast();
    }
}

The result:

❯ forge script script/Counter.s.sol
Found existing alias for "forge". You should use: "f"
[⠊] Compiling...
[⠰] Compiling 1 files with Solc 0.8.30
[⠔] Solc 0.8.30 finished in 332.03ms
Compiler run successful!
Script ran successfully.
Gas used: 6188337

## Setting up 1 EVM.
Error: Failed with `Target has empty code`:

  [803] → new Counter@0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496
    └─ ← [Revert] 0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000155461726765742068617320656d70747920636f64650000000000000000000000

Error: Simulated execution failed.

The error message indeed corresponds to the require:

❯ python -c 'print(bytes.fromhex("155461726765742068617320656d70747920636f6465").decode())'
Target has empty code

Aka, it seems to be ✅ working for a local empty simulation, but ❌ not for a local forking simulation. I have MAINNET_RPC_URL set correctly to a correct endpoint

I have pushed the code: https://github.com/hacker-DOM/foundry-issue-empty-contract-in-after-deployment-in-script/blob/a478aad33d66469349b18a8a48b4cf5adbd9eee7/script/Counter.s.sol#L23.

[Minhal128]

Reproduced on forge 1.8.3 (cae51ad). It isn't the constructor — the address baked into the constructor argument is stale, because the broadcast sender's nonce differs between the two phases of forge script.

-vvvv shows it:

Traces:                                     <- execution phase
  ├─ [117035] → new Counter@0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496
  ├─ [75777]  → new HasNonEmptyCode@0x34A1D3fff3958843C43aD80F30b94c510645C316

Simulated On-chain Traces:                  <- on-chain simulation
  [58909] → new <unknown>@0x5b73C5498c1E3b4dbA84de0F1833c4a029d90519   <- Counter, 294 bytes
  [803]   → new Counter@0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496     <- actually HasNonEmptyCode
          └─ ← [Revert] Target has empty code

Both phases use the same sender (DefaultSender 0x1804c8AB…) but at different nonces:

0x1804c8AB…  nonce 0 -> 0x5b73C5498c1E3b4dbA84de0F1833c4a029d90519
0x1804c8AB…  nonce 1 -> 0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496
0x1804c8AB…  nonce 2 -> 0x34A1D3fff3958843C43aD80F30b94c510645C316

Logging vm.getNonce(sender) right before startBroadcast() confirms the split:

how the fork is selected	sender nonce in script	Counter deployed at
vm.createSelectFork(...) inside run()	1	0x7FA9385b…
--rpc-url on the command line	0	0x5b73C549…

vm.createSelectFork does not adopt the forked chain's nonce for the (persistent) default sender — it keeps the 1 it already had in the pre-fork environment. So every CREATE address shifts by one slot between the execution phase and the on-chain simulation.

That is what breaks your script. HasNonEmptyCode's constructor argument is ABI-encoded during the execution phase, where Counter is at 0x7FA9385b…, and that calldata is recorded verbatim. During the simulation Counter actually lands at 0x5b73C549…, while 0x7FA9385b… is the address HasNonEmptyCode itself is being deployed to. A contract has no code during its own constructor, so target.code.length is 0 and the require reverts — the argument ends up pointing at the contract that is asking the question.

The new Counter@0x7FA9385b… label on the reverting frame is the same off-by-one: forge names the frame from the execution-phase address map.

Two ways around it

1. Pass the RPC on the command line instead of forking inside run() — the execution phase then starts on the fork, the nonce matches, and both phases compute the same addresses:

forge script script/Counter.s.sol --rpc-url $MAINNET_RPC

function run() public {
    vm.startBroadcast();               // no vm.createSelectFork
    address counter = address(new Counter());
    new HasNonEmptyCode(counter);
    vm.stopBroadcast();
}

2. If you need createSelectFork anyway (multi-chain script, fork chosen at runtime), realign the nonce right after selecting:

vm.createSelectFork(getChain("mainnet").rpcUrl);

(, address sender, ) = vm.readCallers();
vm.resetNonce(sender);                 // vm.setNonce can't lower a nonce

vm.startBroadcast();

Both pass on 1.8.3. Note vm.setNonce is not usable here — it rejects new nonce (0) must be strictly equal to or higher than the account's current nonce (1); vm.resetNonce is the one that can move it down.

Worth an issue in its own right, I think: the divergence is silent, and it only surfaces when a deployed address is captured into calldata. Anything that records an address during execution — constructor args, vm.serializeAddress in a deployment manifest, a registry set(addr) call — inherits the same off-by-one, and in most of those cases nothing reverts, you just get a manifest pointing at the wrong address.