Loading...
Loading
Loading
Publish the source of a contract you deployed on Bittensor EVM, so anyone can read the code that runs at its address. This guide covers the verification form.
Verification recompiles your source and compares it with the bytecode on chain. A match proves the code, not the name: anyone can deploy a contract with any name.
A verified contract shows its source files, its ABI and its compiler settings on its contract page, with the match it reached.
.json file of at most 5 MB. Vyper isn't supported.A submission that finds the contract already verified with an exact match sends nothing, and doesn't count against your allowance.
The standard-JSON input is what your build tool gives the Solidity compiler: every source file (sources) and every setting (settings: optimizer, EVM version, remappings, viaIR). Take it from the build that produced the deployed contract.
Print it for the deployed contract, and save it to a file:
forge verify-contract <address> src/Token.sol:Token \
--show-standard-json-input > token-input.json--show-standard-json-input only prints the input; nothing is submitted anywhere. Alternatively, build with forge build --build-info and upload the file from out/build-info/: the form reads its input.
Compiling writes build-info files to artifacts/build-info/. Each one's input field is the standard-JSON input:
npx hardhat compile
ls artifacts/build-info/Upload the build-info file that contains your contract as it is: the form uses its input and fills in the compiler version from its solcLongVersion. If your Hardhat version writes a separate .output.json beside it, upload the other file.
A build-info input holds every file compiled in that run, so a large project's can be over 5 MB. Foundry's --show-standard-json-input includes only the files the one contract needs.
Use solc's full version with its commit, for example 0.8.30+commit.73712a01. In the form, type the release (0.8.30) and pick it from the list. A build-info file names it as solcLongVersion, and solc --version prints it.
It must be the version the contract was deployed with: a different version almost always produces different bytecode.
The contract to verify, written path:Name: the source file's path exactly as it appears under sources in the input, a colon, and the contract's name. For example src/Token.sol:Token.
After you upload the input, the form lists the deployable contracts it found; interfaces and abstract contracts are left out because they compile to no code.
The creation transaction hash is optional. With it, the verifier also checks the contract's creation code; a wrong hash fails the verification.
Verification usually takes under a minute. You can leave the page: its link shows the result later, while you are signed in.
An exact match reproduces the deployed bytecode byte for byte, including the metadata hash; a partial match reproduces the code that runs, but the metadata hash (comments, file paths or unrelated settings) differs.
When a verification fails, the result says why. The usual causes:
viaIR, the EVM version, a library address or a source file. Upload the input from the build that produced the deployed contract.A verified contract's name is chosen by whoever deployed it. Verification proves the code, not who wrote it or what it is called.