# What Aster's Security Audits Actually Found (Every Report, Read)
> All seven published audits of Aster's contracts, read end to end: findings by severity per report, what was fixed versus accepted, and what the audits never covered.
- Source: https://asterpedia.com/privacy/aster-security-audits
- Category: privacy
- Published: 2026-08-18
- Updated: 2026-08-18
- Publisher: Asterpedia (https://asterpedia.com)
---
"Audited" has become a box on a landing page. It tells you a firm was paid to look, and almost nothing about what they saw. Aster publishes seven audit reports on its documentation site as raw PDFs, which is more than most venues do, and as far as I can tell nobody has read them for a reader. So I did, all seven, and this is what is in them.
Two things to say before the numbers. Audited is not safe, and nothing here is advice about whether to deposit. What follows is a report on what seven documents say, with the section and page references, so you can check every line of it yourself.
> **Key takeaway:** Across all seven reports there are **31 findings and not one high or critical**. The heaviest severity anywhere is medium, and there are six of those. The more interesting split is what happened next: on the **vault** report every one of the five findings is marked Mitigated, and reading the status text shows all five were **acknowledged with a written rationale rather than changed in code**. On the Earn-product reports, most findings were fixed in a named commit.
## What was audited, by whom, and when
Three firms, seven reports, spanning September 2024 to June 2025.
| Report | Auditor | What was in scope | Report date |
|---|---|---|---|
| AstherusVault | Salus Security | `contracts/AstherusVault.sol`, one file, at commit 98606bc | 13 September 2024 |
| Astherus Earn | Salus Security | `Earn.sol`, `Timelock.sol`, `WithdrawVault.sol`, `oft/AssXXX.sol`, `oft/TransferLimiter.sol` at commit edeb7de | 12 September 2024 |
| asBNB | Salus Security | `AsBNB.sol`, `AsBnbMinter.sol`, `Timelock.sol`, `YieldProxy.sol`, `libraries/FullMath.sol` at commit e1561e3 | 11 December 2024 |
| Astherus BNB Earn | PeckShield (#2024-274) | `ass-bnb-earn-contract` at commit 870d30e, whitebox method | 2 December 2024 |
| Astherus USDF Earn | PeckShield (#2024-275) | `ass-usdf-earn-contract` at commit c4b4a48, whitebox method | 3 December 2024 |
| asCAKE | Salus Security | `AssToken.sol`, `Buyback.sol`, `Minter.sol`, `RewardDistributionScheduler.sol`, `Timelock.sol`, `UniversalProxy.sol` at commit 5eb634c | 17 December 2024 |
| USDF & asUSDF | Halborn | 14 files in `astherus-usdt-contract` at commit d0fd0bb, including `USDF.sol`, `asUSDF.sol`, `USDFEarn.sol`, `asUSDFEarn.sol`, `WithdrawVault.sol`, `RewardDispatcher.sol`, `Timelock.sol` | engagement 25 to 30 April 2025, report last updated 16 June 2025 |
Every report names the exact commit it covered, which matters more than it sounds. An audit is a photograph of one commit, and the code has moved since.
## Findings by severity
Counts are taken from each report's own summary table, using each firm's own severity labels. Salus grades High, Medium, Low and Informational with no Critical band, so the empty Critical column on those four rows means the scale has no such category rather than that a category came back clean.
| Report | Critical | High | Medium | Low | Informational | Total |
|---|---|---|---|---|---|---|
| AstherusVault (Salus) | n/a | 0 | 1 | 4 | 0 | **5** |
| Astherus Earn (Salus) | n/a | 0 | 1 | 1 | 2 | **4** |
| asBNB (Salus) | n/a | 0 | 2 | 1 | 4 | **7** |
| asCAKE (Salus) | n/a | 0 | 1 | 0 | 3 | **4** |
| BNB Earn (PeckShield) | 0 | 0 | 0 | 3 | 0 | **3** |
| USDF Earn (PeckShield) | 0 | 0 | 0 | 2 | 0 | **2** |
| USDF & asUSDF (Halborn) | 0 | 0 | 1 | 1 | 4 | **6** |
| **All seven** | **0** | **0** | **6** | **12** | **13** | **31** |
The six mediums, named by their reports:
- **Centralization risk**, in both the AstherusVault and the Astherus Earn reports. Privileged roles and accounts hold powers that a compromised key would inherit.
- **Wrong activity removal logic** and **the newly added activity may affect the originally active activity**, both on asBNB, both business-logic errors in how reward activities are managed.
- **Token may be locked**, on asCAKE.
- **Users might receive less USDF than expected due to a race condition**, the single medium Halborn raised.
Nothing in that list is exotic. Centralization risk in particular appears in a large share of DeFi audits, because it is a description of how the system is governed rather than a bug in it.
## What was fixed, and what was accepted
This is the part a depositor actually cares about, and it is the part a severity table hides. A finding can be closed three ways: the code changes, the team explains why it does not need to, or the team simply notes it. The reports use different words for these, so I read the status text on every finding rather than trusting the column.
### The vault report: five findings, five acknowledgements, zero code changes
> **Warning:** On the AstherusVault report the summary table in section 2.1, on page 5, marks all five findings **Mitigated**. The per-finding status text in section 2.2, pages 6 through 10, tells a different story. Every one of the five opens with the same sentence: *"This issue has been acknowledged by the team."* None cites a fix commit.
The five rationales, verbatim in substance:
1. **Centralization risk** (medium): the team stated they will transfer to multi-sig accounts and implement timelock governors to enhance security. A stated intention at audit time, not a change the auditor verified.
2. **Not applicable for rebase token** (low): the team stated they do not support rebase tokens.
3. **Functions may be blocked if an ERC20 token is paused** (low): the team explained it is a risk-control function, and that when integrating a token they double-check the functionality is disabled.
4. **Chainlink's `latestRoundData()` might return stale results** (low): the team stated Chainlink price is not part of the core business and is only used for the user withdraw limit.
5. **Potential cross-contract or cross-chain signature replay** (low): the team stated the truthholder differs between chains, so there is no cross-chain risk.
Four of those five are reasonable answers. Whether the first one is depends on something the report cannot tell you: whether the multi-sig and timelock were ever actually deployed. That is checkable on-chain, and it is worth checking before sizing a deposit rather than taking a two-year-old stated intention as the current state.
### The Earn-product reports: mostly real fixes
The picture changes on the products built after the vault.
- **asBNB (Salus)**: all seven findings marked Resolved, with the floating-pragma fix cited to commit bb35f6f.
- **asCAKE (Salus)**: all four Resolved, fix cited to commit e24306b.
- **Astherus Earn (Salus)**: the medium centralization finding is Mitigated; the low and both informational findings are Resolved, one cited to commit 668c0e8.
- **BNB Earn (PeckShield)**: PVE-001 and PVE-002 Resolved; PVE-003, "Trust Issue of Admin Keys", Mitigated. The report names the post-fix commit as bb35f6f.
- **USDF Earn (PeckShield)**: PVE-001 Resolved; PVE-002, again "Trust Issue of Admin Keys", Mitigated. Post-fix commits a660303 and 7c20b84.
Two things are worth noticing. Admin-key trust is the one issue every firm raises and nobody closes, which is a structural property of the design rather than an oversight. And PeckShield's own summary line describes the contracts as "well-designed and engineered", with all findings low severity.
### Halborn: a cover page and a table that disagree
The Halborn report's cover page carries a large **100%** above the line "of all reported findings have been addressed." The findings table in section 6, Assessment Summary and Findings Overview, says:
| Finding | Severity | Remediation status |
|---|---|---|
| Users might receive less USDF than expected due to a race condition | Medium | Risk accepted, 13 June 2025 |
| The reward dispatcher contract does not utilise the pause functionality | Low | Risk accepted, 13 June 2025 |
| Functions are missing natspec | Informational | Acknowledged, 13 June 2025 |
| Comment in a foreign language | Informational | Solved, 13 June 2025 |
| Removing users from the emergency withdraw whitelist accepts an array as memory instead of calldata | Informational | Solved, 13 June 2025 |
| String reverts instead of custom errors | Informational | Acknowledged, 13 June 2025 |
Two solved, two acknowledged, two risk-accepted. Halborn's own assessment summary, section 2, puts it plainly: the improvements "were partially addressed by the Astherus team." "Addressed" is doing a lot of work on that cover page, and it is exactly the kind of number that gets screenshotted into a marketing deck without the table underneath it.
## What these audits do not cover
Scope is the most under-read section of any audit report, and here it is the most important one.
**The perpetuals exchange itself was not audited in any of these reports.** Every file in scope across all seven is a vault, an Earn product, a liquid-staking token, or its supporting plumbing. There is no matching engine, no order book, no [hidden-order encryption path](https://asterpedia.com/privacy/aster-hidden-orders-explained), no liquidation engine, no oracle infrastructure, and nothing touching the [1001x leverage product](https://asterpedia.com/guides/trading/aster-1001x-leverage-explained). If you are trading perps on Aster rather than depositing into Earn, none of these seven documents is about the thing you are using.
**Aster Chain is not in scope either.** The privacy L1 postdates every one of these reports.
**Nor is anything Aster has shipped since.** The most recent report covers a commit from April 2025, and Aster ships quickly. Between then and now the venue has added product surfaces and revised [the token's buyback and burn mechanics](https://asterpedia.com/ecosystem/aster-fee-buyback-burn-tokenomics), and [staking moved to an emissions model](https://asterpedia.com/ecosystem/aster-staking-explained) in 2026. None of that was reviewed in a published report.
**Economic attacks and third-party dependencies were explicitly excluded** from the Halborn engagement, which the report states in its Scope section. That exclusion is standard, and it means an oracle manipulation or a depeg driven by a dependency sits outside what any of this covers.
**Salus states the limit itself**, in the disclaimer on page 4 of each of its four reports: the audit "does not give any warranties on finding all possible security issues" and "the evaluation result does not guarantee the nonexistence of any further findings."
So the honest summary is narrow. Seven independent reviews of the custody and yield contracts found no high or critical issues, most of what they found was fixed, and the trading engine most people come to Aster for has no published audit at all. Whether that is acceptable is a judgment about your own risk, and one this site cannot make for you. If you are weighing venues on this dimension, our [Aster versus Hyperliquid comparison](https://asterpedia.com/compare/aster-vs-hyperliquid) covers what each publishes.
## How to read an audit report yourself
Six checks, in the order I use them, so you can do this on the next report without waiting for someone to write it up.
1. **Find the commit hash first.** It is usually in an appendix or a scope section. If the report does not name one, you cannot tell what was audited. If it does, compare it against what is deployed.
2. **Read the scope list, not the summary.** The file list tells you what was looked at. Everything not on it was not looked at, no matter what the marketing page says.
3. **Ignore the cover-page percentage.** Go to the findings table and count the statuses yourself. "Addressed", "mitigated" and "acknowledged" are not synonyms for "fixed", as the Halborn report above demonstrates.
4. **Read the status text under each finding, not just the status column.** That is the only place the AstherusVault pattern shows up.
5. **Note the severity scale in use.** Salus has four bands with no Critical; PeckShield has five. A zero in a column that does not exist is not a result.
6. **Check the date against the product.** An audit from September 2024 says nothing about a feature shipped in 2026.
That method is not specific to Aster. It works on any report, and it is most of what separates reading an audit from looking at one.
## Sources
All seven reports are published by Aster and linked from a single page. Read them rather than taking my counts on trust.
- [Aster's audit reports page](https://docs.asterdex.com/overview/audit-reports), which hosts all seven PDFs: AstherusVault, Astherus Earn, asBNB from Salus, asBNB from PeckShield, USDF from PeckShield, USDF and asUSDF from Halborn, and asCAKE from Salus.
The tallies, the fixed-versus-accepted split, and the scope-gap analysis on this page are mine, computed by reading those documents. Everything attributed to a report is quoted or paraphrased from it with the page named. Our [methodology page](https://asterpedia.com/methodology) explains how figures on this site are checked and how often.