Armor RCA
Smart Contract Security Assessment
10.02.2022
![Ease](/audits/img/logos/ease.jpeg)
SUMMARY
ABSTRACT
Dedaub was commissioned to perform an audit on the Armor.fi RCA (reciprocally covered assets). The Armor.fi RCA protocol is a DeFi insurance protocol that has a novel funding model compared to previous versions of Armor. Rather than relying on insurers, or stakers to cover losses, the users of the system collectively cover other users in the event that a single protocol is hacked. Since hacks are long-tailed events it is expected that since there will be many many different pools
No Critical vulnerabilities were found, but two high vulnerabilities were found. The audit did not include OpenZeppelin library code, most notably the Merkle verifier and the Convex Shield. The audit applies to commit hash: 88bfc89d81e85a6c5d010654a4eec1120722984e.
The audit methodology involved careful review of (currently closed-source) sources, static analysis of compiled contracts and inspection of off-chain systems expected to interact with Armor RCA.
CENTRALIZATION ASPECTS
As is common in many new protocols, the maintainers of the smart contracts yield considerable power over the protocol. It is possible that some of these elements could evolve in the direction of decentralization in later versions of the protocol.
Governance (a timelocked DAO) - The power of the governance includes the ability to liquidate deposits on the protocol by setting the amounts to be liquidated for each shield. The protocol’s Governance can set many parameters that affect the user’s funds, namely the apr, discount, and withdrawal delay. The current DAO design allows for users to predict the governance actions. [Disclaimer: Dedaub has been previously commissioned to audit the Armor DAO contracts.]
Oracle (an EOA)- A centralized Oracle routinely sets the price for any asset.
Guardian (a multisig) - The “guardian” of the protocol can set the amount of funds that are paused (to be used following a hack) that directly affects withdrawals (see L3). When this happens, whoever withdraws their tokens loses a percentage (no current limits in code prevent it from reaching 100%) of the underlying tokens, but these are distributed to all other users after funds are un-paused.