`forge verify-contract --flatten` produces different flattened code than `forge flatten` command

[0xLaz3r]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

1.3.5-stable

What version of Foundryup are you on?

0.3.3

What command(s) is the bug in?

forge flatten / forge verify-contract --flatten

Operating System

macOS (Apple Silicon)

Describe the bug

The forge verify-contract --flatten command produces different flattened source code compared to the standalone forge flatten command. This inconsistency causes verification failures on Etherscan because the bytecode generated from the two different flattened versions doesn't match.

Specific Differences Found:

1. SPDX License Identifier Placement:

• forge flatten: Places SPDX license at the very top of the file (line 1).
• forge verify-contract --flatten: Places SPDX license after the first file's content.

2. Interface Name Handling:

• forge flatten: Adds suffixes to disambiguate duplicate interface names (e.g., IContract_0, IContract_1)
• forge verify-contract --flatten: Creates interfaces without suffixes (e.g., IContract)

Impact:

• Verification failures on Etherscan due to bytecode mismatch
• Inconsistent behavior between two commands that should produce identical output
• Developers cannot rely on forge flatten output to match what gets sent for verification

Reproduction Steps:

1. Create a project with multiple files containing duplicate interface names
2. Run forge flatten src/Contract.sol --output flat.sol
3. Run forge verify-contract --flatten --skip-is-verified-check <address> src/Contract.sol:Contract. To capture the source, you can create a fake local verifier server.
4. Compare the two outputs - they will differ in SPDX placement and interface naming

Expected Behavior:

Both commands should produce identical flattened source code, ensuring that local flattening matches what gets sent for verification.

Evidence:

• File size difference
• Different checksums
• Interface naming differences cause different bytecode generation

This bug makes contract verification unreliable and forces developers to use workarounds or manual verification processes.

[grandizzy]

@0xLaz3r I have changes here master...grandizzy:issue-11754 to unify them but would really appreciate a minimal repro, really hard to test it works as expected with provided steps, thank you

[0xLaz3r]

I found the mismatch when verifying this contract: https://github.com/sky-ecosystem/spells-mainnet/blob/master/src/DssSpell.sol

I stored the forge flatten output and then I compared it with the source code sent to Etherscan with

forge verify-contract --chain sepolia --etherscan-api-key "dummy" --verifier etherscan --verifier-url http://127.0.0.1:5001/api --flatten --force --skip-is-verified-check --watch <contract_address> src/DssSpell.sol:DssSpell -vvvv

I'm using a custom verifier url because I'm using a fake server to send the code to and get the output of the forge verify-contract command.

[grandizzy]

@0xLaz3r can you provide the full forge flatten and forge verify-contract commands, I want to test locally if fix works, thank you

[grandizzy]

or maybe you could foundryup from pr #11873 and retry

[0xLaz3r]

@0xLaz3r can you provide the full forge flatten and forge verify-contract commands, I want to test locally if fix works, thank you

This is the contract that I used: 0x9F6c475100F5fFC4e24b27926c188Ef094af8d61

or maybe you could foundryup from pr #11873 and retry

Yes, let me try it as well

[grandizzy]

local tests show consistent results, will merge after getting confirmation from you, thanks!