Parity Finance Liquid Staking & Early Purchase security record

The `liquid_staking::restake_expired_withdrawal::handler()` function restakes the expired withdrawals by minting LST tokens back to the stakers. However, it does not transfer the relevant user's base tokens (funded by the depositor) from the `window_base_token_account` to the `pair_base_token_account`. Therefore, these base tokens will remain locked in the `window_base_token_account`, preventing the closing of the `withdrawal_window` in the `liquid_staking::close_withdrawal_window::handler()` function.

During the token purchase phase in the `early-purchase` program, buyers transfer their payments (either SPL tokens to the `sale_payment_ata` or SOL directly to the Sale PDA). The sale organizer (acting through a Guardian) deposits the `sale.purchase_mint` tokens for distribution after the sale ends. However, the program lacks a mechanism to transfer the collected buyer payments from the `Sale` PDA and ATA accounts to the sale organizer or a designated treasury. It is also noted that the address of the user initiating the sale is not saved in the `Sale` PDA, and only guardians with `deposit_tokens` permission can deposit the `sale.purchase_mint` tokens.

The  `early_purchase::deposit_tokens::handler()` function is intended to enable a Guardian to deposit a specified quantity of `purchase_mint` tokens (`params.amount_to_deposit`) into the sale token vault  `sale_purchase_ata`. However, the `token::transfer` CPI within this instruction incorrectly uses `sale.calculate_base_purchase_cost(amount_to_deposit)` as the amount argument for the transfer instead of the `amount_to_deposit`, resulting in a significantly different value: ```rust token::transfer( CpiContext::new( purchase_program.to_account_info(), token::Transfer { from: authority_purchase_ata.to_account_info(), to: sale_purchase_ata.to_account_info(), authority: authority.to_account_info(), }, ), sale.calculate_base_purchase_cost(amount_to_deposit), ) ```

The `early_purchase::redeem_receipt::handler()` function is responsible for transferring the `purchase_mint` tokens from the sale's ATA (`config_purchase_ata`) to the buyer's ATA (`buyer_purchase_ata`) during sale receipt redemption. However, the `token::transfer` CPI is incorrectly configured with the `buyer` as the authority for this transfer: ```rust token::transfer( CpiContext::new( purchase_program.to_account_info(), token::Transfer { from: config_purchase_ata.to_account_info(), to: buyer_purchase_ata.to_account_info(), authority: buyer.to_account_info(), }, ), num_tokens_pending, ) ```

The Early Purchase program appears to be completly missing a test suite. Contracts that are not extensively tested are at high risk of serious bugs that can impact the protocol's proper functioning and security. While audits can help developers to find bugs, they are not a substitute for thorough unit and integration testing.

Sale accounts can be created by any user and they are assigned as their admins. Additionally, receipt PDAs are derived with the following seeds at the buyer's first token purchase: ``` seeds = [ Receipt::PREFIX.as_bytes(), &buyer.key.to_bytes() ] ``` This implies that `Receipt` accounts are initialized in a 1:1 relation to buyer accounts, allowing an attacker to create a receipt and purchase an amount of a worthless token and redeem the receipt against a sale that holds actual, legitimate tokens.

The `early_purchase::end_sale::handler()`function is used by a guardian to end a specific sale. However, the this function does not check that the referenced sale end time has passed (`sale.is_end_time_reached()`), allowing guardians to end any sale even before it has officially ended.

The instructions that initialize PDAs in the `early-purchase` program use the `space` parameter (`#[account(init, payer = ..., space = ...)]`) to specify the space needed for account creation. The `space` attribute expects the total space required for the account's data, including an 8-byte discriminator. However, the 8-byte discriminator is not accounted for in the size calculation. If insufficient space is allocated, it could lead to runtime errors during account initialization or data serialization issues later if data attempts to write past the allocated boundary.

When users purchase tokens in the `early-purchase` program using SOL, the current SOL price is determined dynamically at the time of transaction execution using a Pyth Network oracle price feed. However, the current token purchase implementation does not allow users to specify a maximum amount of SOL they are willing to pay for their desired quantity of purchase tokens, only the number of tokens to buy. While the `sale.max_price_feed_age` check ensures the oracle price is not excessively stale, it does not protect against legitimate, recent price volatility that occurs before transaction confirmation. The `sale.purchase_mint` token price (`sale.payment_amount`) may also change without the buyer's knowledge.

The `early_purchase::update_sale::handler()` function permits `Guardians` with `update_sale` permissions to modify critical parameters such as `sale.purchase_mint`, `sale.payment_mint`, `sale.guard_purchases` and so on, even if the `sale.is_start_time_reached()`is `true`. Buyers typically make purchase decisions based on the observed state of the sale. If these parameters can be altered while the sale is active or just moments before a buyer's transaction is processed, a buyer might inadvertently pay a different price (potentially higher) or face different purchasing conditions than they initially expected. The `purchase_tokens` instruction calculates the cost dynamically at the time of execution based on the current `Sale` state. This could lead to user frustration, loss of trust, and scenarios where buyers feel deceived if, for instance, the token price effectively increases due to a mid-sale update.