We are finally getting closer to our token launch. There have been many obstacles we needed to overcome, and they were not at all technology related. A good launch is a coming together of marketing, partnerships, recognition, and security - then at the end, a small part is product-related. Of course, there’s no long-term success without an excellent product.
And there is no token without a token contract. We have published our token contract on our public github and you can review it here: https://github.com/3air-tech/3air-contracts/blob/main/contracts/3air.sol
Let me guide you a bit through the code. We have decided to use the ERC20 standard of the token. OpenZeppelin issues the open-source code for these and the code has been thoroughly audited and tested in thousands of live projects. This by itself allows for a safe and secure token at THE highest standard currently available.
So, we are using the standard ERC20 with extensions that allow us to burn the tokens, to use tokens for voting and vote delegation.
The constructor() function is automatically called only at contract deployment and mints a set supply of 1B 3AIR tokens. No more minting is possible at any other point in time of the smart contract lifecycle.
###Sniping bot prevention at launch
Additionally, we have integrated a securityProxy function that allows or prevents the interaction with the functions of the token contract based on some conditions. This is used for sniping bot prevention at launch, as we do not want a bot to buy up all the liquidity for the lowest price and then dump it on all of you.
In short, what this does is that when you want to interact (buy) the token, it checks some parameters that determine if you are a bot or not and then either allows you to buy or not. Unfortunately, publishing the bot detection algorithm is impossible as it would render it useless because someone could adapt the bot to bypass them.
Lastly, there’s also the function that disables the securityProxy that we call once the initial launch is successful and there is no more economic incentive for a bot to snipe the project. Once the securityProxy is disabled, there is no option to enable it again so that no manipulation of the token is possible from our side through the proxy.
The vesting contract is a bit different. At 3air, we want to give you the freedom to claim your vested tokens at any point in time. Unfortunately, there is currently no standard that allows this, so we had to write the whole smart contract from scratch. This means you can claim all your tokens at the end of the vesting period, or you can claim them every minute (or block) if you want.
We did use some security utilities provided by OpenZeppelin.
In essence there are 2 functions: the first one adds a new wallet and tokens into vesting and the second one allows you to claim your tokens.
This function takes the user wallet address, vesting type and the amount of tokens to be vested. There are 16 vesting types defined in the smart contract that you can see at the bottom. It determines how the token gets released with three numbers, the first is the cliff, the second is the vesting period and the third is the percentage of release immediately at TGE.
We will mint all tokens from the token contract directly into the vesting smart contract. From there, we will add them to the individual vesting terms. The vesting terms start counting at a predetermined time that we set once we enter your wallet into the vesting term. We will start adding your tokens into vesting once the launch date is 100% percent confirmed by third parties involved in the launch (launchpads, exchanges).
The rest of the tokens will remain in the vesting smart contract where we can add additional valets at a later stage. For instance, if we onboard another partner or advisor or influencer, we can vest their tokens from the date they have been onboarded. This is again a feature we came up with to create a fairer distribution of the tokens to every party involved.
The function that is most important for you is the claimTokens function. What this function does is that it checks your wallet against an array of all wallets that have tokens vested. Then it determines how many tokens are available for claiming as a difference of how many have been vested at that moment in time, minus how many have already been claimed. After that, the available tokens are transferred to your wallet.
Even having white-hat certified coders on our team, it is always good practice to have such important code audited. We will do anything in our power to prevent any hacks or exploits of our smart contracts and security is our top priority.
We would like to point out that these contracts are straightforward and should not present any security holes.
It is currently quite difficult to get quality contract audits. The major auditing companies have waiting times of up to 8 months for an audit and charge very high fees. Therefore, we have decided to go with CTD SEC, an auditing company who has a provable record of many code audits in the past. The audit report can be found on their git repository here: https://github.com/JorgeRodriguezsec/CTDsec/blob/main/Audits/Cybersecurity_Audit_CTDSEC_3air.pdf
As you can see from the report both smart contracts have been fully audited. If you want to have a summary you can just scroll to the end where it states: “Contract has no critical issues and it’s safe to be deployed.”, but if you want to know more, let’s dive into what has been found and explain it.
This is bound to how the actual underlying blockchain is structured and we have no influence on it. The blockchain itself has a max gas limit where a transaction will fail if it reaches that threshold. This can lead to a DoS attack similar to those that have made news in the past. Note that this does not mean anyone would be able to steal your funds, it just means that your transactions on the network will not go through. This is a security issue you face every day with every coin on the Ethereum and Ethereum compatible networks.
As the auditor states, this may incur slightly higher gas fees while we add a new address to vesting, but in turn you are having a lower gas fee while claiming the token. We have tested this and decided to go for a solution that gives lower gas fees for the end user.
There is the security proxy that we have described in the previous section that prevents sniping bots at token launch. We hold the authority over enabling it at start and disabling it once we deem it’s not needed anymore. Once we turn it off, we can’t turn it on anymore. It is in our own interest to disable this proxy at the earliest possible point in time as it will allow for a better price action of the token.
In the vesting contract we are the only authority to add new valets to vesting. We believe this is self-explanatory and you will agree that no one else should have the ability to access this function. Note that we can only vest the tokens that are inside the smart contract per se. So, once you claim your tokens nobody can vest them anymore.
While we do not believe this would make any difference, we do see it as a good practice and have implemented the change as per the auditors recommendation.
With this, I think we have all the technicalities sorted out for a good launch. Now we need you to help us spread the word and make the token launch successful. Follow us, share us and like us on all your social media channels and look out for our giveaways and airdrops.
Sandi Bitenc, CEO
###Follow us on social media