# July 2026 Community Audit Remediation Register

**Updated:** 2026-09-30
**Repository baseline:** `564a7c4504c8da7a24a302204f4fd5e39d1abece`

This register shows the current status of every normalized finding in the community
audit submitted on 27 July 2026. The published report keeps the submitted text apart from
one disclosed company-name redaction and preserves the severity and project snapshot
recorded on that date. A red or high-severity label
in the original report is therefore historical severity, not proof that the issue is
still open today. Current status is authoritative only in this evidence-backed register.

- [Published report](IFR_Protocol_Audit_2026-07-27.md) (submitted text with one disclosed owner-requested company-name redaction, 2026-09-30)
- Published (redacted) SHA-256: `57ec9eeb3fa2de0b9ac4f62680a62ff8d2ea79dc19b89a0726e9b41b70fb3f12`
- Pre-redaction original SHA-256: `ec7f99b0b74c51e04091727a0b69f49f67c36409a52c9ea7b55ba545b6b3e375`
- [Audit index](README.md)
- [Current CWA-01...CWA-82 register](CWA_REMEDIATION_REGISTER.md)

## Status Summary

| Status | Count | Meaning |
| --- | ---: | --- |
| Fixed and verified | 12 | The correction is integrated and current repository evidence verifies the claimed scope. |
| Partially remediated | 3 | Material safeguards or wording corrections are integrated, but a stated part of the finding remains open. |
| Corrected outdated snapshot | 1 | The dated observation no longer describes current state; current facts and their evidence are published separately. |
| Governance or future-version gated | 4 | The remaining change needs an authorized governance action, migration or separately reviewed future contract version. |
| Accepted or monitored | 2 | The current limitation is explicitly documented and monitored; it must be revisited before the affected path is activated or replaced. |
| Open actionable | 1 | Repository, hosting or product work remains directly actionable. |

## Finding-by-Finding Status

| Finding | Severity at audit | Current status | Current assessment | Remaining action | Verification | Evidence |
| --- | --- | --- | --- | --- | --- | --- |
| **JUL-01** Project-wide legal, privacy and risk disclosures (section 3.1) | Critical | **Partially remediated** | Benefits now has a dedicated privacy surface and public claims carry narrower risk boundaries, but project-wide operator, privacy, terms and regulatory texts still require qualified German/EU legal review. | Complete qualified legal review and publish only the approved project-wide disclosures; keep lending fail-closed until its legal and technical activation gates are satisfied. | Legal approval, route/link checks on every public surface and a privacy data-flow review. | [apps/benefits-network/frontend/src/app/privacy/page.tsx](../../apps/benefits-network/frontend/src/app/privacy/page.tsx); [docs/community-audits/README.md](../../docs/community-audits/README.md) |
| **JUL-02** Unqualified lifetime-access marketing (section 3.2) | High | **Fixed and verified** | Active core copy now states that access remains active only while each product's required IFR stays locked and the integration remains available. | Keep the content-trust guard and review new product copy against the same qualified-access rule. | Content-trust test plus public Landing/Wiki claim checks. | [README.md](../../README.md); [scripts/test-content-trust.cjs](../../scripts/test-content-trust.cjs) |
| **JUL-03** LendingVault manual price and activation risk (section 3.3) | High | **Governance or future-version gated** | V1 borrowing remains fail-closed with ifrPriceWei = 0. Lender offers are live, but borrower activation is not approved and requires a bounded, fresh, pausable price path. | Design and independently review the V2 price path, caps, expiry behavior and emergency controls before any governed activation. | Oracle freshness/bounds tests, hostile-price tests, independent review, governance execution and post-execution chain checks. | [docs/wiki/roadmap.html](../../docs/wiki/roadmap.html); [docs/community-audits/cwa-remediation-register.json](../../docs/community-audits/cwa-remediation-register.json) |
| **JUL-04** Internal reviews presented as an external audit (section 3.4) | High | **Fixed and verified** | Current public copy distinguishes internal audits, community reviews and automated evidence from an independent professional certification, which remains pending. | Preserve the wording guard and do not use professional-certification language until a qualifying audit exists. | Content-trust test and Landing/Wiki/Copilot claim checks. | [docs/wiki/faq.html](../../docs/wiki/faq.html); [docs/index.html](../../docs/index.html) |
| **JUL-05** Dated adoption, liquidity and live-state snapshot (section 3.5) | High | **Corrected outdated snapshot** | The original zero-offer and zero-lock statements are historical. Current public status records live CommitmentVault locks and three LendingVault offers while still disclosing that borrowing is disabled and adoption remains limited. | Continue dated, source-labeled live-state reporting and never convert snapshots into evergreen adoption claims. | Block-pinned chain reads, current status tests and stale-data behavior on live surfaces. | [docs/wiki/roadmap.html](../../docs/wiki/roadmap.html); [docs/llms.txt](../../docs/llms.txt) |
| **JUL-06** Guardian and signer centralization (section 3.6) | High | **Governance or future-version gated** | Safe ownership and timelock controls are public, but guardian concentration and signer independence remain governance/key-custody questions rather than completed remediations. | Approve and execute a reviewed guardian/key-custody model or explicitly accept the current model with bounded operational controls. | Role inventory, proposal simulation, signer/key separation evidence and post-execution chain checks. | [docs/community-audits/cwa-remediation-register.json](../../docs/community-audits/cwa-remediation-register.json); [contracts/governance/Governance.sol](../../contracts/governance/Governance.sol) |
| **JUL-07** Vault fee-exemption solvency dependency (section 4.1) | Medium | **Partially remediated** | Mainnet exemptions and balance coverage are monitored fail-closed, with negative regression tests. Deployed V1 still depends on the exemptions; balance-diff accounting is a V2 requirement. | Keep invariant monitoring active and implement runtime exemption checks plus balance-diff accounting in a separately reviewed V2. | Scheduled chain monitor, negative exemption tests and future V2 deposit/withdraw lifecycle tests. | [docs/VAULT_FEE_EXEMPT_HARDENING.md](../../docs/VAULT_FEE_EXEMPT_HARDENING.md); [scripts/test-vault-invariants.cjs](../../scripts/test-vault-invariants.cjs) |
| **JUL-08** Fee-on-transfer buyback swap accounting (section 4.2) | Medium | **Governance or future-version gated** | Source remediated for future deployments (T-189): BuybackController and BuybackVault swap via swapExactETHForTokensSupportingFeeOnTransferTokens and account for the IFR actually received (balance difference); BuybackVault events report the IFR credited to BurnReserve and Treasury, tested with the real InfernoToken with and without exemptions (on Mainnet the vault, controller, BurnReserve and Treasury are fee-exempt, verified 2026-10-02). The deployed Mainnet buyback contracts are unchanged and stay dormant. | Keep the deployed path dormant; activate only through an independently reviewed, governed redeploy of the remediated sources. | Taxed-token router tests with received-balance assertions pass (test/BuybackController.test.js, test/BuybackVault.test.js); independent review and governed deployment evidence remain required before activation. | [contracts/buyback/BuybackController.sol](../../contracts/buyback/BuybackController.sol); [contracts/buyback/BuybackVault.sol](../../contracts/buyback/BuybackVault.sol); [test/BuybackVault.test.js](../../test/BuybackVault.test.js) |
| **JUL-09** Apex security-header limitations (section 4.3) | Medium | **Open actionable** | Application-level safety controls have improved, but GitHub Pages does not provide the full desired response-header policy at the apex host. | Select a serving-layer solution that can enforce CSP, HSTS, frame protection, nosniff and permissions policy without breaking wallet flows. | Live response-header contract and desktop/mobile wallet regression suite. | [docs/community-audits/cwa-remediation-register.json](../../docs/community-audits/cwa-remediation-register.json) |
| **JUL-10** Public operational TODO artifacts (section 4.4) | Medium | **Fixed and verified** | The public TODO files were removed and CI now fails if either file reappears under docs. | Keep operational notes outside the public docs tree and retain the content-trust guard. | Content-trust test and public link scan. | [scripts/test-content-trust.cjs](../../scripts/test-content-trust.cjs) |
| **JUL-11** Wallet-critical browser dependencies (section 4.5) | Medium | **Partially remediated** | Ethers v6 is pinned and self-hosted. On the local integration branch (merge and release still pending) the WalletConnect provider is also bundled as a pinned, reproducibly built same-origin artifact instead of a runtime CDN import; the finding stays partially remediated until that integrated build is merged, released and connector parity is re-verified. | Verify WalletConnect connector parity across supported browsers and devices on the integrated build. | Asset integrity check, no-runtime-CDN assertion and full wallet/browser regression matrix. | [docs/web3/index.html](../../docs/web3/index.html); [docs/assets/wallet-core.js](../../docs/assets/wallet-core.js); [scripts/check-web3-wallet-runtime.cjs](../../scripts/check-web3-wallet-runtime.cjs) |
| **JUL-12** Unreproducible coverage and drifting test counts (section 4.6) | Medium | **Fixed and verified** | Current canonical test counts are centralized and checked. The old coverage percentage is labeled as a historical subset snapshot rather than current full-repository evidence. | Update the canonical matrix only with reproducible test evidence and keep historical coverage explicitly dated. | Status-baseline, functionality-status and CWA-register CI guards. | [README.md](../../README.md); [README.md](../../README.md) |
| **JUL-13** Cross-surface numeric and narrative drift (section 4.7) | Medium | **Fixed and verified** | The CWA-57 through CWA-73 content-drift findings are corrected against contract, route and block-pinned chain evidence; CWA-74 is informational. | Retain the dedicated CWA content-coherence guard and update dated values only with matching evidence. | CWA content-coherence, content-trust, status-baseline, cross-surface routing/link tests and block-pinned supply evidence. | [scripts/test-content-trust.cjs](../../scripts/test-content-trust.cjs); [docs/community-audits/cwa-remediation-register.json](../../docs/community-audits/cwa-remediation-register.json); [scripts/test-cwa-content-coherence.cjs](../../scripts/test-cwa-content-coherence.cjs) |
| **JUL-14** LP custody and lock explanation (section 4.8) | Medium | **Fixed and verified** | Public surfaces now state that Team.Finance was disabled, LP tokens remain in finalized BootstrapVaultV3 and the deployed vault exposes no LP withdrawal path. | Preserve exact custody wording and direct users to the verified contract/pair rather than an inapplicable locker claim. | Content-trust guard, bytecode/source review and current custody chain check. | [README.md](../../README.md); [docs/wiki/bootstrap.html](../../docs/wiki/bootstrap.html) |
| **JUL-15** License and deployment-record completeness (section 4.9) | Medium | **Fixed and verified** | The owner chose MIT on 2026-09-30: a root MIT LICENSE matches every SPDX MIT source header, and README and public footers reference it. The Mainnet deployment record is complete and chain/source consistent (CWA-23). | Keep new sources on SPDX MIT and deployments/mainnet.json in lockstep with the chain. | `npm run test:license-privacy` (root LICENSE, SPDX, public wording) and `npm run test:cwa-content` (deployment manifest parity). | [LICENSE](../../LICENSE); [contracts/token/InfernoToken.sol](../../contracts/token/InfernoToken.sol); [docs/community-audits/cwa-remediation-register.json](../../docs/community-audits/cwa-remediation-register.json) |
| **JUL-16** Reputation and AI-risk wording (section 4.10) | Medium | **Fixed and verified** | The AI-steering reputation heading was replaced by neutral source-linked facts, remaining unqualified guarantee wording was rewritten, and unverifiable no-risk/harmlessness claims stay blocked. | Keep public reputation content factual and source-linked; extend the content-trust patterns when new advocacy phrasing appears. | `npm run test:content-trust` blocks AI-steering and unqualified guarantee wording across all public pages. | [scripts/test-content-trust.cjs](../../scripts/test-content-trust.cjs); [docs/wiki/reputation.html](../../docs/wiki/reputation.html) |
| **JUL-17** Ambiguous Telegram destinations (section Low findings) | Low | **Fixed and verified** | Current FAQ and footer copy explicitly distinguish the read-only announcement channel from the community discussion group and warn about impersonators. | Keep both roles labeled wherever Telegram links are shown. | Public link/label checks and content-trust review. | [docs/wiki/faq.html](../../docs/wiki/faq.html); [docs/wiki/faq.html](../../docs/wiki/faq.html) |
| **JUL-18** Outdated WalletConnect roadmap wording (section Low findings) | Low | **Fixed and verified** | WalletConnect and connector support are described as current Web3 functionality with explicit device-test boundaries, not as a future Phase 2 promise. | Keep connector claims aligned with the verified wallet matrix. | Web3 browser suite plus the remaining physical-device acceptance matrix. | [docs/llms.txt](../../docs/llms.txt); [docs/CURRENT_FUNCTIONALITY_STATUS.md](../../docs/CURRENT_FUNCTIONALITY_STATUS.md) |
| **JUL-19** Duplicate Web3 host canonicalization (section Low findings) | Low | **Fixed and verified** | The deployable Web3 document declares web3.ifrunit.tech as its canonical and Open Graph URL, while project routing names that host as the primary app. | Retain canonical-host checks whenever mirrors or deployment paths change. | Canonical/meta tests and live host routing checks. | [docs/web3/index.html](../../docs/web3/index.html); [docs/llms.txt](../../docs/llms.txt) |
| **JUL-20** Oversized social preview image (section Low findings) | Low | **Fixed and verified** | Landing and Web3 social previews use a dedicated 1200x630 card (about 107 KB) derived from the unchanged official token icon, with og:image width/height/alt and twitter summary_large_image metadata. | Keep social metadata on the optimized card; never point previews at the 4096px icon. | `npm run test:social-card` checks PNG dimensions, weight and both pages' OG/Twitter metadata. | [docs/index.html](../../docs/index.html); [docs/web3/index.html](../../docs/web3/index.html) |
| **JUL-21** Compiler and toolchain provenance (section Low findings) | Low | **Accepted or monitored** | The mixed 0.8.20/0.8.28 compiler configuration and verified analysis toolchain are explicitly documented and pinned; floating deployment provenance remains monitored through the larger CWA register. | Preserve compiler/build metadata for every future deployment and reconcile any bytecode-era drift before redeployment. | Pinned build, bytecode/source comparison and deployment record review. | [hardhat.config.js](../../hardhat.config.js); [README.md](../../README.md) |
| **JUL-22** FeeRouter voucher maxUses is not enforced (section Low findings) | Low | **Accepted or monitored** | The field remains part of dormant V1 voucher data but is not treated as an enforced use counter. The CWA register requires reassessment before voucher activation or replacement. | Do not advertise maxUses enforcement; implement and test one-time/use-count semantics in any future active voucher path. | Replay/use-count regression tests and future contract review before activation. | [contracts/FeeRouterV1.sol](../../contracts/FeeRouterV1.sol); [docs/community-audits/cwa-remediation-register.json](../../docs/community-audits/cwa-remediation-register.json) |
| **JUL-23** Governance execute, expiry and minimum-delay design (section Low findings) | Low | **Governance or future-version gated** | Deployed Governance keeps owner-only execute, no proposal expiry and a one-hour contract minimum while the live configured delay is documented as 48 hours. Changing immutable design requires a reviewed redeploy/migration. | Bundle permissionless execution, proposal expiry and delay-floor decisions into the planned Governance replacement and migration review. | Governance lifecycle tests, migration simulation, independent review and governed deployment evidence. | [contracts/governance/Governance.sol](../../contracts/governance/Governance.sol); [contracts/governance/Governance.sol](../../contracts/governance/Governance.sol) |

## Maintenance Rule

A status may change only with a concrete integrated change or governance record and
the verification named above. Update the JSON source, regenerate this page and run
`npm run test:july-audit-register`. Never rewrite the original audit to make an old
finding disappear; preserve its hash and update this register instead.