solt icon indicating copy to clipboard operation
solt copied to clipboard

Verification fails due to relative path in json output (and useLiteralContent flag?)

Open coindegen opened this issue 2 years ago • 1 comments

First off thanks for the tool, it works a charm once I make some minor tweaks to the json output.

There appears to be only a single factor preventing my contracts from verifying out of the box. Testing with this contract, I am able to verify without a problem using Hardhat, but solt doesn't work without some manual adjustments (using solt write contracts/NFT.sol --npm). Here is the difference:

Hardhat output (excerpt)

{
  "language": "Solidity",
  "sources": {
    "contracts/NFT.sol": ,
    "@openzeppelin/contracts/access/Ownable.sol": ,
    "contracts/ERC721A.sol": ,
    "@openzeppelin/contracts/utils/Strings.sol": ,
    "@openzeppelin/contracts/utils/math/SafeMath.sol": ,
    "@openzeppelin/contracts/utils/Context.sol": ,
    "@openzeppelin/contracts/token/ERC721/IERC721.sol": ,
    "@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol": ,
    "@openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol": ,
    "@openzeppelin/contracts/token/ERC721/extensions/IERC721Enumerable.sol": ,
    "@openzeppelin/contracts/utils/Address.sol": ,
    "@openzeppelin/contracts/utils/introspection/ERC165.sol": ,
    "@openzeppelin/contracts/utils/introspection/IERC165.sol": 
  },
  "settings": {
	"outputSelection": {
	"*": {
	"*": [
		"abi",
		"evm.bytecode",
		"evm.deployedBytecode",
		"evm.methodIdentifiers",
		"metadata"
	],
	"": ["ast"]
	}
	},
	"libraries": {}
  },
}

solt output (excerpt)

{
  "language": "Solidity",
  "sources": {
  "./contracts/NFT.sol": ,
  "./contracts/ERC721A.sol": ,
  "@openzeppelin/contracts/access/Ownable.sol": ,
  "@openzeppelin/contracts/utils/Context.sol": ,
  "@openzeppelin/contracts/utils/Strings.sol": ,
  "@openzeppelin/contracts/utils/math/SafeMath.sol": ,
  "@openzeppelin/contracts/token/ERC721/IERC721.sol": ,
  "@openzeppelin/contracts/utils/introspection/IERC165.sol": ,
  "@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol": ,
  "@openzeppelin/contracts/token/ERC721/extensions/IERC721Metadata.sol": ,
  "@openzeppelin/contracts/token/ERC721/extensions/IERC721Enumerable.sol": ,
  "@openzeppelin/contracts/utils/Address.sol": ,
  "@openzeppelin/contracts/utils/introspection/ERC165.sol": 
  },
  "settings": {
      "metadata": {
          "useLiteralContent": true
      },
      "optimizer": {
          "enabled": true,
          "runs": 200
      },
      "outputSelection": {
          "*": {
              "*": [
                  "abi",
                  "evm.bytecode",
                  "evm.deployedBytecode",
                  "evm.methodIdentifiers"
              ],
              "": [
                  "id",
                  "ast"
              ]
          }
      }
  },
}

As you can see, the only difference is the relative paths "./contracts/...". When I manually delete the ./ from the solt output, verification passes. When I leave it in it fails.

By the way, I'm not using solt to verify since I have to do it programmatically by calling the Etherscan API. Here is my payload to the https://api-rinkeby.etherscan.io/api endpoint:

apikey:HDBRZ227RPV6YFG2QY1SCKE6IG3P7F1234
module:contract
action:verifysourcecode
sourceCode:{ "language": "Solidity", "sources": { "contracts/NFT.sol": { "content": "// SPDX-License-Identifier: MIT\n// Creator: Scatter v0.0.1\npragma solidity ^0.8....
contractaddress:0x0533e3804011869eac9bdca0041983cb9d41f054
codeformat:solidity-standard-json-input
contractname:contracts/NFT.sol:ScatterNFT
compilerversion:v0.8.4+commit.c7e474f2

Perhaps this is also due to the useLiteralContent setting? That's the only other difference I see. Hardhat defaults it to false instead of true for every write. Not sure about this since, after making the above tweak, when I leave it as true verification still works.

From the docs:

    "metadata": {
      // Use only literal content and not URLs (false by default)
      "useLiteralContent": true,
     ...
 } 

coindegen avatar Mar 24 '22 11:03 coindegen

Cheers for the info, I'll give it a test and see if excluding that ./ breaks anything otherwise will implement that change if it helps out in future :+1:

hjubb avatar Mar 24 '22 23:03 hjubb