OnRe security record

The `cancel_redemption_request` instruction accepts both `redemption_offer` and `redemption_request` as mutable accounts but does not enforce any relationship between them. There is no validation that the provided redemption request belongs to the specified redemption offer.

When an offer's total duration is not evenly divisible `price_fix_duration`, a partial interval will occur at the end of the offer period that is not accounted for in the protocol's pricing calculation. The price calculation logic fails to properly handle this edge case, causing users who transact during this period to pay one interval more than the intended maximum price (`sell_token_end_amount`). An additional note here is that in the current implementation this behaviour will also occur if a user calls one of the take offer functions in the final second of the offer, because of the inclusive upper bounds check on `offer.offer_end_time`. Consider this simplified example: 1. The team creates an offer where the duration from start to end is 2.5 days. 2. The `price_fix_duration` is set to one day. 3. Assuming the start price is 10e9 and the end price is 20e9. 3. The `number_of_intervals` used in `calculate_current_sell_amount()` will round down to two one day long intervals due to integer division (`216_000 // 86_400`). 4. Users transacting on day one will pay the start price plus one interval price (15e9). 5. Users transacting on day two will pay the start price plus two interval prices, this will be the intended `sell_token_end_amount` ratio (20e9). 6. However users transacting in the additional half day will be charged the start price plus 3 interval bumps, causing them to pay a greater amount (25e9) than the intended `sell_token_end_amount` ratio.

The Prop AMM tracks net sell volume across discrete time windows of length`epochDurationSeconds` to adjust dynamic wall liquidity and apply redemption haircuts. However, epoch boundaries are not aligned with absolute time (e.g., using `block.timestamp % epochDuration`). Instead, epochs are event-driven and updated lazily on trade execution by setting `state.epochStart = uint64(currentTime)`. Because the decay calculation evaluates time elapsed relative to this stateful `epochStart` timestamp, historical volume does not decay smoothly across real time during low-activity periods. This introduces two primary vulnerabilities: 1. **Frozen & Prolonged Decay:** If trading halts after a high-volume sell-off, the historical volume penalty remains frozen at high severity. When a trade finally occurs long after the epoch should have ended, the protocol treats the elapsed time as a fresh epoch rollover (`elapsed >= epochDuration`), applying the full historical penalty to the new trade and re-anchoring `epochStart` to the current block timestamp. This extends the penalty's decay window far beyond its intended duration. 2. **Incentivized Market Freeze:** If a user trades between `1.0 * epochDuration` and `1.99 * epochDuration` after a spike in sell volume, they absorb 100% of the historical penalty and restart the full decay clock for everyone else. However, if all users wait past the `2 * epochDuration` threshold, the contract evaluates `elapsed >= epochDuration * 2` and completely wipes `previousNet` to 0. This creates an unaligned incentive where rational users are forced to freeze trading until the `2.0 * epochDuration` threshold passes to avoid absorbing an unfair haircut.

The `MakeRedemptionOffer` instruction defines `redemption_offer` as a PDA. However, subsequent instructions that accept the `redemption_offer` account do not revalidate its PDA derivation, which may allow incorrect redemption offer accounts to be passed in. Similarly, the `redemption_request` account is defined as a PDA in the `CreateRedemptionRequest` instruction, but its PDA constraints are not validated in other instructions that interact with it.

The `RedemptionOffer` account holds the state related to a given redemption offer, including the current `requested_redemptions` amount. This value is added to when a user creates a redemption request; however, it is not subtracted from when their redemption request is fulfilled. The inline documentation above the `fulfill_redemption_request()` function suggests that this action should take place, but the necessary logic is missing in the current implementation. This causes inconsistent accounting, making it more difficult for the protocol team to correctly ensure they provide the necessary amount of tokens to fulfill all requests.

The `pub boss: Signer<'info>` account in `CloseOfferTwo` is not marked as mutable. The boss account is intended to receive rent refunds from closing the offer account and associated token accounts, requiring it to be mutable (`#[account(mut)]`). This missing constraint may cause the `close_offer_two()` instruction to fail.

The protocol uses an emergency killswitch that is described to prohibit minting and redeeming tokens while allowing token transfers, quotes, and other view functions. We highlight the following locations where the killswitch may depart from the specification: - `LibOnReVault._withdrawConfigurableVault()`: `isKilled` is checked before processing any withdrawal. This blocks fee, proceeds, liquidity, and buffer-reserve transfers to their configured destinations. - `LibOnReOffer._previewExecution()`: This function routes previews through `_requireExecutableOfferConfig`, which reverts when killed. This freezes all quotes. - `LibOnReBuffer.setBufferGrossApr()` and `LibOnReBuffer.setBufferFeeConfig()`: Buffer configuration changes can still result in a mint. Both functions settle accrued returns through `_accrue()` and a potential downstream call to `IManagedToken.mintBuffer()` without checking the killswitch. - `ManagedToken.mintBuffer()`: Direct token supply changes remain possible for authorized minters / burners.

The token contract exposes the `burnFrom` function to facilitate burns using allowances. However, since this function forces a call to `_spendAllowance()`, it will revert if the caller attempts to burn from their own balance (`account = msg.sender`). This may cause unexpected reverts for integrating protocols and thus composability issues.

The `swap_v2` implementation allows any `remaining_accounts_info` passed in the data to be included as supplementary tick arrays on top of the three default tick arrays provided. Requiring that the swap is executed within the three default tick arrays may mean some swaps that can be executed correctly may unexpectedly fail. The likelihood of this increases if the liquidity across ticks is shallow or if the size of the desired swap is large.

The architecture of the mmbot programs intends to limit the actions of the `executor` to making swaps between ONYC token and stablecoins (USDC and USDG). However, due to there being no validation on which tokens are swapped, a malicious `executor` would be able to trade the funds present in the protocol for any arbitrary tokens. This opens up a number of scenarios where theft of the protocol's funds is possible.