As of 30 Oct 2026, Strata has 7 audit reports by 3 security firms on Trustblock; the latest is by Cyfrin, dated 23 Jan 2026. Those reports list no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Strata Shares Cooldown Audit Report | Security firm: Cyfrin | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Strata - Update to Tranches | Security firm: Quantstamp | Date: | Scope: Repository at commit ef6dbfd | No open critical findings | Open · certificate.quantstamp.com |
| Strata Tranches | Security firm: Quantstamp | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · certificate.quantstamp.com |
| Strata Tranches Report | Security firm: Guardian Audits | Date: | Scope: Not recorded (see the report) | 1 critical finding, fixed | Open · GitHub |
| Strata Tranches Audit Report | Security firm: Cyfrin | Date: | Scope: Not recorded (see the report) | 1 critical finding, fixed | Open · GitHub |
| Strata PreDeposit Vaults | Security firm: Quantstamp | Date: | Scope: Files named in the report | No open critical findings | Open · certificate.quantstamp.com |
| Strata PreDeposit Audit Report | Security firm: Cyfrin | Date: | Scope: Not recorded (see the report) | 1 critical finding, fixed | Open · GitHub |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 3 |
| High | 0 | 0 | 8 |
| Medium | 0 | 0 | 30 |
| Low | 2 | 0 | 33 |
The report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportIn 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.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe reviewed changes introduce the mechanic of a withdrawal fee, which a privileged address can set between 0 and 1% of the user’s withdrawal amount. As users might have deposited at a time without the concept of a withdrawal fee or with it being set at e.g. 0%, a sudden change to 1% has non-trivial consequences for user’s strategies. In order for users to have a sufficient time window to react to a change to the fee parameter, we propose adding a 24 hour delay between proposed new fee value and enforcing it on-chain.
Open the reportWhen 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.
Open the reportIn 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.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe MetaVault enables different registered ERC4626 vault shares to be used similarly to USDe, the underlying asset of the vault. In the different deposits and withdraw flows involving those registered share tokens, the registered vault's `previewX()` functions are used to determine the appropriate converted amount to be tracked in the vault/the amount to be paid out. According to the ERC-4626 standard, however, the `previewX()` functions are supposed to not account for any withdrawal/deposit limits or pauses to the vault contract, they solely calculate the shares or underlying assets based on the conversion function at hand, ignoring additional state such as contract pause or deposit limits. For this fairly rare case of not just pricing the asset, but also making it interchangeably used with other registered share tokens and USDe, we think that the state-including check via the `maxX()` functions should additionally be performed.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe reports name a repository or files. Open a report to see its scope.
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="strata"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something 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