Taler Finance security record

The fee system in `FeeModule` uses a two-path accounting model for management fees. During accrual in `_accrueFees()`, the management fee accumulator `mgmtSharesPerBps` advances and `totalPendingFeeShares` is incremented by the floor-divided share count for that individual accrual. Every accrual adds an increment by a floored share count. When `claimFees()` later calls `_settleEntry()`, it computes the owed shares from the full accumulated delta since the entry's last checkpoint as a single floor division over the combined delta. However, by the fundamental property of floor division, `floor(a) + floor(b) <= floor(a + b)`. This means the sum of per-call pending increments accumulated across multiple accruals can be less than the single-shot settlement amount computed in `_settleEntry()`. When the fractional remainders of the individual accrual divisions sum to at least `ACCUMULATOR_PRECISION`, the settlement exceeds `totalPendingFeeShares` by at least 1 wei. The subtraction `totalPendingFeeShares -= shares` in `claimFees()` then underflows and reverts. This occurs during normal vault operations with no attacker required. Any two deposits, withdrawals, or other operations that trigger `_accrueFees()` on different blocks without a `claimFees()` call in between can create the 1-wei drift. The revert blocks the entire `claimFees()` call across all entries, as well as `removeFeeEntry()` and `removeFeeEntryAsAdmin()`. The DoS is recoverable without a contract upgrade through a careful settle-between-accruals admin procedure, but this requires multiple cycles and is non-trivial. User funds remain safe as fee accounting is isolated from share and asset accounting.

The `FeeModule` maintains a global `highWaterMarkNavPerShare` to prevent double-charging performance fees on the same NAV gain. When all performance fee entries are removed via `_removeFeeEntry()`, the code resets the high-water mark to zero when `totalPerformanceFeeBps` reaches zero. This allows `_initializeFeeTimingState()` to properly re-initialize the high-water mark at the current `assetsPerShare()` when a new performance fee entry is later added. However, when `updateFeeEntry()` is used to set an entry's performance fee to 0 bps instead of removing the entry, `totalPerformanceFeeBps` drops to zero but the high-water mark is not reset. The HWM reset logic exists only in `_removeFeeEntry()` and is absent from `_updateFeeEntry()`. When a new performance fee entry is subsequently added via `addFeeEntry()`, `_initializeFeeTimingState()` checks whether `highWaterMarkNavPerShare` equals zero and skips re-initialization because the stale value persists. A related discrepancy exists on the `updateFeeEntry()` path. When `_updateFeeEntry()` is used to set an entry's performance fee to 0 bps instead of removing it, `totalPerformanceFeeBps` drops to zero but the HWM is not reset because the reset logic only exists in `_removeFeeEntry()`. The stale HWM then persists, and when a new performance fee entry is later added via `addFeeEntry()`, `_initializeFeeTimingState()` skips re-initialization because `highWaterMarkNavPerShare` is nonzero. Depending on NAV movement relative to the stale mark, fee recipients may lose legitimately earned performance fees (if the new entry must exceed an old HWM that is above the intended starting point), or depositors may be overcharged (if the stale HWM sits below the price at which the new entry was meant to begin tracking).

In the `AsyncRedemptionModule`, `requestRedemptionWithPermit()` calls `IERC20Permit.permit()` directly without a try/catch wrapper. This differs from the `Vault._tryPermit()` which gracefully handles permit failures using try/catch. If a user's permit signature is front-run and consumed by a third party before their transaction executes, the `requestRedemptionWithPermit()` call will revert, forcing the user to fall back to a separate `approve()` + `requestRedemption()` two-transaction flow.

In both gateway execution paths, the event `ExecutionFromModuleFailure` is effectively unreachable under the current vault implementation. `ExecutionGateway.execTransactionFromModule()` performs a low level call to `Vault.executeAction()` and immediately bubbles the revert data if that call fails. `ExecutionGateway.execTransactionFromModuleReturnData()` invokes `Vault.executeAction()` through a Solidity external call, which also bubbles reverts by default. Inside `Vault.executeAction()`, the downstream call result is checked and the function reverts with `Vault_ActionFailed()` whenever the action result is false, instead of returning `(false, returnData)`. As a result, both gateway functions proceed to event emission only on successful execution, making `ExecutionFromModuleFailure` a dead monitoring signal for offchain services. Integrators that rely on that event for failure detection will miss failed executions and must parse revert traces instead.

`VaultFactory.deployVaultSystem()` accepts assets with up to 77 decimals. Because share decimals equal `assetDecimals + 2`, a 77 decimal asset produces a 79 decimal share token. Both `Accounting.assetsPerShare()` and `AsyncRedemptionModule._convertToAssets()` compute `10 ** shareDecimals`, which overflows `uint256` at 79 decimals. Deposits still succeed because their conversion path only uses `10 ** DECIMALS_OFFSET` (where offset is two), so the overflow surfaces later when settlement calls `assetsPerShare()`, permanently blocking epoch settlement and user claims.

In the `Accounting` contract, `removePosition()` calls `position.adapter.calculateNav()` and requires the result to equal zero before allowing removal. If an adapter becomes non-functional (e.g., reverts due to a broken oracle dependency, a paused external protocol, or a buggy upgrade), the `calculateNav()` call will revert, making it impossible to remove the position through the normal path. Since `totalAssets()` also iterates all positions and calls `calculateNav()`, a bricked adapter will additionally DoS deposits, redemptions, and fee accrual until the adapter is restored or an upgrade is performed.

The management fee accrual path in `_accrueFees()` computes two values on each call: the accumulator delta `mgmtAccumDelta` which is unconditionally added to `mgmtSharesPerBps`, and the total management shares `totalMgmtShares` derived by multiplying the delta back by `totalMgmtBps` divided by `ACCUMULATOR_PRECISION`. The `totalPendingFeeShares` tracker is only incremented when `totalMgmtShares` is non-zero. However, when `mgmtAccumDelta * totalMgmtBps` is less than `ACCUMULATOR_PRECISION`, the floor division produces zero shares and `totalPendingFeeShares` is not incremented while the accumulator continues to advance. Over many such zero-rounding calls, the accumulated delta grows large enough that `_settleEntry()` produces non-zero shares that were never tracked in `totalPendingFeeShares`. The subtraction in `claimFees()` then underflows and reverts. This requires an active attacker calling `accrueFees()` at high frequency on vaults with low supply and low-decimal underlying tokens such as WBTC or USDC. The thresholds are restrictive: a WBTC vault at 200 bps must hold under approximately 9,450 dollars worth of assets for the zero-rounding condition to trigger on per-second accruals. For 18-decimal tokens the threshold is below one billionth of a dollar, making them immune. The attack cost in gas significantly exceeds the value of fees denied, making it economically irrational.

The protocol currently targets Ethereum L1, where Chainlink feeds update independently and no sequencer exists. However, the team has stated the code should be compatible with L2 networks. When the sequencer goes down and later recovers, it replays queued transactions against oracle prices that may not have been updated during the outage. Chainlink provides [L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds) specifically for this scenario. Neither `OracleMiddleware` nor any of the NAV adapters check the sequencer uptime feed or enforce a grace period after the sequencer restarts. If the protocol is deployed to an L2 without adding this check, the adapters could read stale prices immediately after a sequencer recovery, before Chainlink feeds have had the opportunity to update. This can lead to incorrect NAV calculations during the post recovery window, potentially allowing deposits or redemption settlements at mispriced values.

`Vault.executeAction()` supports sending native tokens via `to.call{value: value}(data)`, but there is no way for native tokens to reach the vault. The `ExecutionGateway` forwards execution requests to the vault through two functions, and neither passes `msg.value` along. Additionally, `Vault` does not declare a `receive()` or `fallback()` function. Together, these omissions make the `value` parameter in `executeAction()` dead code. This prevents the vault from interacting with any external protocol that requires native token payment as part of a function call.

The NAV slippage protection in `Vault.executeAction()` compares the NAV before and after each individual execution. After each execution, the NAV cache is updated to `navAfter`. This means the slippage baseline resets with every call. An executor can chain multiple actions, each reducing the NAV by just under the tolerance limit, and the cumulative reduction compounds well beyond what the vault owner likely intended when setting the tolerance.