What Aster's Security Audits Actually Found (Every Report, Read)

"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.

What was audited, by whom, and when

Three firms, seven reports, spanning September 2024 to 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.

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

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:

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, no liquidation engine, no oracle infrastructure, and nothing touching the 1001x leverage product. 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, and staking moved to an emissions model 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 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, 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 explains how figures on this site are checked and how often.

Sources & Citation

How these figures were verified

• Salus Security: AstherusVault audit report (Sep 13 2024) — the 1 medium and 4 low findings on contracts/AstherusVault.sol at commit 98606bc, the summary table in section 2.1 on page 5, and the per-finding status text in section 2.2 on pages 6 to 10. Checked August 18, 2026.
• Salus Security: Astherus Earn audit report (Sep 12 2024) — the 1 medium, 1 low and 2 informational findings across Earn.sol, Timelock.sol, WithdrawVault.sol, AssXXX.sol and TransferLimiter.sol at commit edeb7de. Checked August 18, 2026.
• Salus Security: asBNB audit report (Dec 11 2024) — the 2 medium, 1 low and 4 informational findings on AsBNB.sol, AsBnbMinter.sol, Timelock.sol, YieldProxy.sol and FullMath.sol at commit e1561e3, all marked Resolved. Checked August 18, 2026.
• Salus Security: asCAKE audit report (Dec 17 2024) — the 1 medium and 3 informational findings across AssToken.sol, Buyback.sol, Minter.sol, RewardDistributionScheduler.sol, Timelock.sol and UniversalProxy.sol at commit 5eb634c. Checked August 18, 2026.
• PeckShield: Astherus BNB Earn, report #2024-274 (Dec 2 2024) — the severity table on page 9 (0 critical, 0 high, 0 medium, 3 low) and the key-findings table on page 10 with PVE-001 to PVE-003 and their statuses. Checked August 18, 2026.
• PeckShield: Astherus USDF Earn, report #2024-275 (Dec 3 2024) — the severity table on page 9 (0 critical, 0 high, 0 medium, 2 low) and the key-findings table on page 10 with PVE-001 and PVE-002. Checked August 18, 2026.
• Halborn: Astherus / Aster security assessment (engagement 25 to 30 April 2025, last updated 16 June 2025) — the 1 medium, 1 low and 4 informational findings on the astherus-usdt-contract repository at commit d0fd0bb, the 14 files listed in the Scope section, and the per-finding remediation status in the Assessment Summary and Findings Overview. Checked August 18, 2026.
• Asterpedia — the cross-report tallies, the fixed-versus-accepted split, and the scope-gap analysis, all computed by reading the seven reports named above. Checked August 18, 2026.

Aster revises its fee schedules, leverage caps and token mechanics regularly, so every figure here is a dated snapshot rather than a live feed. Where a number comes from Asterpedia’s own tracking rather than the documentation, it is labelled as such above.

Cite this page

Asterpedia. "What Aster's Security Audits Actually Found (Every Report, Read)." Published August 18, 2026; last updated August 18, 2026. https://asterpedia.com/privacy/aster-security-auditsCopy

<a href="https://asterpedia.com/privacy/aster-security-audits">What Aster's Security Audits Actually Found (Every Report, Read)</a> — Asterpedia, updated August 18, 2026Copy HTML

Reuse

You may republish these figures with attribution and a link to https://asterpedia.com/privacy/aster-security-audits.