ArmorFi

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.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System. This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

Payouts are handled by the Armor team directly. The payouts are based on and completed in ARMOR or USDC as specified in the table and take place according to a vesting schedule of up to 24 months. A USD estimate of the current value of the token is provided for reference. Estimates are updated regularly, but should not be relied on.

This bug bounty applies to all smart contracts used actively in live products on mainnet.

Armor is especially interested in receiving and rewarding vulnerabilities of the following types:

Smart Contracts/Blockchain:

• Re-entrancy
• Logic errors
  • Including user authentication errors
• Solidity/EVM details not considered
  • Including integer over-/under-flow
  • Including unhandled exceptions
• Trusting trust/dependency vulnerabilities
  • Including composability vulnerabilities
• Oracle failure/manipulation
• Novel governance attacks
• Economic/financial attacks
  • Including flash loan attacks
• Congestion and scalability
  • Including running out of gas
  • Including block stuffing
  • Including susceptibility to frontrunning
• Consensus failures
• Cryptography problems
  • Signature malleability
  • Susceptibility to replay attacks
  • Weak randomness
  • Weak encryption
• 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
• Sybil attacks

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

Other Notes

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 https://armorfi.gitbook.io/armor/

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 risk rating system (above), 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. In the event of a discrepancy, the following classification will prevail.

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 all user funds can be lost or an exploit that allows the contract to become completely disabled.