Quantstamp reviewed Strata (Strata Tranches) on 28 Oct 2025: 4 findings, 0 critical; 3 marked fixed, 1 open.
Report hosted on certificate.quantstamp.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 0 |
| Medium | 0 | 0 | 1 |
| Low | 1 | 0 | 2 |
In the `deposit_viaSwap()` function, if the depositor does not specify `params.swapAmountOutMinimum`, the protocol attempts to set a default slippage tolerance based on the `minimumReturnPercentage` for a given input token set in the `autoSwaps` mapping. However, no decimal normalisation takes place to ensure the input and output tokens have the same amount of decimal precision. This means that when trading from a token with less decimals (for example USDT/USDC, which both have 6 decimals) to a token with more decimals (such as USDe which has 18 decimals) the `swapAmountOutMinimum` will be set to a value much smaller than intended, making the user susceptible to losing most of their input amount in slippage. Conversely, if performing a swap from a token with a large number of decimals to one with a smaller number, the default slippage tolerance will be set to a significantly larger number than the actual expected output causing the swap to always fail.
When withdrawing from the junior vault, the `cdo.maxWithdraw()` function will validate that the user's withdrawal will not drop the junior to senior vault ratio below the `minimumJrtSrtRatio` value. When the protocol is operating normally this is an important check to ensure that there is a sufficient balance in the junior vault to handle potential shortfalls in the senior vault yield. However, in a protocol-wind-down scenario or in an emergency scenario, where a complete exit from the protocol is recommended, a non-zero `minimumJrtSrtRatio` would prevent all funds being removed from the junior vault until all funds have been removed from its senior counterpart.
In the `TrancheDepositor.depositWithPermit()` function, the contract utilizes a token’s ERC-2612 permit functionality without protection against front-running attacks. The vulnerability stems from the deterministic nature of permit signatures and the lack of error handling when permit calls fail. An attacker can front-run the user's transaction, consume the signature provided to `depositWithPermit()` and force the `ERC2616.permit()` call made within the `depositWithPermit()` function to revert, impacting UX and causing the user to lose funds to transaction fees.
The report names a repository or files. Open the report to see its scope.
236 projects reviewed · 332 reports · latest Oct 2026
See Quantstamp’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us