Contract Verification - Constructor Arguments
Note: Moonriver (MOVR) on Kusama is a companion network to Moonbeam and provides a permanently incentivized canary network. New code ships to Moonriver first, where it can be tested and verified under real economic conditions. Once proven, the same code ships to Moonbeam on Polkadot.
Polygon PoS (polygonscan.com) is an EVM-compatible environment optimized for high throughput and low transaction fees while Polygon zkEVM (zkevm.polygonscan.com) is an EVM-equivalent ZK rollup designed for security.
The Constructor Arguments are automatically appended to the end of the contract source bytecode when the contract is compiled by Solidity.
These are a few examples of contracts with Constructor Arguments:
https://arbiscan.io/address/0x4Fe2d119873790cc9e15F6cC53cae1C2eb2039dC#code
https://arbiscan.io/address/0xd95c2d570c35eb85537b7cbbe0b3e1dc5efce7df#code
When verifying the contract source code at Arbiscan we require that you also provide us with the Constructor Arguments (if the contract required these) used when deploying your Arbitrum smart contract. We will use this information to perform a blockchain search to see if it matches with the existing bytecodes. The Constructor argument should be provided in ABI hex encoded form.
00000000000000000000000033daedabab9085bd1a94460a652e7ffff592dfe3000000000000000000000000fec8bb460c2501b8c1d4801f34b4408c1fbbccb1
Which when decoded would be
Arg [0] : 00000000000000000000000033daedabab9085bd1a94460a652e7ffff592dfe3
Arg [1] : 000000000000000000000000fec8bb460c2501b8c1d4801f34b4408c1fbbccb1
Another quick and dirty way of figuring out what your constructor arguments are is to compare both the browser solidity/remix compiled bytecode and compare this with the input creation bytecode. If you look carefully you will notice that the additional hex codes attached at the END of the input created bytecode. This is your 'Constructor Arguments'.