OnRe security record

Several instructions in the program require mint authority to mint or burn tokens as part of their normal operation. This mint authority can be either a program-derived address or the `boss` account. However, since the program allows transferring ownership of the `boss` role, a boss transfer performed without properly updating the mint authorities of the relevant token mints can leave the program unable to mint or burn tokens. This would effectively result in a denial of service. Additionally, the `TransferMintAuthorityToProgram` instruction requires the current mint authority to be the active `boss` before allowing the authority to be transferred to a PDA. If the previous `boss` becomes inaccessible after boss transfer is performed, there is no mechanism to move the mint authority to the new `boss` or to the PDA, permanently blocking mint and burn operations.

In the current implementation of the deposit flow the redemption fee is calculated at the time the request is fulfilled. For larger redemption requests, which may be forced to wait before their request can be fulfilled, this may mean that the `fee_basis_points` taken out of their redemption has been changed by the admin between their initial request and its fulfillment, causing them to pay a larger amount in fees than they expected.

The `mint_to` instruction allows the boss to mint new ONyc tokens but does not check the `state.is_killed` flag intended to act as a global kill switch. As a result, token minting remains possible even when the protocol is placed into a killed or emergency paused state.

The `take_offer` instruction allows users to execute an offer by specifying only the amount of tokens in. This instruction does not accept or enforce any slippage bounds such as a minimum acceptable `token_out` amount or maximum execution price. Since the exchange rate is calculated at execution time using a chain state, users have no guarantee that the received amount of `token_out` matches their expectations at the time of transaction submission. This exposes users to adverse price movement without recourse.

The `initialize` instruction derives the program’s upgrade authority via `get_upgrade_authority()` and only enforces that `boss` matches this authority when the result is `Some(pubkey)`. If the program is immutable (upgrade authority is `None` under the upgradeable loader) or deployed under the `bpf_loader`, the function performs no alternative authorization check and proceeds to set the boss to the Signer. Since the `state` PDA is created deterministically with `init`, and if the `upgrade_authority` is `None`, then the first signer to call `initialize` will permanently set `state.boss` to themselves. Although an `ImmutableProgram` error exists, it is never used to prevent this path.

The `instructions::initialize::initialize()` function can be frontrunned after the program is deployed. An attacker might create a state and set themselves as a boss, preventing the real admin from controlling the program.