Learn about Crypto, DeFi and ease.org DeFi cover
Print

ImmuneFi Bug Bounties

Note: Please submit all bugs here.

Program Overview

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 by Threat Level

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.

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.

 

Assets in Scope
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.
Prioritized Vulnerabilities
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
  • Oracle failure/manipulation
  • Novel governance attacks
  • Economic/financial 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

Out of Scope & Rules

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. More information about Armor can also be found on the Github Repo.

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.

Table of Contents
Scroll to Top