I’m pleased to announce the latest release of solt - the Solidity tool.
solc-sjw, the project quickly outgrew the basic usage of writing Solidity standard json output for your smart contracts
and has been renamed as a result
with a more streamlined set of commands and options to suit all your Solidity contract verification from the command line,
no matter the project’s structure or framework you’re using to develop with.
Installing the latest version (v0.4.0 at time of writing)
These installation steps are available in the README of the repository which will have the latest versions and kept up to date, but are replicated here for those wanting to play along at home. (Although I highly encourage you to follow the repository for notifications on future releases)
wget https://github.com/hjubb/solt/releases/latest/download/solt-linux-x64 -O ~/.local/bin/solt chmod +x ~/.local/bin/solt
wget https://github.com/hjubb/solt/releases/latest/download/solt-mac -O ~/.local/bin/solt chmod +x ~/.local/bin/solt
solc-sjw, developers were able to write a JSON file containing the source codes of every smart contract in a base folder,
which could be used with Etherscan’s verification portal. This approach was good
to test drive passable solutions, but fell short of the potential for a tool like this. I set out with a simple goal, to remove the
problem of supplying verified source code for your deployed smart contracts. Using the latest version of
you are now able to achieve the same result as the previous
solc-sjw tool with some major improvements.
Input can now be either a folder (as before), OR a specific file (as heavily requested)
The previous JSON output writer functionality can be replicated, on either a folder or file by running:
solt write src/somefolder # or solt write src/somefolder/contract.sol
in the base of your smart contract’s repo (where you’d usually have a truffle config or a
This outputs the normal
solc-input[-name].json so you can write out multiple JSON files if you are verifying a lot of
contracts at once. The usual
--runs flags are available, so you’ll need to match
whatever the optimization specific flags with whatever your config might be, or your build tool’s defaults.
If you’re deploying separately released contracts through a repo with shared dependencies that might look like this:
$ solt write src/SystemA/OurToken.sol # collecting etc... file written to: solc-input-ourtoken.json $ solt write src/SystemB/Controller.sol # collecting etc... file written to: solc-input-controller.json
Better error handling (ongoing)
You’ll now conveniently be presented with an error if
solt found non-relative/absolute dependencies, usually resulting
from having NPM imported libraries if you’re using something like Truffle. The new file functionality removes the
headaches developers were having where they would have to manually remove tests, migrations and other unrelated contracts from the output,
and entirely eliminates the need to exclude file extensions if you use .sol or .t.sol files for testing.
Some cryptic errors that resulted in trying not to spew too much stacktrace from the CLI has been fixed up so that you’ll
get at least some help to point you in the direction of the problem, although in most cases that was covered by not having the
flag or not running
npm install in the repo before trying to collect those dependencies (it me).
The most important and exciting improvement, the reason for the project’s name change and expansion in functionality comes
with the second mode of operation, verifying smart contracts from the command line. There are tools out there that might
plug into your framework or ecosystem, one of the most notable I’ve seen for Truffle being Rosco’s truffle-verify-plugin,
which itself recently received an update!. Some people however
don’t have the option, whether by their choice of development tooling or otherwise. This is where
solt comes in.
Someone using the tools from dapp.tools for instance, in conjunction with something like dapp-pm to manage their dependencies was out of luck until now, and I’ve tried to make it as easy as possible for users to get their deployed contracts verified with as little headache as possible. This means including all the API keys necessary so that (best case) you shouldn’t need to create, store, and manage your own Etherscan API key if you don’t want to, although you can do that as well.
The most basic usage for
solt verify takes the form of:
$ solt verify [file] [address] [contract name] -c [compiler version like 'v0.6.12']
Points to your
solc-input.json that was generated in the
solt write step
This is simply your
0x address of the deployed contract
This can take a couple of forms:
- the name of the main smart contract (this is required by Etherscan, might be able to automate in future). Right now
it will search your
solc-input.jsonfor a key in the
"content":section for the first match, so it can be as long or short as you want e.g.
MyERCwill match a key of
- the name as before with our own mapping or custom name. This is what you see on Etherscan’s code section of a contract under “Contract Name:”
which is useful for remapping the name to the overall purpose of the contract with its dependencies e.g.
src/mytoken/ERC20Impl.sol:UsefulToken. If you don’t use a custom mapping it’ll just take the file name without extension, so the previous example will show up as
--compiler / -c
The compiler flag is the same as Etherscan’s web portal and I might be able to extract this from build artifacts,
but at the moment it’s easy enough to specify.
Made easier is the fact that whatever you specify here is the first available match, so specifying
-c v0.6 will match
-c v0 (if for some reason you like to live dangerously) will at the time of writing this match
This simply uses a different Etherscan API endpoint, all of which should be supported the same from my testing as their explorer. Chances are if you can see a deployed contract on Etherscan’s explorer you can probably verify it by the same value in this flag as the subdomain (if you are verifying on mainnet you can leave this blank)
--etherscan API Keys
I’ve packaged API keys with the tool, and I can only see the packaged Etherscan key becoming problematic, so this should rarely need to be specified. If however you want to use your own keys (so other users don’t have to create accounts, generate keys and use them here if the shared keys get rate limited), you can specify these or pass them through some CI process or environment variable in the command line:
solt verify ... --infura $INFURA_KEY --etherscan $ETHERSCAN_KEY
Putting It All Together, a Dapp Example
For simplicity, I won’t go into how to get dapp.tools up and running on your machine,
nor will I won’t go into much detail about setting up the deployment process for a project using dapp.tools,
as these can vary form being as simple as talking directly to your json-rpc eth node with an account unlocked, to deploying with custom scripts
using other libraries and languages that use the compiled ABIs. I will simply substitute the deployment step with
[run deployment magic here 🧙].
You’ll want to create and enter the directory your contracts will be created and verified from like some variation of the following:
$ cd ~/coolprojects $ mkdir verified && cd verified
Following this you’ll want to run:
$ dapp init
which will generate your basic project structure, and a Makefile used for building / debugging / deploying your project.
Next, we’ll create a simple ERC20 token, because the world can’t have enough of them – but wait, instead of writing out
an IERC20.sol and implementing it, or specifying some cool
mapping(account=>uint256) balances and other variables,
we will just use OpenZeppelin’s contracts via a simple dapp-pm command:
$ dapp-pm firstname.lastname@example.org ERC20.sol
Implementing a token
Now all we need is our own implementation of the token with a cool name, symbol and maybe even mint some, so that they can actually be sent to other users or traded somewhere.
Dapp tools already made us a file at
./src/Verified.sol which will be our starting point, the only thing we need to add is the import for
ERC20.sol and a constructor which mints us some tokens to play with:
Now we have a contract to deploy, and we can do so with our
[run deployment magic here 🧙] step.
NB: you will want to take note of whether optimization took place through compilation with how many runs for this next step
If you want to follow the same config as me, I didn’t use any optimization, with compiler version
v0.6.7. As a result
solt write step will look like:
$ solt write ./src/Verified.sol --no-optimization
which will output a file called
solc-input-verified.json. Taking note of my deployed address, I can verify my contract (which is deployed to rinkeby)
with the following command:
$ solt verify solc-input-verified.json 0xD66888E0815B87c19b04Fa9DcD495CAb49928912 Verified -c v0.6.7 --network rinkeby
which, after executing and waiting for the result, should return us a
Pass - Verified at the end of execution, or if you’ve just run the exact
same command as I wrote above, it will probably tell you it’s already been verified…
You can check out the output result for my deployed cool token here.
Congratulations you are now the proud owner of 100% of the 10*10^-18 total CoolTokens in existence, don’t spend them all in one place!
If you’ve found
solt useful reach out to me and let me know on Twitter @harris_s0n or by showing your appreciation
on the repository on GitHub. If you have any suggestions for feature improvements don’t hesitate to reach out on either platform either by DM, tagging me, or raising an issue!
I’ll be looking forward to adding extra features as requested and building the Solidity tool you look forward to using.
If you got this far thanks for your time, I hope I save you some in the future with