How to Create Your Own Tokens: Standard Token Factory (for Humans) Deployed

We’ve deployed a Standard Token Factory to the Ethereum mainnet.

To add it to Mist, go to the Contracts screen and add a new contract. Enter the address: 0xA7a677183373CA33a65f00084eB81747c8AE5F03 .

and add the following ABI:

[{“constant”:false,”inputs”:[{“name”:”_initialAmount”,”type”:”uint256"},{“name”:”_name”,”type”:”string”},{“name”:”_decimals”,”type”:”uint8"},{“name”:”_symbol”,”type”:”string”}],”name”:”createHumanStandardToken”,”outputs”:[{“name”:””,”type”:”address”}],”type”:”function”},{“constant”:true,”inputs”:[{“name”:””,”type”:”address”},{“name”:””,”type”:”uint256"}],”name”:”created”,”outputs”:[{“name”:””,”type”:”address”}],”type”:”function”},{“constant”:true,”inputs”:[],”name”:”humanStandardByteCode”,”outputs”:[{“name”:””,”type”:”bytes”}],”type”:”function”},{“constant”:true,”inputs”:[{“name”:””,”type”:”address”}],”name”:”isHumanToken”,”outputs”:[{“name”:””,”type”:”bool”}],”type”:”function”},{“constant”:false,”inputs”:[{“name”:”_tokenContract”,”type”:”address”}],”name”:”verifyHumanStandardToken”,”outputs”:[{“name”:””,”type”:”bool”}],”type”:”function”},{“inputs”:[],”type”:”constructor”}]

To deploy a token contract, use the function “Create Human Standard Token” and enter the variables required.

Once that’s done, you can retrieve the address of the token by checking the created array. Insert the address that called the factory. When you have that address, you can add it to Mist as a token contract by following the “watch token” prompts.

Deploying contracts through a factory is easier for the user and provides greater security and compliance with standards.

Easier to Use

In order to deploy a contract, a decentralized application (dApp) can do so for you or, currently, the more common interface would be something like Mist or Geth, where one needs to copy and paste the smart contract code in order to deploy it. A factory contains the source code for a specific contract. To deploy the contract, one simply invokes a function in the factory. Thus, it becomes simpler to deploy a contract.

Having an on-chain factory is also required in some circumstances. For example, when another dApp wants to deploy a token contract automatically without requiring a user to manually deploy and configure it.

Security and Standards

There are various concerns when interacting with Ethereum contracts. When someone gives you an address to interact with, how do you know that the smart contract that’s been deployed there does what it’s supposed to do? In other words, it could be malicious code that, for example, gobbles up your Ether. In order to mitigate this, one can either vet the code oneself (by checking that the open source code matches the compiled bytecode on the blockchain), trust the creator, or trust the community to vet it.

Another potential problem is malicious changes to browsers or other external applications. If one creates a contract oneself in the browser, or through an application like Mist, there is potential for an attack where the bytecode that is actually being deployed is changed to other bytecode. One could then interact with the contract, thinking it is what you wanted to deploy, all the while it could have inserted backdoors.

It could potentially not even be malicious. If the developer ships a new update to the site, they could unintentionally change the bytecode that’s being deployed. With a factory simply calling a contract, there’s less potential for errors.

Thirdly, using a factory, one can determine whether certain code that’s deployed at an address was created by the factory or conforms to some bytecode. This particular factory keeps track of deployed human standard token contracts, but it has an additional feature: an on-chain bytecode verifier. If one deploys the human standard token without the factory, another application or user can verify that it is a human standard token contract by simply passing the address of the contract to the factory. A dApp UI (like a browser) can provide a better UX if it can verify that a contract conforms to a specific standard. If a contract doesn’t comply, it’s not the end of the world, but it does mean that the user might have a worse UX as a result of it. For example, Mist expects that tokens have a name and symbol, so token contracts that do not conform to this may look unusual in the Mist UI.

Some of these attacks are edge cases and would be difficult to pull off. However, using a factory to deploy contracts has the benefits described above and provides a useful alternative to injecting the bytecode oneself.

Human Standard vs Machine Tokens

During the process of defining the token standard in Ethereum, effort was made to ensure that the standard conforms as much as possible to all use cases. A particularly important distinction is the one between tokens used by people and tokens that probably won’t see a UI in front of it. A human token system can be something like a currency or shares. A machine token could be something like a smart meter generating kilowatt hours and automatically creating sellable tokens for sending energy back into the grid. In the IOT space, these tokens might in the future be generated by the thousands and might only exist for short periods of time. However, having a standard API is still useful in order to create programmable tokenized infrastructure.

Since the more immediate use cases for tokens center around use by people, the Ethereum Foundation and Mist team have forged ahead with their own standard on what a human-readable token looks like.

We have thus moved along with these recommendations by adding 3 optional features to the default Standard Token:

1. Finite Initial Supply: When the contract is created the msg.sender (“creator”) receives an initial supply, which then cannot be inflated afterwards.
2. Human-readable variables: These are the number of decimals, symbols and names of the token contracts. Mist and other applications display these in their UIs.
3. An approveAndCall() function: This function is similar to approve(), but also has an additional hook built in that attempts to notify of an approval. For example, if you approve a decentralized exchange, the token contract can then immediately, in the same transaction, notify it, in case internal actions need to be done. If this does not exist, it might lead to the user having to do 2 transactions/actions instead of one. This is optional and the default approve() functionality still exists.

The Human Standard Token Factory is available at: 0xA7a677183373CA33a65f00084eB81747c8AE5F03.

The factory code can be found on Github. It deploys this token code.

The Token Factory

This contract release is in preparation for a production launch of what we’ve built, called The Token Factory. It’s a simple, usable interface where anyone can create their own tokens and also interact with a standard token. It will be launched alongside MetaMask. Here’s a peek from the current Alpha.

Disclaimer: This project is under the MIT license.

Our aim is for developers and researchers familiar with Ethereum and blockchain development to engage with this Human Standard Token Factory Contract. This is a test release of the software contract, not production release of the dApp itself, and so has not been through a security audit and may have bugs. If you see any bugs or flaws, please let us know.

This software and accompanying documentation is provided as if “AS IS” and without any warranties and support.

Consensus Systems, LLC (also known as ConsenSys) and the developers of the Token Factory assume no responsibility or liability for the use of the software, conveys no license or title under any patent, copyright, or mask work right to the product.

ConsenSys and the developers of the Token Factory reserve the right to make changes in the software without notification. ConsenSys Systems, LLC and the developers of the Token Factory also make no representation or warranty that such application will be suitable for the specified use without further testing or modification.

In no event shall ConsenSys be liable to any party for direct, indirect, special, incidental, or consequential damages, including lost profits, arising out of the use of this software and its documentation, even if ConsenSys has been advised of the possibility of such damage.