Armor is a smart insurance aggregator for DeFi which provides Pay as You Go and Only Pay What You Owe ᴰᵀᴹ coverage for user funds across various protocols. Underwritten by Nexus, Armor evolves digital asset insurance from static chunks of coverage toward dynamic risk management customized to client demands and circumstances. Instead of sticking to a fixed amount, a set timeframe, and expiration date, all of these inputs can be dynamically recommended and modified at any time.
The bug bounty program is focused around its smart contracts used actively in live products on mainnet.
Verification of Armor’s bug bounty program on Immunefi is available at https://armorfi.gitbook.io/armor/developers/bug-bounties/immunefi-bug-bounty
Rewards are distributed according to the exploitability level of the vulnerability and its impact based on the Immunefi Vulnerability Severity Classification System. The listed rewards represent the maximum that will be paid out for a security bug reporting.
up to $1,150,000
Payouts are handled by the Armor team directly and are denominated in USD. However, payouts are done in ETH or ARMOR and take place according to a vesting schedule.
This bug bounty applies to all smart contracts used actively in live products on mainnet. All code can be found at https://github.com/ArmorFi.
Armor is especially interested in receiving and rewarding vulnerabilities of the following types:
Including user authentication errors
Solidity/EVM details not considered
Including integer over-/under-flow
Including unhandled exceptions
Trusting trust/dependency vulnerabilities
Including composability vulnerabilities
Novel governance attacks
Including flash loan attacks
Congestion and scalability
Including running out of gas
Including block stuffing
Including susceptibility to frontrunning
Susceptibility to replay attacks
Susceptibility to block timestamp manipulation
Missing access controls / unprotected internal or debugging interfaces
The following vulnerabilities are excluded from the rewards for this bug bounty program:
Attacks that the reporter has already exploited themselves, leading to damage
Attacks that rely on social engineering
Attacks requiring access to leaked keys/credentials
Incorrect data supplied by third party oracles
Not to exclude oracle manipulation/flash loan attacks
Basic economic governance attacks (e.g. 51% attack)
Lack of liquidity
Best practice critiques
The following activities are prohibited by bug bounty program:
Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
Any testing with pricing oracles or third party smart contracts
Attempting phishing or other social engineering attacks against our employees and/or customers
Any testing with third party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
Any denial of service attacks
Automated testing of services that generates significant amounts of traffic
Disassembly or reverse engineering of binaries for which source code is not published, not including smart contract bytecode
Public disclosure of an unpatched vulnerability in an embargoed bounty
There is usually a description of the contract and main functions in the readme contained in the GitHub Repos linked to in the left panel under DEVELOPER RESOURCES. More information about Armor can also be found on its Gitbook.
Rewards will only be given to the bounty hunter that first submits the bug. The classification and reward given for any bug will be based on the Immunefi Vulnerability Severity Classification System, but at the sole discretion of the token holders or Armor team.
We have compiled a list of examples to complement the severity classification system in order to make things clearer:
Low - A low severity bug, for example, may be the contract not applying to standards in a non-threatening way (such as there not being a total supply), or an external getter function not working correctly.
Medium - Bugs that lead to a small (but non-negligible) loss of funds or a loss of funds in extreme edge cases.
High - Exploits that leads to a severe loss of user funds that require a re-deployment of the contract or an upgrade.
Critical - An exploit in which more than $1m in user funds can be lost or an exploit that allows the contract to become permanently disabled.