TraderDAOai Contracts Security Audit Report

1. Contract Ambassador_Redeem_Contract contract inherits basic access control properties from Openzeppelin’s Ownable contract, where the contract’s ownership can be transferred or renounced. Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
2. Function SetPause() allows the owner to pause or resume the contracts functionalities available to the users. Users would be unable to redeem USDT tokes for the signature signed by the signerAddress if the contract is paused.
3. Function SetSigner() allows the owner to update the signerAddress. All previous un-redeemed signatures will be invalid if the signerAddress is updated. New signatures must be generated for previous unclaimed signatures.
4. Function Save() allows the owner to withdraw ERC-20 tokens from the contract.

The functions SetDecimal() and SetRate() allow the gov address to modify POT<>USDT conversion parameters. With current values of Rate = 100 and Decimals = 10**18, the 1 POT = 0.0001 USDT

Users should know that the gov address can set any conversion rate without restriction.

• https://github.com/TraderDAOai/contracts/blob/9d4f1b1993ed76de25d7f3555a8b4eebdb8ad768/Liquidity_Wallet.sol#L56-L62.

1. Contract Liquidity_Wallet contract inherits basic access control properties from Openzeppelin’s Ownable contract, where the contract’s ownership can be transferred or renounced. Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
2. Function SetPause() allows the owner to pause or resume the contracts functionalities available to the users. Users cannot trade POT tokens for USDT tokens if the contract is paused.
3. Function SetGov() allows the owner to update the gov address.
4. Function Save() allows the owner to withdraw ERC-20 tokens from the contract.
5. Function SetFee() allow the gov address to set a fee for the user’s claim amount.

1. Contract POT_Token contract inherits basic access control properties from Openzeppelin’s Ownable contract, where the contract’s ownership can be transferred or renounced. Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
2. Function ownerMint allows the owner to mint arbitrary tokens.
3. Function SetSigner() allows the owner to update the signerAddress. All previous un-redeemed signatures will be invalid if the signerAddress is updated. New signatures must be generated for previous unclaimed signatures.

Based on the docs, the Proof_of_Trade_Arbi_One contract should rewards users in POT tokens, but the contract’s implementation rewards users in USDT tokens.

• https://github.com/TraderDAOai/contracts/blob/9d4f1b1993ed76de25d7f3555a8b4eebdb8ad768/Proof_Of_Trade_Arbi_One.sol#L68.

Consider reviewing the implementation or updating documentation based on the business requirements.

1. The function SetSigner() allows the owner to update the signerAddress. All previous un-redeemed signatures will be invalid if the signerAddress is updated. New signatures must be generated for previous unclaimed signatures.
2. Function SetPause() allows the owner to pause or resume the contract’s functionalities available to the users. Users cannot deposit USDT tokens or claim rewards if the contract is paused.
3. Function Save() allows the owner to withdraw ERC-20 tokens from the contract.

The function deposit() can be called by any user with any parameters. It allows an attacker to deposit with id_ that already exists.

• https://github.com/TraderDAOai/contracts/blob/9d4f1b1993ed76de25d7f3555a8b4eebdb8ad768/Proof_Of_Trade_Arbi_One.sol#L58.

1. Missing docstrings

The contracts in the code base lack documentation. This hinders reviewers’ understanding of the code’s intention, which is fundamental to correctly assess not only security but also correctness. Additionally, docstrings improve readability and ease maintenance. They should explicitly explain the purpose or intention of the functions, the scenarios under which they can fail, the roles allowed to call them, the values returned, and the events emitted.

Consider thoroughly documenting all functions (and their parameters) that are part of the contracts’ public API. Functions implementing sensitive functionality, even if not public, should also be documented. Consider following the Ethereum Natural Specification Format (NatSpec) when writing docstrings.

2. Missing test suite

The contract is missing a test suite to validate and verify the behavior of the contract functionalities. Add tests are recommended to ensure that the contract functions and behaves as expected.

3. Missing zero address checks

In several places in the code, addresses are passed as parameters to functions. In many of these instances, the functions do not validate that the passed address is not the address 0. While this does not currently pose a security risk, consider adding checks for the passed addresses being nonzero to prevent unexpected behavior where required, or documenting the fact that a zero address is indeed a valid parameter.

4. Insufficient event logging

Multiple functions with owner privileges in the contracts do not emit an event. Events are useful to inform external dapps or users that an important state was modified on the contract.