Skip to main content

Immunefi

Immunefi — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Immunefi — an Infra | Security project: an “onchain security operations” platform (bug bounty, audits, monitoring etc.) and related programs/tools; the IMU token is described as the ecosystem token of Security OS.

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a platform for protecting web3 protocols: bug bounty programs, audits/audit competitions, monitoring, and other elements of “security ops”.
  • Who it’s for: protocol/project teams that need a full cycle of security operations, and security researchers (whitehats) who find vulnerabilities and receive payouts.
  • Why onchain/token: onchain is the threat domain (contracts/transactions/incidents) being protected; the IMU token is described as a mechanism for ecosystem incentives/participation in Security OS (details — in Tier‑1 documents).

How it works (very briefly)

  1. The user does: a project connects Immunefi products (for example, bug bounty/audit/monitoring), or a researcher selects a program and submits a report.
  2. The system does: provides coordination processes for disclosure/triage/payouts, as well as monitoring and code/transaction review services (per the product line).
  3. The user gets: projects — risk reduction and vulnerability handling; researchers — payouts for bugs found.
  4. Where the blockchain is: the verifiable onchain artifact is the IMU token (ERC‑20) on Ethereum; the protection domain is clients’ onchain contracts and their activity.
  5. Token role (if any): IMU is described as the ecosystem token of Security OS, intended to strengthen incentives/signals and train Immunefi AI (claimed).

Quick links: AI thesis fit

Project passport

Field Value
Project name Immunefi
Also known as (aliases) IMU
Logo (logo) ../assets/903_immunefi_logo.svg
Token symbol (ticker) IMU
Category Infra | Security
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0xb48c6b24f36307c7a1f2a9281e978a9ef2902ba5
Token model (token_type) unknown
Max supply 10 000 000 000 IMU
Issuance —
Tokenomics (tokenomics, brief) Allocation: 10B IMU (described on the foundation website); max total supply 10B is confirmed by the token’s onchain page.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) security agents / Immunefi AI for on-chain security
Use‑case (use_case) security ops for protocols + bug bounty
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary ai_score 0 / onchain_score 1 / token_score 0 / evidence_score 3
Last verified 2026-02-11

General project overview

Per Tier‑1 sources, Immunefi is positioned as a platform for “unified security operations” in web3: bug bounty programs, audits, monitoring, code and transaction review etc. The product targets protocols/teams (as clients) and security researchers (whitehats) who find vulnerabilities and receive payouts through programs.

Separately, Immunefi Foundation and the documentation describe the IMU token as the central asset of the Security OS ecosystem: the token is intended to structure incentives, accumulate signals, and (claimed) fuel the training of Immunefi AI on threat/exploit data.

Features/modules

  • Bug bounty programs: program catalogs, disclosure rules, and payouts (via the platform).
  • Audits / Audit competitions: outsourcing/competitions to find vulnerabilities.
  • Monitoring / threat detection: monitoring of onchain risks (as a product line).
  • Code review agent / Multisig Tx Review: review services (as a product line).

Typical scenarios

  • Scenario 1 (protocol): a team launches a bug bounty → receives reports → triage/remediation → payouts.
  • Scenario 2 (researcher): a researcher selects a program → finds a vulnerability → reports it → receives a payout.
  • Scenario 3 (ops): a team connects monitoring/transaction/code review as part of its security stack.

Getting started (wallet/network)

  • What you need: an account/access to the Immunefi platform (to participate in programs) and, if necessary, the project’s onchain infrastructure.
  • Network/chain: depends on the protocols being protected; the IMU token is deployed as ERC‑20 on Ethereum.
  • Fees: depend on specific onchain operations outside the platform; not recorded within this card.

Architecture/tech (non‑AI)

  • Components: bug bounty/audit/monitoring coordination services; user interfaces for protocols and researchers.
  • Where logic runs: most of it — offchain (platform/processes); the onchain part consists of clients’ assets/contracts and the ecosystem token.

Token/economics (expanded, no forecasts)

  • Parameters (Tier‑1): max total supply 10B IMU (confirmed onchain and by the foundation page).
  • Token role (Tier‑1, claimed): incentives and a “security flywheel” around data/signals that strengthen Security OS.
  • What is not established: detailed “payment/collateral/slashing” mechanics in the form of specific contracts/parameters.

Governance

  • Not established per Tier‑1: a specific governance process/voting mechanics via IMU (if any).

Security and incidents

  • Bug bounty (for projects): the core product (see links_*).
  • Audits: available as a product (see links_*).
  • Incidents: not recorded in this card without a separate Tier‑1 source/postmortem.

Project status and timeline

  • Current status: the platform is active and publicly accessible.

AI component of the project

  • What is real AI here? Immunefi claims “security agents” and “Immunefi AI”, trained on a dataset of exploits/reports/fixes; however, Tier‑1 artifacts (public metrics/tech description/code) to confirm AI reality are not recorded.
  • What is truly onchain? the threat domain is onchain protocols; the verifiable artifact is the IMU token (ERC‑20) on Ethereum.
  • Why is a token needed? the IMU token is described as an element of incentives and the “security flywheel” around Security OS (Tier‑1, claimed).
  • Red flags (based on the information found): the AI part is currently described as “claimed”; without technical artifacts (metrics/architecture/public code), AI_1..AI_4 remain 0.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality low 0
Onchain necessity low 1
Token necessity low 0
Evidence Tier‑1 absent 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): Mentions of “Immunefi AI” are present in Tier‑1 product materials, but as intent/marketing positioning, without verifiable artifacts.
  • Evidence: Tier‑1 — https://immunefi.com/ ; https://www.immunefi.foundation/
  • Why sufficient / why not (one line): AI_0 requires a Tier‑1 roadmap/declaration of AI intentions; here AI appears as a product thesis without a formal roadmap artifact.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): What exactly the AI component does and how it is integrated into the product (in a verifiable form) are not established per Tier‑1.
  • Evidence: Tier‑1 — https://immunefi.com/
  • Why sufficient / why not (one line): Tier‑1 artifacts (docs/code/demo) describing the AI feature are required.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): A demo of “Immunefi AI” in operation as a verifiable Tier‑1 artifact is not recorded.
  • Evidence: Tier‑1 — https://immunefi.com/
  • Why sufficient / why not (one line): Without a Tier‑1 link to a demo, AI_2 remains 0.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://immunefi.com/
  • Why sufficient / why not (one line): Quality metrics are not recorded per Tier‑1.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): A technical description of the AI part (architecture/versions/artifacts) is not recorded per Tier‑1.
  • Evidence: Tier‑1 — https://docs.immunefi.foundation/
  • Why sufficient / why not (one line): Tier‑1 docs/repo with an architecture or description are required.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: IMU token (ERC‑20): 0xb48c6b24f36307c7a1f2a9281e978a9ef2902ba5
  • Evidence: Tier‑1 — https://etherscan.io/token/0xb48c6b24f36307c7a1f2a9281e978a9ef2902ba5
  • Why sufficient / why not (one line): The token contract address on a public network is a verifiable onchain fact.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 0
  • What useful logic is onchain: —
  • Evidence: Tier‑1 — https://docs.immunefi.foundation/
  • Why sufficient / why not (one line): Without a Tier‑1 description of protocol logic, OC_2 cannot be confirmed.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: —
  • Evidence: Tier‑1 — https://docs.immunefi.foundation/
  • Why sufficient / why not (one line): Onchain criticality requires formal justification and sources.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, IMU.
  • Evidence: Tier‑1 — https://docs.immunefi.foundation/ ; https://etherscan.io/token/0xb48c6b24f36307c7a1f2a9281e978a9ef2902ba5
  • Why sufficient / why not (one line): Tier‑1 sources confirm the existence of the token and the onchain contract.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): It is not established per Tier‑1 that IMU is mandatory as “payment for the service” (in the protocol sense).
  • Evidence: Tier‑1 — https://docs.immunefi.foundation/
  • Why sufficient / why not (one line): TK_1 requires an explicit Tier‑1 description of the fee mechanism.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): No specific protocol mechanics of incentives/collateral/penalties (contracts/parameters) are recorded per Tier‑1, beyond the general “flywheel” principles.
  • Evidence: Tier‑1 — https://docs.immunefi.foundation/
  • Why sufficient / why not (one line): “1” requires specific rules/parameters and verifiable artifacts.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): Governance mechanics via IMU are not established per Tier‑1.
  • Evidence: Tier‑1 — https://docs.immunefi.foundation/
  • Why sufficient / why not (one line): “1” requires a described governance process.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability of the token is not assessed without Tier‑1 data.
  • Evidence: Tier‑1 — https://docs.immunefi.foundation/
  • Why sufficient / why not (one line): Tier‑1 data on the role of the token in the protocol is required.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://immunefi.com/ The platform’s product line (bug bounty/audits/monitoring etc.) and the description of “security agents / Immunefi AI” as positioning.
Tier‑1 https://www.immunefi.foundation/ Description of Security OS and the IMU token (allocation 10B; “security flywheel”).
Tier‑1 https://docs.immunefi.foundation/ IMU documentation: the role of the token and “flywheel” principles.
Tier‑1 https://docs.immunefi.foundation/mica-whitepaper/ MiCA whitepaper (PDF) as a Tier‑1 document on the token/risks/role in the ecosystem.
Tier‑1 https://etherscan.io/token/0xb48c6b24f36307c7a1f2a9281e978a9ef2902ba5 Onchain fact: the IMU token contract on Ethereum; max total supply 10B.
Tier‑2 https://coinmarketcap.com/currencies/immunefi/ Aggregator profile (context).
Tier‑2 https://www.coingecko.com/en/coins/immunefi Aggregator profile (context).

No comments to display

Back to top