4Mica lets a payer back payments with collateral. The recipient gets a BLS-signed guarantee that the collateral covers the payment, and the money moves later, when obligations are netted and settled in periodic cycles. Users deposit ETH or approved stablecoins into a vault contract, and the stablecoins earn yield on Aave in the meantime. An off-chain operator issues the guarantees and builds each settlement cycle. On chain, a ClearingHouse contract collects from debtors, seizes collateral from anyone who defaults, and credits the creditors.
ATM Labs asked us to audit 4Mica’s cryptography and software security, covering the Rust operator service, the Solidity contracts, and the sign-in and signing code in the Rust SDK. Section 2.2 of the report lists exactly what was in scope. Today we’re publishing the report, 4MCA-01.
Download 4MCA-01 (PDF, 54 pages)
The cryptographic core is correct. 4Mica’s BLS implementation matches the on-chain verifier byte for byte, and settlement netting is zero-sum. We compared every constant and encoding that Rust and Solidity both define, and only one struct disagreed, on a verification path 4Mica had already deprecated.
The serious problems were in settlement. A committed cycle could end only in full success. If a single collateral seizure failed, the cycle could not finalize, and every creditor in it waited until an operator intervened (4MCA-H06). A TODO comment in the contract already acknowledged the gap. A seizure could fail in more than one way. If Aave lacked the liquidity to pay out a debtor’s stablecoins, the seizure had to wait, and a shortage that outlasted the withdrawal grace period could let the debtor withdraw first and make the loss permanent. A rounding boundary in the yield fee could also make the seizure underflow and revert; in our integer model of the contract, 5% of yield states failed at a 5% fee.
The second group of findings is about keys. The ClearingHouse checked that a cycle’s totals balanced, but not that its Merkle root matched obligations anyone had signed, so whoever held the operator key could commit a fabricated cycle and move any user’s collateral to an account they controlled (4MCA-H01). The AccessManager admin key had a shorter route: it could grant itself the role that seizes collateral (4MCA-H02). Both keys were externally owned accounts with execution delays but no multisig. A delay makes a malicious action visible before it runs, but the single key keeps the same authority.
The report has 24 findings: nine High, seven Medium, seven Low and one Informational. Others include a reorg that could credit an ETH deposit twice under a non-default scanner setting, and an endpoint that let any signed-in wallet read another user’s balance. Some ratings depend on production settings the 4Mica team confirmed for us, such as the yield fee, which was enabled, and the V2 guarantee flow, which was not. 4Mica has fixed all 24, and the report links each finding to its pull request.
If you are designing a system like this and want these questions asked early, get in touch.