6.1 Calling pause(...) and unpause(...) without checking current state leads to redundant event emissions
The pause(...) and unpause(...) functions in the DepositPool and PerpsStateVerifier contracts do not check whether the contract is already in the target state before updating storage and emitting state transition events.
As a result, authorized users can invoke pause(...) or unpause(...) repeatedly when the contract is already in that state, leading to duplicate Paused or Unpaused events still being emitted.
Recommendation
Consider adding state validation guards to both pause(...) and unpause(...) functions to verify that the contract is not already in the target state prior to performing storage modifications and emitting events.
6.2 Defensive balance-check pattern in deposit() is unnecessary for standard USDC
The deposit() function measures the actual USDC received via a balanceOf before/after pattern rather than trusting the caller-declared amount. However, USDC on Avalanche is a standard, non-rebasing, non-fee-on-transfer token, meaning the amount received will always equal the amount under current conditions.
USDC has an upgradeable proxy architecture, and hence Circle could theoretically introduce a transfer fee via a contract upgrade at any time in the future.
Recommendation
Consider introducing an owner-configurable maximum acceptable fee threshold in basis points (e.g., maxDepositFeeBps). On each deposit, compute the fee as the amount received and revert if it exceeds the configured threshold. This gives the team explicit control over how much transfer-fee slippage is acceptable.
6.3 Ownership transfer does not revoke pending operational-role nominations across both contracts
In both DepositPool and PerpsStateVerifier, acceptOwnership(...) updates only owner and clears pendingOwner, but does not invalidate any pending operational-role rotations that the previous owner may have proposed. These stale nominations remain executable by their nominees after the handover of ownership, without any authorization from the new owner.
When ownership changes, the contract must automatically clear all pending role nominations and reset their ETAs value to zero.
Recommendation
Clear all pending operational-role slots and their associated ETAs during ownership acceptance.
6.4 Role rotation functions do not check that the new address differs from the current one
The DepositPool contract manages rotations of administrative roles for the owner, operator, and authorizer. Role changes follow a two-step pattern: the owner proposes a new address, and a timelock must elapse before the rotation can be finalized.
However, the proposeOperator(...), proposeAuthorizer(...), and transferOwnership(...) functions only validate that the proposed address is not address(0). They fail to verify whether the proposed address matches the current holder of the role.
Recommendation
Consider adding validation in proposeOperator(...), proposeAuthorizer(...), and transferOwnership(...) to ensure that the proposed address does not match the current holder.
6.5 Missing enforcement of distinct addresses between owner and operator/authorizer roles
The DepositPool contract relies on a two-key custody separation model where the operator submits withdrawal transactions and the authorizer signs authorization payloads. Compromising either key alone should not be sufficient to drain funds.
The contract enforces that operator != authorizer cannot be the same address, but does not enforce the owner address to be distinct from operator or authorizer address.
As owner, operator, and authorizer are three distinct roles, it is recommended to keep them separate and not allow the roles to collapse into a single address.
A similar pattern exists in the PrepStateVerifier contract.
Recommendation
Consider adding explicit validation checks in the constructor(...) and all role assignment and acceptance functions, such as acceptOperator(...), acceptAuthorizer(...), and acceptOwnership(...), to ensure that the owner, operator, and authorizer variables strictly store unique addresses.
