Oikos Cash security record

The withdraw() transfers the availableBalance for the token, instead it should be the amount calcu lated according to the number of pNoma tokens the user had. In withdraw() first it gets the balance of the user, then burns the p-assets. Then calculates the minAmountOut value. Finally it transfers the availableBalance instead of minAmountOut resulting in transfer of more than intended tokens.

The deposit() function in the presale contract allows users to pass an arbitrary referralCode. However, this referralCode is later interpreted as the address to receive referral rewards in payReferrals()<br>- A user can generate their own referral code from their own address (e.g., bytes32(uint256(uint160(msg.sender)))) and pass it to the deposit() function.<br>- As a result, they receive a percentage of their own deposit back via the referral mechanism.<br>- This effectively gives them a discount on token purchases at the cost of the protocol.<br>Additionally:<br>- msg.value == 0 is allowed, which could result in unintended free mints or bloated contributor lists

In Presale contract, slippage check is calculated in the finalize() function to ensure the stability of the price. But the issue is that the comment has mentioned slippage to be 0.1% and the actual slippage calculated in contract is 0.5% which is higher and is mismatched from the sentence.

<br>1. No Emergency Mode Toggle:<br> The emergencyWithdrawal() function does not depend on any emergency toggle/switch, meaning it’s passively time-gated (deadline + 30 days), rather than actively controlled by the protocol or owner.<br> This limits response flexibility in critical failures (e.g., token price manipulation, stuck funds, or an attack on the protocol).<br><br>2. Improper Error Message:<br> The revert message in emergencyWithdrawal() uses PresaleOngoing() when finalized is true, which is semantically incorrect. If the presale is finalized, emergency withdrawal shouldn’t be allowed at all, or a different error like PresaleFinalized() should be used.<br><br>3. State Inconsistency in Emergency Withdrawal:<br> While a user’s individual contributions[msg.sender] is zeroed, the global totalRaised variable is not decremented.<br> <br>This leads to inflated accounting, which can break invariant assumptions during finalization or analytics.<br><br>4. Commented-Out Contribution Limits:<br> In deposit(), the MIN_CONTRIBUTION and MAX_CONTRIBUTION checks are commented out

The deposit function in the Presale contract performs an incorrect validation check that could allow contributions to exceed the intended hardcap limit. The check is performed before the new contribu tion is added to the total, and it only reverts if the current balance is already greater than the hardcap.