Creating your own ERC20 Token

Things to consider when creating your own token

So you’re thinking about creating your own ERC20 / BEP20 token but you don’t know where to start. While there’s information on how to create a contract, there’s not much advice on what approach to take. So we decided to write a guide to walk you through different options.

Disclaimer. If you’re thinking about running a scam, please don’t be a tool. Scam = bad.

Use a launchpad if possible

If your needs are straightforward, it’s best to use a launchpad that automatically creates and deploys the contract for you. You’ll receive a well-tested contract that’s unlikely to contain any security flaws. This is absolutely the best option provided it meets your needs.

Other benefits — some launchpads can also help you conduct public presales, lock your liquidity tokens and vest your tokens.

Launchpads can help you create a token without any coding experience

PinkSales is a good option as it’s a fully featured launchpad, with more tokenomics options than other launchpads. You’ll be able to create:

Standard tokens
Liquidity / Tax Generating tokens (tax buys and sells to improve token liquidity and also raise marketing funds)
Rewards tokens (reward holders in another token, while also supporting taxes)
Buyback Rewards tokens (same as Rewards tokens, with the ability to manually buyback tokens)

The above covers the vast majority of tokenomics common in the ERC20/BEP20 space today. Note: I haven’t personally used PinkSales or any other launchpad. Also DYOR before connecting your wallet to any website.

That said, PinkSales, Unicrypt and DxSales are very popular options for creating tokens and liquidity and are very likely to be safe.

There are other options out there that do allow creating tokens with taxes and redistribution, however, I’ve not personally seen these being used, and at least one of them is accused of being a scam. Again, always use extreme caution in this space.

Enlist A Dev If Needed

If you have custom requirements and a launchpad doesn’t cover what you need, then it’s worth looking for a Solidity developer to help out.

Good Solidity developers are in very short supply at the moment, and they don’t come cheap (expect to pay at least a few BNB). When hiring a Solidity developer to create your token, always ask for references of prior work.

Good Solidity Developers are in high demand at the moment

Bad Solidity developers are more plentiful, but you get what you pay for. As with everything, if it looks too good to be true, it probably is.

Unless you’ve got some coding skills and trust yourself to vet your work, it pays to be very careful with who you approach. While creating smart contracts isn’t necessarily hard, the stakes are high and it’s you and your users who will pay if there’s a vulnerability in the contract.

Ask the developer to provide you with proof of the testing they’ve conducted (if they’re not using automated testing, it’s a big red flag).

Sometimes, less is more

No matter how good the developer is, there are risks involved when asking for complex and novel features. There’s a possibility that they make a mistake, leaving your contract vulnerable. Hackers are always on the lookout for flaws that they can exploit. There’s perhaps no better example of this than The DAO, a hack that ultimately led to the split of the original Ethereum blockchain into Ethereum and Ethereum Classic.

Ask yourself if you really need novel features, and discuss with your dev the complexity of implementing such features. It’s worth considering the benefits against the risk of a potential exploit (i.e. a bad actor draining all the funds from your token).

Creating a Token Yourself

Start from a known working token

While I’m sure it’s a fun exercise to code your own ERC20 token from scratch, I’d strongly recommend starting from a known working contract for any real-world deployment (particularly if you want to implement complex features like token taxes and redistribution).

Most tokens are MIT licensed, so feel free to browse your favourite block explorer and find a contract you like. You’re free to use our own Agent Shiba I.N.U. contract as inspiration, which itself was forked from Trynos’ Miyazuki Inu contract.

If you’re not a developer…

If you’re not a developer, you can always try and fork a known good contract. There are plenty of tutorials online on how to launch a contract with tools like Remix and Hardhat. It’s a lot of fun, and with the ability to launch first on a Testnet, you don’t need to risk real funds to get started.

Modifying a token for somebody who is not experienced is very risky. Unless you want to incur the wrath of your investors (and some of them can be very vicious), I strongly suggest you don’t do any modifications bar the most trivial — at least until you’ve built up some solid experience and skill.

If you are a developer, but new to Solidity…

There’s a lot of resources out there, and Solidity is not hard to pick up. There are a few gotchas you need to keep in mind, but as long as you do your research, you’ll be up and running in no time.

My preferred approach is to use Hardhat — a development environment that allows you to develop smart contracts locally. You’ll be able to run your own sandboxed EVM compatible blockchain right on your computer, allowing you to quickly develop and iterate on your token with no risks involved.

You can also fork Mainnet to test your token against your preferred router. For example, if you’re planning on deploying PancakeSwap, you can perform buys and sells against the actual PancakeSwap router, to verify that your token will function as is.

I strongly recommend you write comprehensive unit tests for your tokens if you are going down this path. Hardhat comes included with Mocha and Chai, making testing a breeze. The rigour of testing is up to you, but for our Agent Shiba I.N.U. token, we had almost 70 unit and “integration” tests for our token, covering everything from:

Testing all restricted functions to make sure they’re restricted to the owner address
Testing that our anti-whale functionality worked as expected (max TX, max wallet)
Testing that the presale allocation and LP instantiation worked correctly
Testing that the initial price of the token matched the presale price
Testing blacklisting functionality
Testing buys and sells