This repository is for the $InIOSE on Base smart contracts.

• Contract deployed & made publicly available 24+ hours ahead of Liquidity Pool launch
• Public livestream of liquidity pool launch with project hosting X Space
• Liquidity Pool locked for over 1 year
• Transparency with token community & prior announcement of all dev actions

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:

• Read Functions
• Write Functions

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:

• reduceSellTax() - This function reduces the 16% sell tax to 3%, matching the buy tax so the token has a 3/3 tax.
• removeTax() - This function removes the buy and sell tax so the token has a 0/0 tax.
• resetTax() - This function resets the token back to the 3/16 lopsided tax structure.

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:

• Community Wallet - Controlled by the project's CEO or community manager
• Marketing Wallet - Controlled by the project's CMO or marketing director
• Developer Wallet - Controlled by the project's CTO or lead developer

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:

• updateCommunityWallet()
• updateMarketingWallet()
• updateDeveloperWallet()

There are 2 functions for withdrawing tokens in the contract:

• withdrawStuckTokens() - This function withdraws the tokens in the contract
• withdrawStuckETH() - This function withdraws the Ethereum in the contract

The following function enables trading of tokens:

• enableTrading() - This function launches the Uniswap V2 Liquidity Pool with the tokens & ETH in the contract

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:

• removeRestrictions() - This function removes the max transaction and the max wallet

There are 2 functions for ownership in the Contract Standard:

• transferOwnership() - This function transfers the contract to another Ethereum address
• renounceOwnership() - This function sends the contract to the Dead Address

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:

• No Transfer Fee
• No Whitelist
• No Blacklist
• No Mint