I have used the truffle upgrades plugin to deploy a TransparentUpgradeableProxy on Boba Network. It seems nobody has deployed a contract with matching bytecode before. How can I verify it on Boba BlockScout?
First I tried verifying with Sourcify. Since I'm using the plugin, truffle doesn't create a
TransparentUpgradeableProxy.json in my project's
build/contracts folder. There is one in
node_modules/@openzeppelin/contracts/build/contracts, but it doesn't include the required
metadata field and I'm not sure how to construct one.
Then I tried verifying a flattened version. The proxy was deployed with truffle-upgrades 1.11.0. So I flattened
openzeppelin-contracts v4.1.0 and then submitted for verification specifying solc 0.8.2 and 200 runs for the optimizer. But although the constructor args I submitted appear at the end of the creation transaction I got the error "Constructor arguments do not match". The Boba folks say that flattened contract verification can be "flaky".
initialize() takes two address parameters,
(0x4200000000000000000000000000000000000010,0xef5fa9f3dede72ec306dfff1a7ea0bb0a2f7046f). That function call is encoded as
The proxy constructor receives
address _logic, address admin_, bytes memory _data. Those are
(0x5Ded6742e5f77A92556123C9B26fE965fC6A99e6,0x9f4AbB5998dcf1CCF16323B13Cd1d7Eb099a0b1c,<above function call>).
Encoding as ABI yields
0000000000000000000000005ded6742e5f77a92556123c9b26fe965fc6a99e60000000000000000000000009f4abb5998dcf1ccf16323b13cd1d7eb099a0b1c00000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000044485cc9550000000000000000000000004200000000000000000000000000000000000010000000000000000000000000ef5fa9f3dede72ec306dfff1a7ea0bb0a2f7046f00000000000000000000000000000000000000000000000000000000. I think this is right since it matches the end of the contract creation code displayed on BlockScout.
related OZ forum posts
How to verify a contract on Etherscan/BscScan/PolygonScan provides a standard JSON input for verification, but blockscout doesn't accept that format. Verify hardhat upgradeable proxy on blockscout is relevant but there hasn't been a follow-up by anyone who successfully verified.
My last resort will be this kludge. I wish there was a better flow for verifying the plugin's contracts. The time I've spent on this has outweighed what I gain from not just symlinking the contracts and building + deploying myself (though I wouldn't get the plugin's security checks).