.svg)
About Mezzanine Finance
Mezzanine Finance is a governance-operated structured-credit style system built on top of USDCand the internal accounting token MZUSD . IssuanceVault acts as the treasury and epochcoordinator, MZUSD provides the mint/redeem gateway, and the tranche layer concentrates liquidity,yield accrual, and loss realization into differentiated risk tranches.
Summary
The most critical subjects covered in our audit are asset accounting, yield and loss routing, redemption and liquidity liveness, privileged access control, and pause-dependent system behavior. Security regarding all the aforementioned subjects is good, based on the validity of the providedassumptions and specifications.
Representative pause-dependent examples include the couplingdescribed in Findings under A Single Paused Tranche Can Block Global Yield and Loss Processing.The general subjects covered are upgradeability, automation and epoch liveness, documentation and specification quality, and consistency of accounting-related implementation details. Security regarding all the aforementioned subjects is also satisfactory. However, the system includes several economically non-obvious design choices whose safety depends less on technical enforcement than on clear product intent, correct operator behavior, and user understanding of the resulting incentives and tradeoffs, as reflected for example in System Considerations under Spot AllocationAllows Late Capital to Participate in Epoch Yield and Yield Allocation Uses a Hard Zero-TVL Cutoff.
The main security assumptions are not purely technical. They depend materially on honest governance, correct oracle-operated NAV reporting, safe upgrade operations, reliable pause management, and sufficient USDC liquidity in the vault-reservoir system. Several system considerations and issues identified during the review concern behaviors that are unusual enough that, absent clarification, they would likely have warranted a higher severity assessment. These include losses still applying to disabled tranches, users being able to participate in yield without having carried the corresponding historical economic exposure, direct-withdraw users being able to avoid later loss application, and very small tranche TVL still receiving substantial premium-weighted yield allocation. Examples are discussed in System Considerations under Disabled Tranches Remain in the Loss Path, User Can Evade Loss Report with Immediate ExitsEnabled, and Yield Allocation Uses a Hard Zero-TVL Cutoff.
During the review, the development team clarified that these behaviors are intended consequences of the current product design. We therefore treated them primarily as system considerations or informational concerns rather than as higher-severity implementation flaws. All issues raised have been addressed and the communication was always professional.
In summary, we find that the codebase provides a good level of security, but that its risk profile depends materially on governance and operator honesty, oracle correctness, pause and automation liveness, and a clear understanding of the intended economic behavior. It is important to note that security audits are time-boxed and cannot uncover all vulnerabilities. They complement but don't replace other vital measures to secure a project.