mouse-dev-1 / akutar Goto Github PK

curious what is the reasoning for not using a merkle tree for the airdrop and let the user claim the nft? seems less prone to errors even if the current code doesn't have bugs

Here if you make a human mistake when manually inputing the addresses arrays you would need to redeploy the contract.

Will keep trying to get familiar with the code tho and see if I can find any bugs.

There is no randomness in the airdrop tokens if the address[] in airdrop is controlled by the owner. There should be some hash verification to make sure that the address[] isn't shuffled by the owner after the shiftQuantity has been committed. There are any number of ways to implement the check.

Y'all need to make this contract upgradable. It could've potentially saved the day with the original contract. https://docs.openzeppelin.com/contracts/3.x/upgradeable

Hi, we are a security startup named Trustlook focusing on Blockchain and Mobile.

We did an audit on your contract, and here is the link:

https://smart-contract-audit-reports.s3.us-west-1.amazonaws.com/Smart%20Contract%20Audit%20Report%20for%20Akutar.pdf

Please let us know if you have any questions or need any further service. You can reach us at [email protected].

Thanks!

More an optimization suggestion rather than an issue:
Apparently using external over public can save some gas when working with arrays: https://ethereum.stackexchange.com/a/19391

 function airdrop(uint256 airdropGrouping, address[] memory addresses)
        public // use external
        onlyOwner
    {

Is there a scenario where we would call airdrop API multiple times for same airdropGrouping ?
If we do it, then currentId could be calculated to same value over multiple calls .
If that happens, minting would fail for some addresses.
We currently dont have any data structure that identifies if an address has already minted or not.