I am a Community Manager not a Security Researcher. I have only had a very quick look at your token contract.
I suggest going through:
If you are planning an audit, it is a good idea to prepare early and start the process of organizing it. You can request an audit from OpenZeppelin: https://openzeppelin.com/request/
I would suggest targeting high code coverage with your unit tests.
Also review every line of code (even print it out) with everyone in the team. (even if the team is just you).
If you have commented out code, this should be addressed, either removed or be uncommented.
I am not familiar with Compound’s Comp ERC20 smart contract code. I would suggest reading through audits of this contract and checking for anything that you should address.
If other projects have forked this code, you may also want to look at the audits from those projects too.
You should have
SPDX-License-Identifier on every contract with the appropriate license.
If you have merged smart contract code (under the appropriate license), you could add comments in the smart contract with the GitHub commit to the original and what license it is being used under, along with what modifications you have made. You want to make it easier for your community and any auditors to see what is going on.
When I first saw your mint function, I didn’t see any Access Control. You may want to consider the clarity of extending from the Preset ERC20 when you are adding to it, it may (or may not) be clearer to extend ERC20.
Finally, I would suggest looking at OpenZeppelin Defender as you have admin functionality: https://openzeppelin.com/defender/ and using a multi-sig to control your admin functions, see: https://docs.openzeppelin.com/learn/preparing-for-mainnet#admin-accounts