# `Usd0PP::mintWithPermit()` no longer checks that the timestamp exceeds the bond start Low/Info · Sherlock · Stablecoin issuer · 11th November 2025 Finding L-2 of the Usual bUSD0 Upgrade security review. - Protocol: https://usual.money/ - Report: /reports/usual-busd0-upgrade - Source: https://github.com/0xsimao/audits/blob/main/Sherlock/private-audits/2025-11-11-usual-ii.pdf --- ## Summary `Usd0PP::mint()` checks that the timestamp is bigger than the bond start, but `Usd0PP::mintWithPermit()` doesn't, which is conflicting. ## Vulnerability Detail Most of the minting logic was moved to `Usd0PP::_deconstruct()`, but the timestamp and bond start check wasn't, and was kept only on the `mint()` function, having conflicting checks compared to `Usd0PP::mintWithPermit()`. ## Impact No impact since at the moment the timestamp is bigger than the bond start and the check is useless, but a fresh deployment could make it problematic. ## Code Snippet https://github.com/sherlock-audit/2025-11-usual-usd0-upgrade-nov-11th/blob/main/core-protocol/src/token/Usd0PP.sol#L230-L240 ## Tool Used Manual Review ## Recommendation Make the checks consistent across both functions. Disclosed by 0xSimao (https://0xsimao.com/). --- Related findings: - [Attackers will reset `avgStart` of any user making rewards stuck for longer and get lost to savings](https://0xsimao.com/findings/exactly-protocol-update-staking-contract-ii-avg-rewards-stuck-longer): Exactly Protocol Update - Staking Contract - [`rewardData.releaseRate` is incorrectly calculated on `RewardsController::config()` when `block.timestamp > start` and `rewardData.lastConfig != rewardData.start`](https://0xsimao.com/findings/exactly-protocol-update-staking-contract-reward-release-rewards-timestamp): Exactly Protocol Update - Staking Contract - [In function mint() and lzReceive(), _safeMint() is recommended over _mint(), which performs additional checks](https://0xsimao.com/findings/metazero-i-mint-recommended-performs-additional): MetaZero Omnichain NFTs