> For the complete documentation index, see [llms.txt](https://mzf-protocol.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mzf-protocol.gitbook.io/whitepaper/overview/compliance-and-regulatory-considerations/security-and-smart-contract-audit.md).

# Security & Smart Contract Audit

Security is paramount to MZF PROTOCOL’s mission as a capital-efficient payment protocol operating in the DeFi space. Given the inherent risk vectors in Web3 systems, MZF PROTOCOL has engaged Hashlock, a leading blockchain security firm, as our primary audit partner to ensure a robust, verifiable security posture from day one.

### Hashlock

Hashlock is a specialised Web3 security firm known for deep smart contract expertise, a rigorous audit methodology, and a strong track record across DeFi, NFT infrastructure, and payment protocols. Their approach combines manual line-by-line contract reviews, formal verification, and fuzzing/simulation tools to expose both common and advanced vulnerabilities before mainnet deployment.

#### Past Audit Engagements 

Hashlock’s prior audits have included:

* Balancer (V2 pool contracts);
* Redacted Cartel;
* Spool.fi;
* zkSync ecosystem projects; and 
* Custom rollup infrastructure and cross-chain bridges. 

These past engagements reflect both depth in DeFi primitives and versatility across complex, modular systems — aligning strongly with MZF PROTOCOL’s smart contract architecture.

#### MZF PROTOCOL Audit Timeline

* Pre-Deployment Audit (In Progress): Hashlock will audit MZF’s core protocol contracts, including our staking logic, payment flows, vesting mechanics, and treasury controls. The public audit report will be published in the MZF docs and GitHub repo prior to TGE.\ <br>
* Post-Deployment Monitoring (Planned): Hashlock will retain a retainer-based relationship for post-launch upgrades, including any protocol migrations, changes to staking logic, or DAO governance integrations

### DeFi Security Best Practices

MZF’s architecture adheres to the most established best practices in DeFi contract development:

* Modular and upgradeable smart contracts, isolated by purpose (e.g., staking logic, payment channels, and treasury allocation).
* Access controls implemented via OpenZeppelin’s Ownable and AccessControl modules.
* Pauseable functionality to allow emergency stops of non-critical functions (i.e., staking, payment execution).
* Upgrade security via proxy patterns with timelocked governance, audit trails, and signer quorum requirements.
* Non-custodial structure: User funds remain in their own wallets unless explicitly interacting with protocol contracts.

### Common DeFi Attack Vectors Addressed

MZF explicitly mitigates the following well-known DeFi vulnerabilities:

* Reentrancy: All external calls follow the checks-effects-interactions pattern, with relevant functions protected by nonReentrant modifiers. Reentrancy guards are placed on all key vault, staking, and fund-handling functions.
* Oracle Manipulation: Price oracles (if used in future products) will rely on time-weighted average prices (TWAPs) from reputable sources like Chainlink, Uniswap V3, or Pyth, with on-chain bounds checking and fallback logic.
* Flash Loan Attacks: Functions with economic implications (e.g., payment routing, staking yield calculations) are restricted from being called within the same block as state-altering events, minimising flash exploit windows.
* Integer Overflows/Underflows: All contracts use Solidity 0.8.x, which includes built-in overflow and underflow checks.
* Access Control Misconfigurations: Role-based access is implemented using granular roles (e.g., PAYMENT\_ADMIN, TREASURY\_ADMIN, STAKING\_OPERATOR) and guarded via onlyRole() or hasRole() checks. No externally callable admin functions are left exposed without strict controls.
* Front-running & MEV: Core transactions (especially those tied to token vesting, yield harvesting, or automated treasury flows) are designed to be non-profitable for MEV exploitation via slippage checks, TWAP price limits, and restricted access.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://mzf-protocol.gitbook.io/whitepaper/overview/compliance-and-regulatory-considerations/security-and-smart-contract-audit.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.