NATIX Network security record

Solana maintains limitations on both account size and compute units: - Account size: 10 MB, [reference](https://github.com/solana-labs/solana/blob/27eff8408b7223bb3c4ab70523f8a8dca3ca6645/sdk/program/src/system_instruction.rs#L85) - Compute unit: 1_400_000(200_000), [reference](https://github.com/anza-xyz/agave/blob/b7bbe36918f23d98e2e73502e3c4cba78d395ba9/program-runtime/src/compute_budget_processor.rs#L19) The concern is that the current implementation uses a vector to hold all stake information. Although the number of stakes is constrained with `maximum_stakers`, however, it limits the unique user, which means it allows one staker/user to create numbers of stakes which could potentially abuse the account size. At the same time, the program frequently go through the whole stake list, which raise the concern when too many stake info exists.

Based on current implementation, we have raised following concerns: **1. Potential for Excess Reward if No Rate Exists Before Stake Time** The current implementation may overestimate rewards when there's no interest rate defined before or at the stake time. - If no rate is defined before the stake time, `get_interest_rate` only returns rates starting from or after the stake time. - In `get_reward`, the first rate in this list is used as the initial rate. - If this first rate is actually from a time after the stake time, it will be incorrectly applied to the entire period from stake time to this rate's time. - This effectively gives the user a higher interest rate for a period when no rate was actually defined. Example: - Stake time: Day 0 - First defined rate: 5% starting from Day 10 - Unstake time: Day 30 In this case, the 5% rate would be applied for the entire 30-day period, including the first 10 days when no rate was actually defined, resulting in an overpayment of rewards. **2. Potential for Reward Loss Due to Compound Period** The compound period can lead to underpayment of rewards due to rounding and missed rate changes. - Different compound periods can result in different total rewards for the same staking duration and rates. - Longer compound periods may cause more significant rounding losses: - Interest is only calculated at the end of each full compound period. - Any partial periods are essentially ignored, leading to lost interest. **3. Potential Precision Loss Due to Type Cast** The reward calculation also includes type conversion between `u64` and `f64`. The conversion could lead to precision loss in certain scenarios especially when the value of u64 (i.e., `unstaker.amount`) exceeds the range of `f64`. For example, in the following case, the value converted back to u64 increasing due to precision loss. ```rust fn main() { let u64value: u64 = 123_456_789_123_456_780; let f64value: f64 = u64value as f64; let u64back: u64 = f64value as u64; println!("u64value: {:?}", u64value); println!("f64value: {:?}", f64value); println!("u64back: {:?}", u64back); println!("delta: {:?}", u64back - u64value); } ``` Output ```bash u64value: 123456789123456780 f64value: 1.2345678912345678e17 u64back: 123456789123456784 Panic with overflow ``` As a result, an underflow may occur. While the impact is limited to the actual staking amount, which is related to the staking limitation, it's recommended to use the `checked_*` method to handle extreme cases and limit it to 0 while overflow happens.

The `burn_or_transfer` function in `src/burn_or_transfer.rs` checks the `pool.config.forfeit_allow_burn` and `pool.config.forfeit_allow_transfer` flags to determine whether to burn or transfer the forfeited tokens. However, there is no validation during the `set_config` operation to ensure that only one of these flags can be set to true at a time. As a result, 1. If both `pool.config.forfeit_allow_burn` and `pool.config.forfeit_allow_transfer` are true, the code will prioritize burning the forfeited tokens over transferring them. 2. If both `pool.config.forfeit_allow_burn` and `pool.config.forfeit_allow_transfer` are true, the forfeited tokens will be locked.

The current implementation of the unstake cancellation feature in `src/cancel.rs` does not update the `stake_time` when an unstake request is canceled. This oversight allows users to exploit the system by canceling their unstake request and claiming the full reward, even after initiating the unstake process and remaining in the unstake status. ```rust=38 for staker in stakes { staker.unstake_time = 0; staker.instant = false; } ``` For example: 1. Alice stakes 1000 tokens at time T0 by calling the `stake` function. 2. At time T1, Alice initiates an unstake request by calling the `unstake` function, signaling her intention to withdraw her staked tokens and rewards. The staking program records Alice's `unstake_time` as T1. 3. At time T2, Alice cancels the unstake request using the `cancel` function. 4. Because `stake_time` is not updated, Alice's stake is still treated as if it began at T0. As a result, she receives rewards for the period between T1 and T2, while retaining flexibility during this time.

In the `stake_V1` program, there is no specific logic or mechanism to track/deposit reward tokens. Insufficient rewards, potentially causing withdrawal blocks and losses in staking deposits.