Wayfinder

In `handleInvokeEchelon()`, the lock duration check (shown below) may be inaccurate if the `MAX_LOCK_TIMESTAMP` is set to some time far in the future. ``` if ( lockDuration != type(uint256).max && lockDuration > MAX_LOCK_DURATION && lockDuration + block.timestamp > MAX_LOCK_TIMESTAMP ) { revert("Lock duration must be less than 1095 days"); } ``` In particular, the last two conditions `lockDuration > MAX_LOCK_DURATION && lockDuration + block.timestamp > MAX_LOCK_TIMESTAMP` implies that `lockDuration` can be larger than `MAX_LOCK_DURATION` as long as `lockDuration + block.timestamp` is less than `MAX_LOCK_TIMESTAMP`. This means as long as `MAX_LOCK_TIMESTAMP` is far into the future, say `10 years` ahead, then having a `lockDuration` of `5 years` will still pass this check, contradicting the revert statement `revert("Lock duration must be less than 1095 days");` A similar issue exists in `extendDeposit()`.

The `handleInvokeEchelon()` function is marked as `public`, but it is only intended to be called by the `primeToken` contract.

The `withdrawDeposits()` function directly transfers `PRIME` tokens using `primeToken.transfer()`, which does not provide any safety checks and could lead to unexpected behavior if the token contract is not compliant with the ERC20 standard.

The `withdrawDeposits()` function transfers `PRIME` tokens within a loop, which could lead to high gas consumption and potentially cause a denial of service if there are a large number of deposits to withdraw.

The contract imports `Ownable2Step` and `Ownable` from OpenZeppelin, but they are not being used in the contract.