Nodle Network security record

The report gives no description here.

The emergencyWithdraw() function forcefully withdraws all tokens from the contract and sets totalStakedInPool = 0. Users attempting to claim rewards or unstake after emergencyWithdraw() will encounter issues since totalStakedInPool is already 0 and reverts the transaction. In addition, if owner adds the funds again, the value will remain 0, blocking the smart contract of future transactions.

The InsufficientRewardBalance check only verifies if there are enough tokens at the moment the function is called. It does not account for the possibility that other users might claim rewards or unstake concurrently, depleting the balance before transactions are processed.this can be replicated in this scenario:user1 and user2 put 10 tokens each one.Rewards are 20%, so each one will receive 12 tokens.Staking contract has 1 reward token. Pool now contains a total of 21 tokens.user1 claims and obtain 12 tokens. Pool now contains a total of 9 tokens.user2 claims or unstakes but their transaction gets reverted because there is not enough tokens in the smart contract.

During the security assessment of the oracle binary, it was observed that sensitive information, specifically private keys, are required to be passed as command-line arguments when executing the binary. This practice exposes private keys in the process's command line, which can be accessed by any user on the same system with permissions to view the process list, as well as potentially being exposed in logging or in other monitoring tools accessible on the Google Cloud platform. This represents a significant security risk as command-line arguments are not a secure medium for transmitting sensitive information due to their high visibility.

The off-chain component of the bridge runs periodically and processes some number of blocks. The off-chain components are sending transactions to the target network as they are processing the blocks. It was observed that there is no explicit check assuring that the block being processed is finalized. As a consequence, in a scenario when an unfinalized block is reverted, however it was already processed by the off-chain component, a double-spending opportunity arises. User whose interaction with the evm_bridge contract was reverted can do it again in new block which would result in a second valid bridging operation from the off-chain component's perspective.

The claim() and the unstake() functions take an index as input, but there's no check to ensure the index is within the bounds of the stakes[msg.sender] array before accessing the array.

The function unstake() allows users to desist from their stake, getting their funds back to their accounts. In technical terms, with this action, funds are never claimed but are instead unstaked. As such, the claimed variable of the user's stake should be left as false, to correctly show users of the platform of the action that was taken, e.g. when calling the function getStakeInfo() with the index of the specific stake.

The reward calculation suffers from potential precision loss due to integer division. Small stakes or low reward rates could result in users receiving less reward than expected.

The fundRewards() function is intended to be used only by REWARDS_MANAGER_ROLE but it is possible for any user to transfer NODL tokens to the contract and increase the rewards.

The getStakeInfo() function is declared as view, which means it should not modify the contract's state. Using a storage pointer would imply a potential modification of the state, which is not allowed in a view function. Storage variables also consume more gas.