USDC Pool - Solayer

The usage of msg! is usually advisable during tests, and will incur in additional computational budget when the instruction is processed in Mainnet.

In both resolve_batch_deposit and resolve_batch_withdraw instructions, it was observed logging utilizing msg!.

- programs/usdc-pool-program/src/contexts/resolve_batch_deposit.rs

            msg!("expected_amount {:?}", expected_amount);
            msg!("rwa_token_amount {:?}", rwa_token_amount);
            msg!("susd_mint_amount {:?}", susd_mint_amount);

- programs/usdc-pool-program/src/contexts/resolve_batch_withdraw.rs

            msg!("expected_amount {:?}", expected_amount);
            msg!("usdc_withdraw_amount {:?}", usdc_withdraw_amount);

Consider removing msg! logging before mainnet deployment for enhanced computational budget efficiency.

ACKNOWLEDGED: The Solayer team has acknowledged the issue.

The existing implementation of the set_operator and set_rate_authority instructions employ an one-step procedure for authority delegation, which presents a security concern. This method lacks a safeguard against inadvertent delegations to undesired accounts.

- programs/usdc-pool-program/src/contexts/set_operator.rs

#[derive(Accounts)]
pub struct SetOperator<'info> {
    #[account(mut)]
    manager: Signer<'info>,
    #[account(
        mut,
        constraint = new_operator.key() != pool.operator.key()
    )]
    new_operator: Signer<'info>,
    #[account(
        mut,
        has_one = manager,
        seeds = [b"pool", USDC_MINT.as_ref(), pool.susd_mint.as_ref()],
        bump = pool.bump
    )]
    pool: Account<'info, Pool>,
}

impl<'info> SetOperator<'info> {
    pub fn set_operator(&mut self) -> Result<()> {
        self.pool.operator = self.new_operator.key();
        Ok(())
    }
}

- programs/usdc-pool-program/src/contexts/set_rate_authority.rs

#[derive(Accounts)]
pub struct SetRateAuthority<'info> {
    #[account(mut)]
    manager: Signer<'info>,
    #[account(
        mut,
        constraint = new_rate_authority.key() != pool.rate_authority.key()
    )]
    /// CHECK: The new rate authority account
    new_rate_authority: AccountInfo<'info>,
    #[account(
        mut,
        has_one = manager,
        seeds = [b"pool", USDC_MINT.as_ref(), pool.susd_mint.as_ref()],
        bump = pool.bump
    )]
    pool: Account<'info, Pool>,
}

impl<'info> SetRateAuthority<'info> {
    pub fn set_rate_authority(&mut self) -> Result<()> {
        self.pool.rate_authority = self.new_rate_authority.key();
        Ok(())
    }
}

To resolve this issue, it is advisable to establish a multi-step process for authority transfer (being rate_authority or new_operator), thereby enhancing the security of the operation. The current authority would first propose a new candidate authority, who would then need to formally accept the role.

This process would be structured as follows:

1. Proposal by Current Authority: The current signer proposes a new candidate signer. This action updates the candidate_authority field in the account's state. This step assumes the prior creation of an additional field candidate_authority the state.

   
   

2. Acceptance by New Authority: The proposed candidate_authority formally accepts the role. This step transfers the authority status from the current authority to the candidate_authority.

ACKNOWLEDGED: The Solayer team has acknowledged the issue.