Prime Numbers Labs security record

The approveWithdrawRequest() function sets a boolean flag _canWithdraw[user] = true, allowing a user to withdraw funds. However, this flag is not time-bound or tied to the stake amount at the time of approval. An attacker can exploit this by getting approval for a small stake and delaying their actual withdrawal. Later, they can stake a large amount and withdraw without requiring further approval, thus bypassing the intended per-withdrawal approval mechanism. This behavior breaks the intended protocol security model, where every withdrawal should be ap proved based on the user's current stake and context

In the PrimeStakedXDC contract, native XDC is sent to users during reward claims and withdrawals using Solidity’s .transfer function. This opcode only forwards 2300 gas, which is risky and outdated. This is dangerous for two reasons: - Gas costs of EVM instructions may change signifcantly during hard forks which may previously be assumed fxed gas costs. EIP 1884 as an example, broke several existing smart contracts due to a cost increase of the SLOAD instruction. - If the recipient is a contract or a multisig safe, with a “receive”/”fallback” function which requires >2300 gas, e.g. safes that execute extra logic in the “receive”/”fallback” function, the transfer function will always fail for them due to out of gas errors

The notifyRewardAmount() function can be called by any address with no access control or minimum reward threshold. This enables a griefing attack where an adversary sends trivial reward amounts (e.g., 1 wei) repeatedly to reset the lastUpdateTime and extend periodFinish by the full rewardsDuration. As a result, rewardPerToken() accrual is disrupted, and stakers experience significant delays or denial of expected rewards. This attack does not incur meaningful cost for the attacker but can indefinitely block proper reward distribution for all users.

The requestWithdraw() and cancelWithdrawRequest() functions emit events to signal a user’s intent- to withdraw or cancel a withdrawal. However, these functions do not update any internal state to refect the user’s current withdrawal status. The actual logic that allows a user to withdraw is fully controlled by the owner via approveWith drawRequest(), which sets canWithdraw[user] = true. As a result, there’s no on-chain tracking of whether a user has an active withdrawal request or has canceled it; only off-chain listeners can infer that by watching events.

The notifyRewardAmount() function allows the owner to deposit ETH (XDC) into the contract as rewards for stakers. While it emits a RewardAdded(reward) event, the function does not store the reward amount in state or update any cumulative reward tracking variable.<br>This means there’s no on-chain record of how much total reward has been added over time. The only way to trace this is through off-chain event logs, which can be incomplete or unreliable if logs are pruned, missed, or not indexed properly