TESTNET BUILD — no mainnet deployment, no real value. Nothing on this site is an offer or a live financial product.

← Audit register

Round 5 · 27–28 July 2026

Clean mainnet-v1 defensive audit

Internal review. This is an internal engineering review of source, not an independent external audit, and it does not by itself authorize a production launch. It reviews the source at the baseline below, which is not necessarily identical to the code deployed on any network. No mainnet deployment has been authorized or attempted. Nothing here is a securities-law representation; token characterization is a matter for counsel.

Scope
The ADR-0030 clean mainnet-v1 source, deployment scripts, storage namespaces, accounting, attestations, pause paths, compliance exemptions, and economic interactions.
Method
Defensive source review of the whole release tree, followed by a remediation pass and full re-verification across offline, fork, and deployed-Sepolia adversarial suites.
Internal report
audit-reports/PRE_MAINNET_SECURITY_REVIEW_2026-07-20.md (28 July addendum)

Findings and remediation history

Historical snapshot — superseded. ADR-0031 fee accounting and later impairment-source liveness remediation changed production source after this review. This is no longer the controlling review for the current deployment candidate and its hashes, coverage, and completion status must not be applied to current code.

Disposition

At the time it was written, this was the controlling review for that source snapshot. Where an older round's finding conflicts with this one, this one governs — ADR-0030 removed several subsystems that earlier rounds reported on, including the debt-service reserve, the reserve-instrument valuation path, the generic multi-stablecoin registry, and the legacy role and storage compatibility surfaces.

A defensive review of the clean mainnet-v1 source, its deployment scripts, storage namespaces, accounting, attestations, pause paths, compliance exemptions and economic interactions identified eight findings: two High and six Medium. No Critical finding, no permissionless theft path and no unauthorized-mint path was confirmed.

Four findings are now remediated in source. Four remain real and were explicitly accepted or deferred by the protocol owner for launch, including one High. Accepted is not the same as fixed. The prerequisite and the residual impact of each acceptance are recorded above so that governance, operators, external auditors and future maintainers can revisit the decision rather than inherit it silently.

The outstanding High, FRV-DSA-004, is accepted only for the initial Forest Road-controlled curator phase. It cannot be executed by an outside user and can only raise a queued depositor's exit toward ordinary NAV, never above it; it does not pay value to the curator. The residual is timing-based redistribution between depositors: an exiting depositor receives the direct benefit while remaining depositors can inherit more impairment after the temporary support is withdrawn. This trust assumption must be removed before any third-party curator or junior tranche is admitted.

Verification of the remediations

Completed locally against the remediated source:

  • the full offline contract suite passed 855 tests across 73 suites, with 0 failures;
  • the 180-test complete fork tree then passed with no failures or skips, alongside 3 of 3 adversarial checks forked from the deployed testnet stack;
  • source-only coverage entered every source-defined contract function and every source line, with 390 of 393 branches covered; the three uncovered defensive branches and their deployment relevance are disclosed in the internal report;
  • seven focused tests prove that substituting a principal, a nonce, an artifact, or the actual derived deployment runtime alters or invalidates the authorization receipt, that strict validation recomputes the receipt against an independent approval, and that contract or zero attesters are rejected;
  • storage tests prove fresh state lands at exactly the computed namespaced slots, while legacy proxy state remains readable after an upgrade;
  • the literal external mainnet deployment batch passed at a pinned Ethereum block, including manifest output, treasury delegation and strict validation;
  • the receipt tooling reproduces separate configuration, deployment-runtime, artifact-set, principal-set and final authorization hashes, all of which must be reproduced after any release change.

A 28 July follow-up also remediated FRV-DSA-005. The loss cascade's role-gated principal write-down now remains available while ReserveManager is paused, without reopening paused user or custody operations. A focused regression proves the loss lands across the expected layers while the reserve manager remains paused; the complete default and heavy Foundry profiles subsequently passed.

Release-tooling follow-up

The same review found seven release-pipeline defects around the remediations, all since closed:

  1. the full approval binds the actual derived deployment runtime rather than only the base deployment contract, and validation derives every implementation, proxy and immutable address from the approved deployer nonce;
  2. the rehearsal is pinned and calls the exact external entrypoint, with no silent pass;
  3. frontend configuration rejects zero and duplicate addresses and requires independently approved deployment and manifest receipts;
  4. the audit status and the reproducible exact-tree hash manifest cover the full reviewed release;
  5. public copy selects testnet or production legal and network language at build time;
  6. the post-deployment validator rejects zero attesters;
  7. bytecode reconciliation covers the immutable votes aggregator as well as all proxies.

Final release-safety recheck

A subsequent whole-tree review found two Medium release-safety defects, three Low release-evidence gaps and two Informational quality gaps. The owner selected five for immediate remediation; all five are closed:

  1. local fork builds use a distinct local chain identifier, and canonical chain identifiers are rejected for loopback endpoints;
  2. the production build invokes a fail-closed prebuild gate: a mainnet build reads one production manifest, verifies its independently approved digest and deployment receipt, recomputes its principal and creation sequence, and compares every manifest-derived build variable against that manifest;
  3. a lint preset with a known advisory was replaced with direct TypeScript, React-hooks and web-vitals configurations; both full and production-only dependency audits report zero advisories;
  4. current review material is explicitly labelled internal, and remediated findings are described in the past tense rather than repeating obsolete vulnerable-state language;
  5. both previously uncovered claim guards in the recovery top-up distributor now have direct regression tests.

A final corrective pass on 28 July closed the remaining release-tooling findings: local-fork reads, simulation, submission and receipt tracking all use the active wallet provider with chain and tip verification before writes, so two independent local chains cannot produce a false success; mainnet builds require an endpoint that live-attests the canonical chain, reaches the deployment block, and returns contract code at every manifest address; the production content-security policy permits loopback only for the explicit local profile while retaining transport enforcement for production; accessibility and React lint rules were restored without reintroducing the advisory preset; the live validator repeats the exact maximum-maturity assertion for the digital-assets class and proves a one-day mutation is rejected; and the contract tree passes its formatting gate.

The final endpoint-enabled run also caught a test-isolation defect in the new maturity negative: the fixture had not restored a deliberately corrupted validator argument before checking the class mutation. The fixture now restores it, the focused rehearsal passes, and the full fork rerun is clean. This did not expose a contract or deployed-state defect.

What this does not authorize

This is an internal engineering review, not an independent external audit, and it does not by itself authorize a production launch. A first production promotion requires an independent audit, economic and legal sign-off, operational ceremony review, and a fresh reproduction of the exact final receipt after production principals and the deployer nonce are frozen.

Earlier roundPre-mainnet campaign