The MWC development team has completed an AI-driven code audit of the MWC node and the cryptographic and RPC libraries it depends on. The findings were addressed across two releases, and the work is now shipped. The audit was a hardening exercise: no consensus algorithm was changed, and the network's rules behave exactly as they did before.
What was audited
The review covered the full node and the libraries underneath it, rather than the node in isolation. That scope included:
- secp256k1-zkp and rust-secp256k1-zkp — the elliptic-curve and range-proof libraries that underpin Confidential Transactions
- easy-jsonrpc-mwc — the JSON-RPC layer
- mwc-node itself, crate by crate:
core,chain,keychain,store,pool,p2p,api,servers,config,util, and the node binary
Auditing the dependencies alongside the node matters, because the cryptographic primitives are where a silent arithmetic fault would be hardest to detect and most costly.
How it worked
An AI code review was run systematically across every crate, producing a set of findings for the team to triage. Each finding was then addressed by hand in the source, with the reasoning recorded against the specific file and function it applied to. The result is a detailed, file-by-file record published alongside the release rather than a summary judgment.
The review was deliberately broad rather than narrow. Instead of hunting for a single class of exploit, it examined every place where the code made an assumption that was not enforced — arithmetic that could overflow, conversions that could lose data, errors that were swallowed, and inputs that were trusted without validation.
What it found
Two issues recurred across nearly every crate, and together they account for the bulk of the changes:
- Possible data overflow. Arithmetic that could not be proven safe was switched to checked or saturating operations, so an overflow now produces a defined error instead of a silently wrong number.
- Unsafe type conversions. Conversions where data could be lost or altered were switched to checked conversions.
Beyond those two themes, the review drove a number of structural improvements:
- Errors are propagated rather than swallowed. Many functions became fallible, returning a
Resultinstead of panicking or continuing with a bad value. - Inputs are validated at boundaries. Deserialization of untrusted data was hardened throughout — strict boolean bytes instead of "any non-zero means true", explicit length checks, and rejection of trailing bytes after a structure is read.
- Sensitive data is cleared properly. In secp256k1-zkp, temporary buffers holding secret material are now wiped, and the code no longer relies on
memsetfor that purpose, since compilers are permitted to optimize it away in release builds. - Documented contracts match real behaviour. Function documentation that had drifted from the implementation was corrected, so the next reader is not misled.
- Test coverage was expanded. Regression tests were added for the newly defined error paths, and the fuzzing targets were updated to match the new signatures.
No consensus rules were changed
This is the most important point for node operators, miners and exchanges: the consensus algorithms are unchanged. The proof-of-work algorithms, the difficulty adjustment, and the 20,000,000 MWC emission schedule all behave exactly as they did before this work.
Consensus code was touched, but only to make existing behaviour explicit and safe. Arithmetic in the difficulty and reward paths now uses checked operations, and invalid parameters now produce a defined consensus error instead of an undefined result. Where the graph weight calculation was made fallible, the post-hard-fork weight behaviour and the existing expected weights were preserved exactly. Difficulty is now accumulated in a wider integer type and only saturates at the extreme, specifically so the chain stays live under conditions that would previously have overflowed.
One long-range correctness fix is worth naming. The block reward calculation previously allowed every fallback epoch beyond the last defined one to keep returning the final block reward. Epoch 12 now explicitly returns the last block reward, and all later epochs return zero. This does not alter emission anywhere on the published schedule; it makes the fixed 20,000,000 supply cap exact in code rather than depending on the schedule never being queried past its final epoch.
Performance and Tor
Because the added checks touched hot paths, the node's sync process was optimized to use all available CPU cores. The practical effect is that the extra safety does not cost sync time. CPU and memory footprint are broadly unchanged — the MWC node remains light enough to run comfortably on standard hardware.
Arti, the Rust implementation of Tor, was also upgraded to the latest version. Note that Tor is enabled by default. Miners who need a direct IP connection can disable it by setting tor_enabled = false under [server.tor_config] in mwc-node.toml.
Which version to run
The audit findings were addressed in 7.0.0, and 7.1.0 followed with fixes for several critical performance issues found in 7.0.0 along with additional audit findings.
Run 7.1.0. If you are currently on 7.0.0, upgrading is strongly recommended. If you are upgrading from a 6.x release, follow the migration instructions in the 7.0.0 notes first — they include a one-time permissions change that restricts the node data directory to owner-only access.
What's next
The same review process is now being applied to the MWC wallet. Those findings, and the releases that address them, will be published in the same way once that work is complete.
Links
- MWC Node 7.0.0 release: https://github.com/mwcproject/mwc-node/releases/tag/7.0.0
- Full 7.0.0 audit changelog: https://github.com/mwcproject/mwc-node/blob/master/doc/releases/release-7.0.0.md
- MWC Node 7.1.0 release (recommended): https://github.com/mwcproject/mwc-node/releases/tag/7.1.0
- Downloads: https://mwc.mw/downloads
