# MixBytes publishes its client security audits as a browsable report archive

> The audits_public repository is not a library or a tool but a publication channel: a directory tree of PDF security audit reports for DeFi protocols, staking systems and oracles, indexed in a Markdown table with client, project, category, report link and date. It suits a developer who wants to see what a review of a specific contract actually found before commissioning one.

**mixbytes/audits_public** — MixBytes Team public security audits

- Repository: https://github.com/mixbytes/audits_public
- Website: https://mixbytes.io
- Stars: 529 · Forks: 89
- Language: JavaScript
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/mixbytes-audits-public

## A publication channel, not a codebase

The repository is described as MixBytes Team public security audits, and the README says it contains security audit reports performed by the MixBytes team and released with client approval. That last clause is the important part of the framing. These are not the team's internal working notes; each report was published because the client agreed to it, which is the usual condition for a public audit in the DeFi world and the reason the archive is credible rather than marketing. The structure is correspondingly simple. There is a Markdown table at the top of the README with five columns, Client, Project, Category, Report and Date, and each row links to a PDF stored in a directory named after the client and the project. The tree at the root of the repository shows the same shape at scale, with one directory per client: Lido, Gearbox Protocol, DIA, Shift, Resolv, P2P.org, MEV-X, 1inch, AAVE, Aragon, Curve Finance, Euler, Instadapp, Notional Finance, Sushi, along with many more. There is a .github/ directory, a .scripts/ directory and a .gitignore, and the primary language is listed as JavaScript, which is consistent with a repository whose content is generated or maintained by scripts rather than written by hand as code.

## Reading the index table

The index is the useful part and it is denser than it first looks. Each row carries a client, a project, a category badge, a link to the PDF and an ISO date, and the category column is where the information is. Recent entries cover categories such as Liquid Staking, Oracle, RWA, Lending, Yield Aggregator, Liquid Restaking, Staking and DEX. Lido dominates the visible portion of the list, with entries for an Oracle v8.2.0 Diff dated 2026.10.07, an Execution Delegation Framework and a DIA Oracle V3 both dated 2026.09.11, L2 Direct Staking dated 2026.09.03, an Easy Track factory for Deposit Reserve Target management dated 2026.09.02, and an Oracle v8.0.6 dated 2026.08.31. Gearbox Protocol appears with Integrations-v3 for Securitize RWA dated 2026.08.24 and for Midas RWA dated 2026.08.14, plus a Gearbox core v3 Account Factory Diff on 2026.08.07. Other clients in the visible range include Resolv Vault Street, Shift's DeFi Platform and USDT0 Bridge and Strategies, P2P.org's Eth2 Depositor and Staking Fee Distributor, and MEV-X Homelander. The project names in the table are as informative as the categories, because they name the exact artefact under review rather than the protocol as a whole.

## Why the scope naming is the detail that matters

Look closely at the project column and you notice a pattern worth internalising before you read any of these reports. Several entries are named with a version, such as Oracle v8.2.0 Diff and Oracle v8.0.6, and several are explicitly a Diff, such as Gearbox core v3 Account Factory Diff and P2P.org Staking Fee Distributor Diff Audit (v1). That is the audit industry convention for reviewing a proposed change to an already deployed system rather than a codebase from scratch, and it has a direct consequence for how you read a finding. A diff review covers the changed lines and their immediate context, so a report in this category is not a statement about the whole contract, and a clean result does not mean the rest of the contract was audited. The Easy Track factory entries and the migrator entries, such as the Lido AAVE Migrator and GGV Migrator V2, sit on the other side of that line: a factory or a migrator is a self contained piece of code with its own boundaries, which is why it can be reviewed as a unit. The distinction between a versioned snapshot of a component and a diff of a proposed change is the first thing to establish from the scope section of any report you read here.

## What a MixBytes public report typically contains

The repository does not document the report format, so what can be said is limited to what the structure implies. Each entry is a PDF named after the client, the project and the words Security Audit Report, stored under a directory named for the client and the project, and each is linked from the index table. The reports are the deliverable of a review engagement, so they normally cover a scope statement, the findings raised against that scope, an assessment of severity, and a disposition for each finding. The repository's own value is that it lets you compare those outputs across many engagements without an NDA, which is what makes it usable as a calibration reference. The date column is the other axis of the index, and it runs from entries dated 2026.10.07 back through the 2026 releases, so the archive is current rather than historical, which cuts both ways: you get recent practice, but every report ages as the audited code changes.

## Using the archive to calibrate your own review

The practical use for an engineer is not to read a finding about a contract you will never touch, but to learn what a serious review of your own code should contain. Reading two or three reports for the same category of contract, such as two oracle reports or two diff reviews, shows you the recurring vulnerability classes that a competent review looks for, the severity language that a client can act on, and the format the fixes are described in. That gives you something a checklist cannot: a sense of coverage. The categories in the index also tell you which contract types have proven difficult enough to keep hiring auditors, and the mix is instructive, with liquid staking and restaking appearing most often, then oracles, then lending integrations, then bridges and RWA structures. One caveat belongs here. A public report tells you what a reviewer found, not what exists, so it is a floor rather than a ceiling, and the absence of a finding in a report is weak evidence about the code.

## Where this repository is the wrong place to look

Four limits are worth stating plainly. The first is that there is nothing to install and nothing to run. There is no package on PyPI or npm, no CLI, no library and no configuration, so if you are looking for tooling that checks your contracts, this is the wrong repository and you need a static analysis tool or a linter instead. The second is that the reports are PDFs. There is no machine readable findings format, no severity as data, no diff of the report text against a newer version, which means you cannot build a tracker over this archive without parsing documents, and you cannot diff two versions of the same review automatically. The third is the licensing position. GitHub does not classify the licence for this repository, the LICENSE file is not something the project description explains, and the reports themselves are client intellectual property released with approval, so reuse of the report text beyond reading it is not something the repository grants you. The fourth is coverage. The visible index is dominated by a handful of clients, Lido above all, and the directory listing runs to many more names, but a sample of one firm's engagements is not a survey of the ecosystem, and a contract type absent from the archive is not a contract type nobody audits. The realistic alternative for a comparable reference is the published audit trail of a large protocol, which tends to include both public reports and remediation notes, giving you the findings and the fixes in one place rather than the findings alone.

## Conclusion

Adopt this repository as a reading list rather than a dependency, because a set of dated, public review reports for named contracts and protocols is a good calibration source for what a serious audit covers and how findings are written up. Do not expect software from it, since there is no package to install, no code to run and no API, and the reports are PDFs rather than machine readable results. Verify two things before you draw a conclusion from any report: the date, because the listed audits are recent but the code they cover moves fast and a 2026 report says nothing about a later commit, and the scope, since each row names a specific project and version such as Oracle v8.2.0 Diff or Integrations-v3, and the finding applies to that scope only. The practical first step is to open the PDF for the contract you are about to deploy and read the scope section first, then the findings, so you know which code the review actually covered.

## FAQ

### What is the MixBytes audits_public repository?

It is a collection of security audit reports performed by the MixBytes team and released with client approval. Each entry is a PDF stored in a directory named after the client and project, and the README indexes them in a table with client, project, category, report link and date.

### Which clients and protocols are covered in the MixBytes public audits?

The visible index includes Lido for several components including Oracle versions, the Execution Delegation Framework and L2 Direct Staking, plus Gearbox Protocol integrations, DIA Oracle V3, Shift, Resolv Vault Street, P2P.org Eth2 Depositor and MEV-X Homelander. The repository root holds one directory per client across many more names.

### What is the difference between a version review and a diff audit?

A versioned entry such as Oracle v8.2.0 covers a specific released version of a component, while an entry named Diff, such as the Gearbox core v3 Account Factory Diff, covers a proposed change to an already deployed system rather than the whole codebase. A clean diff result is therefore not a statement about the untouched parts of the contract.

### How do I find a specific audit report in the MixBytes archive?

Use the table in the README, which lists every report with its client, project, category, PDF link and date, and browse the directory tree at the repository root where each client has its own folder containing one folder per audited project.

## Sources

- [Issues](https://github.com/mixbytes/audits_public/issues)
- [mixbytes/audits_public on GitHub](https://github.com/mixbytes/audits_public)
- [Project website](https://mixbytes.io)
- [README](https://github.com/mixbytes/audits_public/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mixbytes-audits-public