RIDE has made many smart contract advancements. We have reviewed 100s of moon, elon, doge, and nft smart contracts. We found errors, weaknesses, and vulnerabilities. Next we reviewed audits and technical analysis’ to further identify what needs to be fixed and improved. After all that our Devs got to work and wrote the RIDE advanced smart contract.
One of the major changes we have made is how the burn feature works. Most smart contracts that have reflections for their holders allow their burn address to get reflections also, calling this their burn. The problem we found with this is that the burn address is the largest holder of tokens thus it absorbs a large percentage of the reflections preventing it from being shared with the holders. In some smart contract the burn wallet absorbs approximately 2% of a 5% reflection, leaving only 3% to be divided up amongst the holders.
We went with a Clean Burn concept. It’s a true burn built into our transaction fee. Our transaction fee is a total of 10%, 5% reflections to holders, 3% Liquidity Pool, and 2% True Burn to the burn wallet.
The 3% that goes to our longevity pool does go to the longevity pool. It is not shared with any wallet. This was one of the critical fixes recommended from audits of other smart contracts. Also, we are maintaining control over the contract and it will not be renounced because we need to be able to update it if third party associates, such as Uniswap, change liquidity pool routers or anything else that can be unexpected. Some smart contract tokens out there made the mistake of cloning other contracts and then renounced ownership. That means they can not make any updates nor changes. Now they are stuck with the problem of not being able to update liquidity pool routers, which could be the end of their token.
Many smart contracts out there with tokenomics and transaction fees send a percentage of the fee to their liquidity pools allowing the liquidity pools to get reflections as well. We have blocked reflections from going to our liquidity pools. This stops the token from increasing in the liquidity pool while protecting the pairing of coin to token. We aim to strengthen our liquidity pool by doing this so it is substantially more balanced when wrapping the token to coin to protect the value.