This repository is for updating & explaining the features of my Contract Standard for ERC-20 Tokens. The contract is designed to optimize the performance of long-term Ethereum token projects on Mainnet or a Layer-2. It removes all concern from token holders of nefarious behavior as there are no functions even available that could be misused by the project. The ultimate goal is to encourage transaction volume at launch and subsequent accumulation of tokens into the hands of long-term supporters of the project, fostering a strong community.
I believe in the Web3 Ethos of "Don't Trust, Verify" and have been in the industry for over a decade and will remain for decades to come. As such, creating long-term relationships with project founders and their teams is of utmost importance to me. I value transparency & creating a Win-Win Situation for all parties, especially token holders. If I am the developer of a project, you can expect the following commitment from me and the team.
When deploying smart contracts, I use this workflow with the following services:
With every token project I have launched over the past 3 years, I test a hypothesis with the team to improve the launch & long-term success of the project. Like a scientific study, I keep all the other variables in the contract & launch strategy the same and simply isolate this hypothesis for improvement. This approach allows me to confidently learn and iterate on the best practices I have developed for project teams. View my old contract. With these learnings, I have settled on the following read & write functions for the current contract standard:
My contract standard contains the following features:
Through many experiments with tokenomics, I have found that optimal performance for long-term token projects is achieved through a 3/16 lopsided tax structure. It is important to have the option to reduce the lopsided sell tax for a stable 3/3 tax token and another option to remove taxes altogether.
To ensure community confidence & clearly communicate tax policy, the buy & sell taxes are not openly adjustable. I used to cap what they could be modified to, but find it is better to hard code just a couple options into the smart contract. The following tax functions are available to projects using this contract standard:
Long-term projects work best when there is clear budgeting within the token tax structure between 3 wallets and those wallets are clearly identified. I also believe it is best for projects to have different individuals with control of these wallets and it is communicated on the project's website. This contract standard contains the following:
For project longevity, these wallets are updateable in the contract. This allows teams to use a marketing manager for launch and a different marketing manager for ongoing efforts or just for natural turnover in positions over time. You have the new team member in that role create a fresh wallet only they have control over then we update the smart contract to divert the appropriate tax revenue to that wallet. There are 3 functions to update these wallets:
There are 2 functions for withdrawing tokens in the contract:
The following function enables trading of tokens:
There are 2 anti-whale restrictions in this contract standard. The first is a max transaction that I have found is best to be 2% or less of the total supply. The second is a max wallet which I have found is best to be 5% of the total supply, allowing multiple buys. These are necessary for heavily marketed launches and to prevent whales accumulating at launch, especially bots. 15-30 minutes after launch, this should be removed with the following function:
There are 2 functions for ownership in the Contract Standard:
Here is a list of things I have seen in smart contracts for ERC-20 tokens that I believe are not in the best long-term interest of the project's community and will not include in this contract standard. This contract standard does NOT contain the following: