ApxUSD security record

`ApyUSD.setUnlockToken()` only checks for a nonzero address. It does not verify that the replacement contract was deployed for the active vault or for the correct underlying asset. This is dangerous because the withdrawal path assumes the configured contract is a compatible `UnlockToken`. A mismatched replacement can make every `withdraw()` and `redeem()` revert once `ApyUSD` reaches the external deposit/request path. A single bad admin rotation can brick the entire exit path for current and future vault users until the pointer is corrected.

When `BridgedApyxToken.mint()` is called by the CCIP pool, and the incoming amount would push `totalSupply` past `$.supplyCap`, the function reverts: ```solidity // src/bridge/BridgedApyxToken.sol:161-168 function mint(address account, uint256 amount) external onlyCCIPPool { BridgedApyxTokenStorage storage $ = _getStorage(); uint256 currentSupply = totalSupply(); if (currentSupply + amount > $.supplyCap) { revert SupplyCapExceeded(amount, $.supplyCap - currentSupply); } _mint(account, amount); } ``` Chainlink's CCIP `OffRamp` processes messages in strict sequence per lane. When a `mint()` call reverts, Chainlink's Smart Execution automation retries the failing message automatically for approximately 8 hours. During this entire window, every subsequent message on the same lane, regardless of sender, recipient, or amount, is blocked behind the stuck message. After the automatic retry window expires, the message remains in the queue indefinitely; a manual call to `manuallyExecute` on the `OffRamp` is required to unblock the lane, and only after the root cause (the supply cap violation) is resolved. This scenario can be triggered by either of two paths: 1. **Direct cap reduction:** `ADMIN_ROLE` calls `setSupplyCap()` on a `BridgedApyxToken` deployment with a value below the corresponding mainnet supply cap. If in-flight bridge messages carry amounts that would exceed the new, lower cap, the next `mint()` call reverts and the lane blocks. 2. **Mainnet cap increase without a bridged supply cap update:** If the mainnet `ApxUSD` supply cap is raised (to accommodate new collateral) without a corresponding increase to the destination-chain `BridgedApyxToken` supply cap, the bridged supply cap becomes the binding constraint. Users bridging amounts that would otherwise be permitted under the mainnet cap will encounter a `mint()` revert on the destination chain. The `IBridgedToken` NatSpec identifies both risks and makes two mitigation recommendations: ```solidity /// The cap SHOULD match the mainnet supply cap for the corresponding token. /// ... /// A delay on this function SHOULD be configured in the AccessManager to provide /// an observation window before any cap change takes effect. ``` Neither recommendation is enforced on-chain. `BridgeRoles.assignAdminTargetsFor()` assigns `setSupplyCap` to `ADMIN_ROLE` with no execution delay. `setTargetFunctionRole()` with no preceding `setTargetFunctionDelay()` call configures zero execution delay. A cap reduction takes effect in the same block it is submitted, with no observation window for operators to clear any in-flight bridge messages before the new cap becomes active.

`ApyUSD` overrides `_decimalsOffset()` to return `0`. OpenZeppelin documents that this default makes the classic first-depositor inflation attack unprofitable: the `+1` virtual term in the share conversion captures ~50% of any donation, so the attacker’s expected gains are offset. A malicious actor can still grief users by depositing `1` wei, donating more than twice the victim’s deposit to the vault, and causing the victim’s `deposit()` to mint `0` shares (full loss for the victim at a net loss for the attacker). The issue affects the initial deposit phase when the vault is empty or nearly empty.

`MinterV0` records rate-limit usage in `requestMint()` but `executeMint()` does not re-check or update the rate limit. A minter can queue requests over time and then execute them in a short window, bypassing the intended issuance cap for the rate-limit period.