## Summary When the **folio** is killed or migrated, the `accrue_rewards` function cannot be called, preventing the user from updating their `reward_info`. This leads to the loss of some rewards for the user, as both the global `reward_info` and the individual user's `reward_info` can only be updated via `accrue_rewards`. ## Finding Description ```solidity pub fn accrue_rewards<'info>( system_program: &AccountInfo<'info>, token_program: &AccountInfo<'info>, realm: &AccountInfo<'info>, folio: &AccountLoader<'info, Folio>, actor: &Account<'info, Actor>, folio_owner: &AccountInfo<'info>, governance_token_mint: &AccountInfo<'info>, governance_staked_token_account: &AccountInfo<'info>, caller: &AccountInfo<'info>, caller_governance_token_account: &AccountInfo<'info>, user: &AccountInfo<'info>, user_governance_token_account: &AccountInfo<'info>, folio_reward_tokens: &AccountLoader<'info, FolioRewardTokens>, remaining_accounts: &'info [AccountInfo<'info>], // Claim rewards has this remaining account as mutable, so we need to pass it in, to pass our check fee_recipient_token_account_is_mutable: bool, ) -> Result<()> { ... UserRewardInfo::process_init_if_needed( caller_reward_info, system_program, caller, &caller_key, expected_pda_for_caller.1, &folio_key, &reward_token.key(), &reward_info, raw_caller_governance_account_balance, )?; ``` The user can only update their reward_info through accrue_rewards, but there are two ways accrue_rewards can be called: 1. accrue_rewards instruction – This allows users to manually update their reward_info by invoking the accrue_rewards function directly through an instruction. 2. FolioProgramInternal::accrue_rewards – When the user calls claim_rewards, this function is internally triggered to update the user's reward_info before the rewards are claimed. When the folio is killed or migrated, For the first method, calling the `accrue_rewards` instruction will result in an immediate error. ```solidity /// Validate the instruction. /// /// # Checks /// * Folio is valid PDA and valid status /// * The actor provided is the folio owner's actor /// * Realm is the one that owns the Folio Owner's governance account pub fn validate<'info>( folio: &AccountLoader<'info, Folio>, actor: &Account<'info, Actor>, realm: &AccountInfo<'info>, folio_owner: &AccountInfo<'info>, ) -> Result<()> { folio.load()?.validate_folio( &folio.key(), Some(actor), Some(vec![Role::Owner]), Some(vec![FolioStatus::Initializing, FolioStatus::Initialized]), )?; // Validate that the caller is the realm governance account that represents the folio owner GovernanceUtil::validate_realm_is_valid(realm, folio_owner)?; Ok(()) } ``` For the second method, `FolioProgramInternal::accrue_rewards` will directly skip the execution of `accrue_rewards` and return `Ok` immediately, so the user's `reward_info` cannot be updated. ```solidity pub fn accrue_rewards<'info>( system_program: &AccountInfo<'info>, token_program: &AccountInfo<'info>, realm: &AccountInfo<'info>, folio: &AccountLoader<'info, Folio>, actor: &Account<'info, Actor>, folio_owner: &AccountInfo<'info>, governance_token_mint: &AccountInfo<'info>, governance_staked_token_account: &AccountInfo<'info>, user: &AccountInfo<'info>, caller_governance_token_account: &AccountInfo<'info>, folio_reward_tokens: &AccountLoader<'info, FolioRewardTokens>, remaining_accounts: &'info [AccountInfo<'info>], fee_recipient_token_account_is_mutable: bool, ) -> Result<()> { let loaded_folio = folio.load()?; // If the folio is not initializing or initialized, we don't need to accrue rewards. if ![FolioStatus::Initializing, FolioStatus::Initialized] .contains(&loaded_folio.status.into()) { return Ok(()); } accrue_rewards( system_program, token_program, realm, folio, actor, folio_owner, governance_token_mint, governance_staked_token_account, user, caller_governance_token_account, user, caller_governance_token_account, folio_reward_tokens, remaining_accounts, fee_recipient_token_account_is_mutable, )?; Ok(()) } ``` Since the user's `reward_info` cannot be updated to the latest, the user will lose a portion of their rewards. For example: 1. At time 1, the user updated their `reward_info` index to 50 by calling `claim_rewards`. 2. After some time, the global `reward_info` index increases to 100, but during this period, the user did not update their `reward_info`. 3. If the folio is killed or migrated, the user will not be able to update their `reward_info` to 100, resulting in a loss of staking rewards for that period. ## Impact Explanation High, the user will lose staking rewards. ## Likelihood Explanation Med, there may be inactive users in the system. ## Recommendation It is recommended to add a method that can be called at any time to update the user's reward_info.

Contest	Date	Submissions	Payout
Reserve Protocol	Mar 3, 2025	9	$18,664
Daao	Jan 27, 2025	3	$119
Infrared Finance	Jan 15, 2025	4	$93
LI.FI	Jan 13, 2025	1	$0
Chorus One	Jan 13, 2025	2	$1,157
FarcasterAttestation	Jan 13, 2025	8	$3,189
Soon Labs	Dec 23, 2024	3	$4,193
Tensor	Oct 16, 2024	1	$1,241
Omni Network	Oct 14, 2024	1	$393
Primev	Oct 1, 2024	5	$600

shaflow01

Public reviews