Skip to main content

HackenAI / $HAI

HackenAI (HAI Group / Hacken ecosystem) — 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).

HackenAI — a Security / Infra ecosystem around the HAI token (symbol: HAI) on Base (and a claimed multi‑chain presence).

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: an ecosystem of products and programs around the Hacken brand (web3 security/community/partner initiatives), where the HAI token is used as a “key” to utilities (staking/programs/access).
  • Who it’s for: users/holders participating in ecosystem activities; teams/startups interacting with programs/grants.
  • Why onchain/token: onchain here is primarily the token issuance and the operations associated with it (holding/staking/transfers); no proven “Decentralized AI” component was found.

How it works (very briefly)

  1. The user does: uses HAI and/or stakes the token (depending on the product).
  2. The system does: accrues rewards/access within the ecosystem utilities (staking, community programs, etc.).
  3. The user gets: access/referral bonuses/prizes/participation in activities (per the description on the website).
  4. Where the blockchain is: the HAI token is an ERC‑20 on the Base network; token operations are verifiable in the explorer.
  5. Token role (if any): a utility asset for ecosystem mechanics (staking/access/governance — per the project’s claim).

Quick links: AI thesis fit

Project passport

Field Value
Project name HackenAI / $HAI
Also known as (aliases) Hacken, HAI Group, $HAI, HAI
Logo (logo) ../assets/188_hackenai_logo.svg
Token symbol (ticker) HAI
Category Security | Infra
Primary chain (chain) Base
Type EVM
Network status mainnet
Consensus (consensus) L2 (Optimistic Rollup, Base on Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x7002987e5f63716273e77b51e12a578143c222aa
Token model (token_type) utility (governance)
Max supply 999,980,384.349232 HAI (Max Total Supply, BaseScan)
Issuance —
Tokenomics (tokenomics, brief) HAI is described as the “core token” of the ecosystem; the utilities include staking/real yield and participation programs
Governance hDAO (as claimed; details of onchain procedures not established per Tier‑1)
Admins/keys —
Audit —
Bug bounty yes (Hacken bug bounty services)
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI component not detected
Use‑case (use_case) ecosystem utility token (staking/access/programs)
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary 0 / 1 / 0 / 2
Last verified 2026-02-11

General project overview

On the hacken.ai pages, the $HAI token is described as the “core token” of the HAI Group ecosystem, which brings together a number of utilities (staking/real yield, participation programs, grant initiatives, etc.). On BaseScan the token is displayed as an ERC‑20 (proxy contract).

At the same time, despite the historical name “HackenAI”, in the available Tier‑1 materials no description of the AI component in the sense of “AI model/inference/metrics/architecture” was found. Therefore, per the DecAIHub methodology, this does not confirm AI reality.

Features/modules

  • hAI App: a “hub” application for managing assets/rewards (per the description on the website).
  • Real Yield / staking: claimed rewards for staking HAI within the ecosystem products (description on the website).
  • Community / quests / programs: community activities and participation programs (per the links on the website).
  • Bug bounty: as part of the Hacken business/ecosystem (service page).

Typical scenarios

  • Scenario 1: a user stakes/uses HAI in the ecosystem → receives rewards/access.
  • Scenario 2: a community member performs activities (quests/programs) → receives rewards in HAI (claimed as one of the ways to “earn”).

Getting started (wallet/network)

  • What you need: an EVM wallet and the Base network for onchain operations with HAI.
  • Network/chain: Base.
  • Fees: Base gas.

Architecture/tech (non‑AI)

  • Components: the HAI ERC‑20 token (proxy), ecosystem applications/websites.
  • Where logic runs: onchain — token transfers/balances; the product logic of the ecosystem utilities, judging by the description, is largely offchain (applications/services).

Token/economics (expanded, no forecasts)

  • Token utility: HAI is positioned as an “ecosystem token” with access to utilities and rewards (Tier‑1: tokenomics/whitepaper pages).
  • Issuance/burn: not established per Tier‑1 (apart from the Max Total Supply fact on BaseScan).

Governance

  • Who makes decisions: “Decisions are made by hDAO” is claimed (whitepaper/tokenomics page), but the details of the governance process are not verified.

Security and incidents

  • Bug bounty: the Hacken bug bounty service page is listed.
  • Token audits: no public Tier‑1 audit reports for the HAI contract were found.

Project status and timeline

  • Current status: the website and tokenomics pages are active; the token exists on Base.

AI component of the project

  • What is real AI here? Per the available Tier‑1 sources, the AI component as a product technology is not confirmed (there is the “hAI” brand/naming, but without a technical description of an AI model).
  • What is truly onchain? the HAI ERC‑20 token on Base.
  • Why is a token needed? ecosystem utility (staking/programs/access) — per the project’s claim.
  • Red flags (based on the information found): AI‑washing (the “AI” name/marketing without technical artifacts); onchain‑washing (if “onchain” boils down to the token).

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 partially present 2
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): no Tier‑1 intent about AI as a separate module/roadmap was found.
  • Evidence: Tier‑1 — https://hacken.ai/tokenomics.pdf
  • Why sufficient / why not (one line): “hAI” is used as branding/the application name, but this is not a roadmap of an AI component.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): it is not described what exactly an AI model/inference does as part of the product.
  • Evidence: Tier‑1 — https://hacken.ai/tokenomics.pdf
  • Why sufficient / why not (one line): there is no description of a model/inference/metrics.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): no demo of an AI component was found.
  • Evidence: Tier‑1 — https://hacken.ai/whitepaper
  • Why sufficient / why not (one line): the pages describe the ecosystem and the token utilities, but not an AI demo.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://hacken.ai/whitepaper
  • Why sufficient / why not (one line): there are no metrics of an AI module.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): the AI architecture/model versions are not described.
  • Evidence: Tier‑1 — https://hacken.ai/whitepaper
  • Why sufficient / why not (one line): there is no technical description of an AI model.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base
  • Addresses/identifiers: HAI 0x7002987e5f63716273e77b51e12a578143c222aa
  • Evidence: Tier‑1 — https://basescan.org/token/0x7002987e5f63716273e77b51e12a578143c222aa
  • Why sufficient / why not (one line): BaseScan records the contract and the basic parameters of the token.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: apart from the token, no confirmed onchain logic was found.
  • Evidence: Tier‑1 — https://hacken.ai/tokenomics.pdf
  • Why sufficient / why not (one line): descriptions of “protocol contracts/accounting of contributions/onchain rules” are absent.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the ecosystem utilities could work with centralized accounting; there is no strict proof of onchain criticality.
  • Evidence: Tier‑1 — https://hacken.ai/whitepaper
  • Why sufficient / why not (one line): onchain criticality is not described.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, HAI.
  • Evidence: Tier‑1 — https://basescan.org/token/0x7002987e5f63716273e77b51e12a578143c222aa
  • Why sufficient / why not (one line): the token contract and ticker are visible in the explorer.
  • 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): no mandatory payment for services specifically in HAI was found in Tier‑1.
  • Evidence: Tier‑1 — https://hacken.ai/tokenomics.pdf
  • Why sufficient / why not (one line): the text focuses on “access/utility/yield”, without a strict “X is paid for with the token”.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): HAI is used for staking/rewards (real yield).
  • Evidence: Tier‑1 — https://hacken.ai/tokenomics.pdf
  • Why sufficient / why not (one line): HAI staking and “real yield” are described as a utility.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): hDAO is mentioned, but the mechanism of governance with the token (how they vote, what they change) is not confirmed in Tier‑1 sources as a specific process.
  • Evidence: Tier‑1 — https://hacken.ai/whitepaper
  • Why sufficient / why not (one line): without specifics of the governance mechanics, we set 0.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): the access/loyalty/staking functions could also be implemented via other mechanics; there is no proof of the token’s irreplaceability.
  • Evidence: Tier‑1 — https://hacken.ai/tokenomics.pdf
  • Why sufficient / why not (one line): there is no strict argument “it does not work without the native token”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://basescan.org/token/0x7002987e5f63716273e77b51e12a578143c222aa the HAI token contract on Base, decimals, max total supply
Tier‑1 https://hacken.ai/tokenomics.pdf positioning of HAI as the core token of the ecosystem and its utilities (staking/real yield, etc.)
Tier‑2 https://www.coingecko.com/en/coins/hackenai reference profile

No comments to display

Back to top