Security research
0xGuard audit evidence: remediation without a pinned revision
An OpenSwap finding marked fixed gives a reviewer a useful follow-up question: which exact revision implements the change? A project name and report date locate a document, but they do not uniquely identify the deployed bytecode. The MiniVerse example covers a different project and network; it should not be folded into a single undated claim about every deployment.
A fixed finding needs an identifiable code revision
Use this question to examine the evidence below before carrying an earlier observation into a new engagement.
Separate the historical observation from a current decision
The older 0xGuard analysis recorded a $4,500 test-project quote and a 30% discount conditional on payment within three days. Those are historical editorial observations. The surviving page does not supply a dated proposal and reproducible scope that could support a current quote.
This editorial revision replaces unsupported general praise and does not reproduce the old aggregate rating. DSA has not assigned a new technical score.
OpenSwap V2: the evidence boundary
Read the source report. Audit ended: .
- Reviewed scope
- MasterChef, OpenSwapBridge, Ownable, OpenSwapToken and UniswapV2Pair; Solidity on Binance Smart Chain.
- Revision evidence
- An explicit reviewed commit was not established from the captured report.
- Follow-up
- The conclusion says all high-severity and most low-severity issues were fixed. No fix commit is specified in the inspected report.
- Limit of the observation
- Historical review. The listed contract names do not identify a current deployment or prove that all findings were closed.
MiniVerse: the evidence boundary
Read the source report. Audit date: .
- Reviewed scope
- The report identifies Solidity contracts on Fantom and lists the checked contract addresses.
- Revision evidence
- An explicit reviewed commit was not established from the captured report.
- Follow-up
- No independently traceable fix revision was established in this review. Read the findings and conclusion in the PDF.
- Limit of the observation
- A report about this fork is evidence of that engagement only; deployment changes and current operation were not checked.
Build the release decision around traceable evidence
- Pin the proposed source revision and identify the contracts and dependencies included in the review.
- Choose a material finding in the relevant report. Trace its affected code and record the final disposition.
- Compare the reviewed revision with the intended deployment. Document subsequent changes and unresolved assumptions.
- Confirm the retest scope, assigned reviewers and current commercial terms directly.
Use the 0xGuard profile for field-level sources and the static analysis guide to plan the related technical checks. A tool result supplements the evidence packet; it does not replace a scoped audit.
Prepare an audit request with 0xGuard or compare other providers.
Sources
Checked . Local examples include their inputs and limits.
About this revision
Rebuilt the legacy company analysis around source scope, dated evidence and limits of historical claims. The URL is preserved. This is a DeFiSec editorial revision, not a new assessment by the provider or an expert committee.
Suggest a correction with evidence