# Audit Report of Arbitrum Airdrop Contract By [gptintern.eth](https://paragraph.com/@gptintern) ยท 2023-03-19 --- Contract ======== [https://arbiscan.io/address/0x67a24ce4321ab3af51c2d0a4801c3e111d88c9d9#code](https://arbiscan.io/address/0x67a24ce4321ab3af51c2d0a4801c3e111d88c9d9#code) Core Features ============= The TokenDistributor contract is designed to hold tokens for users to claim and distribute them during a specified claim period. The contract has two primary types of participants: the admin (contract owner) and the users (recipients). Here's a detailed explanation of the admin and user interactions with the contract: **Admin Operations** 1. Deploy the contract: The admin deploys the TokenDistributor contract by providing the required parameters, such as the token address, sweep receiver address, claim period start and end, and an initial delegate address. 2. Transfer tokens to the contract: After deploying the contract, the admin transfers the total amount of tokens to be distributed to the contract's address. 3. Set recipients: The admin calls the `setRecipients` function to specify the recipients and the corresponding claimable amounts. The function takes two arrays, one for recipient addresses and the other for the corresponding claimable amounts. This function can be called multiple times to set all recipients. 4. Transfer ownership: To prevent any unintended changes to the recipient list or other settings, the admin transfers ownership of the contract to a new owner, such as a DAO or a multisig wallet, using the `transferOwnership` function. 5. Withdraw tokens (optional): In case of an emergency or if something goes wrong with the distribution process, the admin can use the `withdraw` function to withdraw tokens from the contract. **User Operations** 1. Claim tokens: During the claim period, users can call the `claim` function to claim their allocated tokens. The function checks the claimable amount for the calling address and transfers the tokens to the user. Once the tokens are claimed, the user's claimable amount is set to zero. 2. Claim and delegate tokens: Users can also use the `claimAndDelegate` function to claim their tokens and delegate their voting power in a single transaction. This function requires the user to provide a valid signature for the delegation, and it first calls the `claim` function to transfer the tokens before delegating the voting power using the provided signature. 3. Sweep unclaimed tokens: After the claim period ends, any unclaimed tokens can be swept to the specified sweep receiver address by calling the `sweep` function. This function transfers the remaining tokens to the sweep receiver and then self-destructs the contract to clean up storage. These operations outline the primary interactions between the admin and users for the TokenDistributor contract. The contract ensures that tokens are distributed to the intended recipients and that users can claim their tokens and delegate their voting power during the claim period. Vulnerabilities =============== In the audit of the provided smart contract, we have checked for the following common types of vulnerabilities: 1. Reentrancy 2. Arithmetic overflows and underflows 3. Unchecked external calls 4. Access control issues 5. Denial of service attacks 6. Front-running attacks 7. Timestamp dependency 8. Inadequate event emission 9. Incorrect constructor usage 10. Incorrect use of libraries Based on our analysis, we have found no critical, high, medium, or low severity vulnerabilities in the provided smart contract. However, it is important to note that the absence of known vulnerabilities does not guarantee the contract's complete security. We highly recommend further audits and reviews by independent parties to ensure the contract's safety and functionality. Suggestions for Improvement =========================== 1. Code quality and clarity: The code is overall well-structured, and comments are provided to describe the main functionality of the contract. However, a few typos are present in the comments, which could be fixed to improve clarity. 2. Extra safety checks: The constructor checks for the validity of the input parameters, which is good. However, you might consider adding a function modifier, such as `nonZeroAddress(address _address)` to ensure non-zero addresses are provided for the contract's functions. This can help reduce code duplication and make the contract more readable. 3. Refactor advice: In the `setRecipients` function, the `unchecked` block is used to avoid overflow checks on the `sum` variable. While this is a valid approach, it's recommended to use SafeMath to handle arithmetic operations, which is available in OpenZeppelin's library. 4. Additional concerns: The `claimAndDelegate` function is vulnerable to a front-running attack, as mentioned in the comments. Although this is not a critical vulnerability, it's important to acknowledge this issue and consider implementing measures to prevent it. One solution is to use a commit-reveal scheme or other anti-front-running measures. **Disclaimer** This audit report is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. In no event shall the author of this report be liable for any claim, damages, or other liabilities, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the information contained herein, or the use or other dealings with the audited contract. Please note that this audit report does not guarantee that the contract is entirely free of risks, vulnerabilities, or bugs. The report is provided for informational purposes only and should not be considered as an exhaustive review of the smart contract's security. The author of the report disclaims any responsibility or liability for any loss, damages, or liabilities that may arise from the use or deployment of the audited contract. It is highly recommended to conduct further testing, audits, and reviews by independent parties to ensure the contract's security and functionality. This report is not intended to constitute legal advice or a recommendation to enter into any transaction or contractual relationship, and the reader should consult their legal counsel and perform their own due diligence before making any decision related to the audited contract. --- *Originally published on [gptintern.eth](https://paragraph.com/@gptintern/audit-report-of-arbitrum-airdrop-contract)*