Incorrect reward accrual when updating lastRewardIndex on stake/unstake

`_updateRewardIndex()` should be invoked when changing `mintRate` to prevent retroactive re-pricing of accrued rewards

`lastMinted` should be updated to `block.timestamp` even when `totalStakedAmount == 0` in `_updateRewardIndex()` to avoid retroactive over-accrual.

If rewards are paid in WBTC, block-by-block calls to `StakingRewardsManagerBase.getRewardFor()` allow an attacker to meaningfully clip staker payouts.

An attacker can DoS `newMaker()` and `newTaker()` by making malicious assets.

`FULL_RESTRICTED` users can stake, violating invariant 7

Redeemer Doesn't Pay Any Fee

`initCollateralUsd` is incorrectly set when opening a leveraged position.

Collecting Fees from `vestPosition` May Revert Due to Incorrect `tickUpper` Usage

Incorrect `modulo` Calculation in `Strategy._setSecondaryPositionsTicks` When `tick < 0`

The `Leverager.withdraw()` Function Incorrectly Utilizes `amountOut0` Instead of `amountOut1` to Determine `repayFromWithdraw`

Incorrect rounding in the `_calcCost` function.

Attackers can drain the `OracleLess` contract by creating an order with a `malicious tokenIn` and executing it with a `malicious target`.

The `execute()` function should reset the approved amount for the `target` to 0 at the end.

The `AutomationMaster.generateOrderId()` function does not guarantee the generation of a unique `orderId`.

The `_cancelOrder()` function removes the `orderId` solely from the `pendingOrderIds` array, but does not remove it from the `orders` mapping.

Reentrancy attack in the `OracleLess` contract.

In the `oracleLess` contract, when an order is created, `tokenIn` is transferred from the `recipient`, which exposes it to potential attacks.

Attackers can drain the `StopLimit` contract.

The `execute()` function should utilize `forceApprove` instead of `safeApprove`.

Incorrect staleness check in the `PythOracle.currentValue()` function.

A `DoS` attack that makes order removal impossible in the `OracleLess` contract, causing all funds to become stuck.

Unfair fee calculation in the `ReputationMarket._calculateBuy()` function.

Incorrect modification of `marketFunds` in the `ReputationMarket.buyVotes()` function.

Improper fee mechanism in the `EthosVouch.applyFees()` function.

Absence of slippage protection in the `ReputationMarket.sellVotes()` function.

The `claim()` function can be front-run, resulting in the potential loss of all funds.