EXECUTIVE SUMMARY
Profit Paradise is a yield farming decentralized application (dApp) designed to provide simple rewards to users. The core incentive is a daily return of 3% on deposits, plus an additional 0.5% return each week, until a new cycle begins. When a new cycle starts, all previous deposits and state are reset to zero, creating a fresh start, and increases the base daily return by 1%. However, the total value locked in the protocol remains from the past cycle, which can help fund new participants.
This mechanics create a cyclical system reliant on continued community participation and attracting new investments over time. As revenue depends on new entrants depositing funds each cycle, there is an inherent gambling dynamic with specific game theory at play. Profit Paradise is tied to the profit paradox concept, whereby sustainability requires a critical mass of users rolling over funds across cycles.
We did not identify any vulnerability in this smart contract.
SCOPE
FUNDAMENTALS
Contest System:
Deposit Rules:
Reset Cycles:
Claim Rewards:
Redeeming Deposit:
Allocation Breakdown:
FINDINGS
| TITLE | SEVERITY |
|---|---|
| [CPFL-1] denial-of-service on cycle reset | LOW |
CPFL-1: In Profit Paradise, user deposits are stored in an array that gets reset when a new cycle begins by looping through and resetting all deposits. This creates a potential denial-of-service (DOS) vulnerability where an attacker could overflow the deposit array to reach the gas limit of a BNB Smart Chain block, freezing the contract. However, this is considered a low severity risk because the minimum deposit amount is 10 USDT. An attack would need to deposit an expansive amount of funds to reach the gas limit, making it economically infeasible. While the contract logic introduces a theoretical DOS vector, the economic costs of an attack provide mitigation, thus the risk is viewed as low severity given the deposit size requirements.
UNIT TESTS
| INTERACTION | RESULT |
|---|---|
| deposit | OK |
| redeem initial | OK |
| claim rewards | OK |
| claim prize | OK |
| claim profit share | OK |
| common vulnerabilities | OK |
Unit testing was conducted to verify the proper execution of the smart contract and its functions. The tests simulated usage scenarios and interactions with the contract by comparing the expected theoretical output to the actual returns from executing the code.
The smart contract was evaluated for common vulnerabilities like flash loan attacks and reentrancy. Testing methodology included verifying proper access controls in the deposit function, which restricts deposits only from user EOA wallets by checking msg.sender == tx.origin. This test validates that smart contracts cannot call the deposit function, mitigating potential flashloan risks. Overall, the tests conducted were straightforward given the access restrictions coded into core functions like deposit. By validating expected behavior for common attack vectors, the test methodology provides assurance that the smart contract is hardened against typical vulnerabilities that plague DeFi protocols.
PRIVILEGES
The smart contract's access control only allows the contract owner to set whitelisted accounts. This was configured upon deployment on August 1, 2023, and cannot be changed afterwards.
RECOMMENDATIONS
There is potential for gas optimization in the smart contract code by removing unused variables that appear to be leftovers from a forked codebase. The presence of these unused declarations creates waste in the compiled bytecode, resulting in higher gas costs for contract interactions.