Introduction
There are already many written contracts that you can use on ETC, for the most basic contracts you won’t need to write any code yourself.
You’ve got Multi-Sig Wallets, IoT proof of concepts, ERC 223 tokens (and https://tokenmint.io/), OpenZeppelin’s suite of useful contracts, and many other contracts available to you just waiting to be deployed.
For this guide we’re going to be deploying a Multi-Sig wallet and we’ll be taking a very honest look at it, warts, work-arounds, and potential hang-ups will be discussed. It’s not that bad, there’s just some things in the Ethereum ecosystem that still need some polish when it comes to deploying contracts.
Also we’re not going to go over modifying any code, one thing you may want to learn to do though, to make deployment easier, is hard-code your constructor arguments rather than declare them during deployment.
So your Contract’s constructor signature looks like this:
function MyContract() (empty)
Rather than this:
function MyContract(address myAddress, uint256 someNumber) (non-empty)
You can also look through my commit history to see an example of turning a contract with a non-empty constructor into a contract with an empty constructor. It’s all rather simple, just deleting arguments and hard-coding variables.
You may even get an added benefit here of unrolling a loop and saving computation cycles/gas.
Why an empty constructor?
To give a little background, at the moment deployment is complicated due to the following issues:
Parity:
- Doesn’t support any hardware wallet signing for contract deployment
- Does support constructor arguments
MEW:
- Does support support any hardware wallet signing for contract deployment
- Doesn’t support constructor arguments
Classic Ether Wallet:
- Does support support any hardware wallet signing for contract deployment
- Does support constructor arguments (except arrays)
So ultimately our best option here is to use CEW with contracts that have an empty constructor (or ones that do not contain arrays). This gives us the most flexible deployment and key storage options. Another benefit to the empty constructor approach is that it makes it easy for others to reproduce the same exact bytecode (and assure themselves that the code deployed matches the code as written).
First get yourself some code
We’ll be using a multi-sig for this example, it’s both more useful and somewhat harder to deploy than a simple token contract. This makes it an excellent example for actually deploying a smart contract.
The code example we’ll be using is here. This code is based on OpenZeppelin’s multisig wallet: https://github.com/pyskell/multisig
Disclaimer: The example code provided here is for EXAMPLE only. If you deployed the code as it currently exists then you would create a multi-sig with several ETC community members as the approved signers. For obvious reasons you don’t want strangers in control of the funds in your multi-sig wallet. If you want to use this code for a real multi-sig then you should be able to find the few areas you need to modify, if you cannot then you should not be using a multi-sig.
Install Truffle
Truffle is easily the best tool currently available to test and compile contracts. Follow their instructions here and come back to this guide once you’re done.
Create your migration
If you’re familiar with migrations from other programming languages it’s pretty similar here. Basically you’re telling Truffle where all of your files are, what to compile, and what to do with them (if you’re deploying from Truffle, which we won’t actually be doing).
We’re skipping some steps here, namely that migrations are also used for testing and deploying to local/remote testnets. You’ll likely have multiple migrations in a project for different purposes. But for this demonstration we only need one: migrations/1_initial_migration.js
It should look like this, and tells truffle which files you want to compile.
var DayLimit = artifacts.require("./DayLimit.sol");
var MultisigWallet = artifacts.require("./MultisigWallet.sol");
var Multisig = artifacts.require("./Multisig.sol");
var Shareable = artifacts.require("./Shareable.sol");
var Migrations = artifacts.require("./Migrations.sol");
All of your contracts should be stored within a contracts/ folder:
To actually compile everything you’ll run truffle compile from your root project folder.
Truffle will then look through your contracts/ folder for files with these names you specified in your migration and create a .json file for each. These get stored in build/contracts/ and they’re where you’ll be looking for the bytecode you want to deploy.
Just FYI: Migrations (migrations/) are executed in file order from the file with the smallest number in front of it to the largest.
Deploy your contract
Alright! You’ve got your code compiled and you’re ready to deploy. For many languages/environments this is the easiest part, C# will make installers for you, Java bundles everything up into a single .jar, and most applications can be run with ./application. On ETC (and ETH) it’s a bit lower level, you’ll be taking the bytecode you just produced and then using https://ethereumproject.github.io/etherwallet/ to deploy it.
As mentioned earlier we’ve chosen CEW for two reasons:
1. We can sign with a hardware wallet, this is pretty much a must, especially for any contract that requires permissions/can be modified by your key pair, as is the case with multi-sigs.
2. We’ve removed the constructor from our contract so CEW supports it.
To deploy go to: https://ethereumproject.github.io/etherwallet/ and click on “Deploy Contract”
Now open the build/contracts/MultisigWallet.json file and find the bytecode key. You can also read this file with your favorite json parsing library if you prefer. Either way copy the value at the bytecode key into your clipboard and paste it into the “Byte Code” box on CEW.
You’re using this file in particular because it’s your main contract, it includes dependencies from all the other contracts. For different deployments there will be different requirements, either a different file, or even multiple contracts each deployed to their own address. It’s best to refer to the documentation of the contract you’re deploying if they have a complex deployment procedure.
Once you paste the bytecode into CEW click on "Estimate gasLimit, this will give you a good estimate of the total cost to deploy the contract. In the case of this contract it’s about 1.8 million gas. This amount should be fine, if it fails you can always send the bytecode again in a new contract with a higher Gas Limit.
Make sure to set your Gas Price (at the top right of CEW’s screen) fairly low for hefty contracts like these so you don’t end up paying too much. Again, you can always retry the transaction with a higher Gas Price.
While you’re up there make sure you have the correct network (ETC) selected 
Lastly sign and approve the transaction with your method of choice. Although if you are signing a multisig you’ll almost certainly want a hardware wallet.
Success!
If you’ve followed all of the instructions above your contract is now deployed at a new address. Fun fact, this address is based on your public address + nonce. It’s actually possible to predict deployment addresses into the future. You can even send funds to an unused contract address and deploy a contract to get them back later.
But I digress, hope you learned something, also I have no editor so if you encounter any issues or have any changes please suggest them!