abi-encode incorrectly prefixes output with 0x and adds newlines, which causes verification to fail on many block explorers.

[monomadic]

Component

Cast

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.1.0 (0f58c52 2022-03-14T00:08:32.530471551+00:00)

What command(s) is the bug in?

cast abi-encode

Operating System

Linux

Describe the bug

This took about 4 hours out of my day today, but I finally figured out why all of my contracts weren't verifying. I was using an inline shell command to pipe the encoded constructor arguments to the verify-contract function of forge. I tried everything, multiple chains, new projects, different versions of solidity, etc etc.

I eventually tried word for word the example on the Forge book, and it worked. I realised I'd manually pasted the abi this time, so I tried printing the output of abi-encode directly to the terminal. It looks like there are two errors that will break almost any block explorer. I didn't try etherscan itself, so it's possible it works there, but it breaks on avalanche testnet (tried this over and over), bsc testnet, and manually deploying an explorer (and using geth).

Steps to reproduce:

Run cast abi-encode and observe the output.

The initial 0x is not present in earlier examples so I imagine the tool didn't always output like this. Newlines also silently cause the deploy to fail and only part of the contract is uploaded (?!). Very strange behavior.

Since most people are deploying forge contracts with shell scripts I'm surprised it hasn't come up before.

[mattsse]

thanks for looking into this!

The 0x part seems strange because we're already stripping that.
you mean only newlines after the constructor args? and/or in the flattened contract?

Curios if you could share (parts) of your verify script, that I can use to come up with integration test?

[monomadic]

Sure! I'm using zsh if that matters, but I doubt it's my shell (for reasons I'll explain).

If I set up some environment variables like this:

export TOKEN_NAME="USDC Token"
export TOKEN_SYMBOL="USDC"
export TOKEN_PRECISION=6
export TOKEN_SUPPLY=50000000000000000000000

And then I run:

cast abi-encode "constructor(string,string,uint8,uint256)" $TOKEN_NAME $TOKEN_SYMBOL $TOKEN_PRECISION $TOKEN_SUPPLY

I get the output:

0x000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000a968163f0a57b400000000000000000000000000000000000000000000000000000000000000000000a5553444320546f6b656e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000045553444300000000000000000000000000000000000000000000000000000000

Even if I pipe directly to xclip, like this:

cast abi-encode "constructor(string,string,uint8,uint256)" $TOKEN_NAME $TOKEN_SYMBOL $TOKEN_PRECISION $TOKEN_SUPPLY|xclip -sel clip

And then paste it elsewhere, or if I pipe directly to a text document or set an environment variable, the 0x is still there. So it's exiting through stdout like that.

[onbjerg]

Hey @monomadic, is this still the case? I tried running your example, but I do not get the newline at the end. The leading 0x is still present, though, and this is consistent across all of Forge and Cast.

The 0x is now also stripped and the args are trimmed since gakonst/ethers-rs#1024

[onbjerg]

Closing because the issue is stale and I cannot reproduce anymore. Let me know if you still encounter this and we can re-open 😄