Skip to main content

HashAI

HashAI — 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).

HashAI — an AI/Compute | Infra project that claims AI optimization of crypto mining (selecting the “most profitable” coins in real time and auto‑tuning rigs) and products around rigs/nodes (including a community share pool). Token: HASHAI (ERC‑20 on Ethereum).

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 token + dApp mechanic where holders deposit the token and receive rewards (in ETH) from a “community share pool” model; in parallel, the project sells/rents “nodes/supercomputers” (per the docs).
  • Who it’s for: token holders and participants of the reward mechanic; potential clients of compute/node rental.
  • Why onchain/token: the token is the unit of participation in pools/the reward mechanic; the onchain layer records the token and deposit/claim transactions.

How it works (very briefly)

  1. The user does: deposits HASHAI into the Share Pool during the “Deposit Phase”.
  2. The system does: holds the deposit for 28 days; during the “Withdrawal Phase” it allows claiming ETH rewards and/or withdrawing the tokens (early withdrawal — with a 15% fee).
  3. The user gets: an ETH reward and the tokens back after the pool period.
  4. Where the blockchain is: HASHAI is an ERC‑20 on Ethereum; claims/withdrawals are executed as onchain transactions via the dApp.
  5. Token role (if any): the “weight” of participation in the share pool (a larger deposit → a higher reward) and access to the project’s product economy.

Quick links: AI thesis fit

Project passport

Field Value
Project name HashAI
Also known as (aliases) Hash AI; HASHAI
Logo (logo) ../assets/139_hashai_logo.png
Token symbol (ticker) HASHAI
Category AI/Compute | Infra
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 0x292fcdd1b104de5a00250febba9bc6a5092a0076
Token model (token_type) utility (staking + rewards)
Max supply 100,000,000,000 HASHAI (Max Total Supply on Etherscan)
Issuance capped supply (per Etherscan)
Tokenomics (tokenomics, brief) share pool: a 28-day deposit; early withdrawal fee 15%; rewards are paid in ETH (per the docs)
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI optimization of coin selection/mining settings
Use‑case (use_case) mining optimization + rewards pool
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 1 / 0 / 3
Last verified 2026-02-05

General project overview

In Tier‑1 sources, HashAI describes the task as mining optimization: manually switching between coins/pools is “inefficient”, so the project claims “advanced algorithms” that analyze the market and select the most profitable coins in real time, automatically tuning the rigs.

The publicly verifiable part at the documentation level is primarily the HASHAI token on Ethereum and the user mechanics around it (e.g., the Share Pool with ETH rewards). There is no public technical description of specific AI models/architecture/metrics in the available Tier‑1 sources.

Features/modules

  • Community Share Pool: a 28-day deposit of HASHAI and claiming ETH rewards during the withdrawal phase window.
  • Node rental & lending / compute: the docs claim “supercomputer/node” rental and use cases (render/AI computing/IoT).
  • Mining optimization (claim): positioning of the project as an AI mining optimizer.

Typical scenarios

  • Scenario 1 (share pool participant): deposits HASHAI into the pool → after 28 days claims ETH and withdraws the tokens.
  • Scenario 2 (early withdrawal): withdraws the deposit early → pays a 15% fee (per the docs).
  • Scenario 3 (compute client): is interested in renting nodes/compute (described in the docs as a product direction).

Getting started (wallet/network)

  • What you need: an EVM wallet and HASHAI; for the Share Pool — connecting the wallet to the dApp (link in the docs).
  • Network/chain: Ethereum (ERC‑20 token).
  • Fees: Ethereum gas for transfers/deposits/claims.

Architecture/tech (non‑AI)

  • Components: the ERC‑20 token HASHAI; a dApp for the Share Pool; mining/node infrastructure (per the description on the website/docs).
  • Participant roles: token holders, Share Pool participants, operators of the project’s infrastructure.
  • Where logic runs: AI optimization and mining — offchain; token ownership accounting/transactions — onchain (Ethereum).
  • Dependencies: Ethereum (wallets, RPC, explorer), the web dApp.

Token/economics (expanded, no forecasts)

  • Token utility: participation in the Share Pool and receiving ETH rewards; the “weight” of the deposit affects the reward.
  • Protocol necessity drivers: the Share Pool requires a deposit of HASHAI.
  • Who pays fees: users pay Ethereum gas for deposits/claims/withdrawals.
  • Where fees go: early withdrawal is subject to a 15% fee (the purpose of the fee is not explicitly spelled out in the docs).
  • Issuance/burn: Etherscan shows a Max Total Supply of 100B HASHAI; there are no inflation parameters.
  • Security/incentive mechanisms: a 28-day lock; deposit/withdrawal phase windows; rollover of unclaimed ETH rewards to the next pool.
  • Distribution and token issuance schedule: — (Tier‑1 sources within this card contain no allocation/vesting table).
  • Treasury: —.

Governance

  • Who makes decisions: —.
  • How protocol parameters change: —.
  • Where decisions are discussed/made: —.
  • Keys/multisig: —.

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: smart contract/pool risks (if applicable), risks of centralization of the offchain mining infrastructure and of reward distribution.

Project status and timeline

  • Current status: active (the website and docs are available; the token exists on Ethereum).
  • Key releases/milestones: —.
  • Roadmap: the website has a roadmap block (without dates/versions as a Tier‑1 artifact).

Ecosystem/integrations

  • Integrations: Ethereum (ERC‑20), the dApp dapp.hashai.co.uk, the Etherscan token profile.
  • Partners: —.
  • Where it’s actually used: Tier‑1 confirms the Share Pool mechanics (docs) and the existence of the token/profile (Etherscan).

AI component of the project

  • What is real AI here? the project claims AI algorithms for mining optimization (coin selection/rig tuning) — without public metrics and technical details.
  • What is truly onchain? the HASHAI token (ERC‑20) and the related deposit/claim/withdrawal transactions in the dApp.
  • Why is a token needed? participation in the “share pool” and calculation of the reward share.
  • Red flags (based on the information found): AI‑washing (no technical details/demos/metrics specifically for the AI part), token‑washing (the token mechanic resembles “membership + rewards” and is potentially replaceable). Double‑check: the addresses/contracts of the pools, the sources of yield and the rules of rewards distribution.

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low 1
Onchain necessity low 1
Token necessity low 0
Evidence Tier‑1 present 3
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): AI is claimed as part of a working product (mining optimization), so we do not classify it as “intent only”.
  • Evidence: Tier‑1 — https://hashai.co.uk/
  • Why sufficient / why not (one line): there is a description of the AI function, so this is more than a roadmap intent.
  • Conflict note (if any): —.

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): AI algorithms analyze the markets, select the most profitable coins and “automatically tune the rigs”.
  • Evidence: Tier‑1 — https://hashai.co.uk/
  • Why sufficient / why not (one line): there is an explicit description of the function of the AI part (albeit a marketing one).
  • Conflict note (if any): —.

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): no public demo of the “AI optimization” specifically (logs/an example of switching/comparisons) was found.
  • Evidence: Tier‑1 — https://hashai.co.uk/
  • Why sufficient / why not (one line): there is a dApp for the pool, but it does not demonstrate the operation of the AI algorithms.
  • Conflict note (if any): —.

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —.
  • Context (version/date/how measured): —.
  • Evidence: Tier‑1 — https://hashai.co.uk/
  • Why sufficient / why not (one line): there are no quantitative metrics of the effectiveness of the AI optimization in Tier‑1.
  • Conflict note (if any): —.

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

  • AI_4 (decision): 0
  • Claim (one line): no technical description of the AI model/architecture/versions was found in the available Tier‑1 sources.
  • Evidence: Tier‑1 — https://hashai.co.uk/
  • Why sufficient / why not (one line): the description remains generic (“advanced algorithms”) without implementation details.
  • Conflict note (if any): —.

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: 0x292fcdd1b104de5a00250febba9bc6a5092a0076
  • Evidence: Tier‑1 — https://etherscan.io/token/0x292fcdd1b104de5a00250febba9bc6a5092a0076
  • Why sufficient / why not (one line): the token and supply are displayed on Etherscan.
  • Conflict note (if any): —.

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

  • OC_2 (decision): 0
  • What useful logic is onchain: besides the token, public addresses/contracts of the Share Pool are not listed in Tier‑1 sources.
  • Evidence: Tier‑1 — https://docs.hashai.co.uk/features/community-share-pool
  • Why sufficient / why not (one line): the deposit/claim process is described, but without addresses of protocol contracts.
  • Conflict note (if any): —.

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the share pool could be implemented in a centralized way; onchain criticality is not proven.
  • Evidence: Tier‑1 — https://docs.hashai.co.uk/features/community-share-pool
  • Why sufficient / why not (one line): Tier‑1 contains no argument that the product breaks without the blockchain.
  • Conflict note (if any): —.

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, HASHAI.
  • Evidence: Tier‑1 — https://etherscan.io/token/0x292fcdd1b104de5a00250febba9bc6a5092a0076
  • Why sufficient / why not (one line): the token is displayed on Etherscan.
  • 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 explicit payment layer of “paying HASHAI for the service” was found in Tier‑1 sources.
  • Evidence: Tier‑1 — https://docs.hashai.co.uk/
  • Why sufficient / why not (one line): rewards/pools and rental are described, but without a rule of payment with the token.
  • Conflict note (if any): —.

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

  • TK_2 (decision): 1
  • Claim (one line): a deposit of HASHAI into the share pool yields an ETH reward; early withdrawal — with a 15% fee.
  • Evidence: Tier‑1 — https://docs.hashai.co.uk/features/community-share-pool
  • Why sufficient / why not (one line): incentives and a penalty (fee) are described at the level of the pool mechanics.
  • Conflict note (if any): —.

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance mechanics via the token are not described in Tier‑1 sources.
  • Evidence: Tier‑1 — https://docs.hashai.co.uk/
  • Why sufficient / why not (one line): there are no voting/DAO rules.
  • Conflict note (if any): —.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): the share pool could logically run on other collateral/a subscription; HASHAI acts as “participation” rather than a uniquely necessary asset.
  • Evidence: Tier‑1 — https://docs.hashai.co.uk/features/community-share-pool
  • Why sufficient / why not (one line): Tier‑1 describes no properties that fundamentally require HASHAI specifically.
  • Conflict note (if any): —.

Evidence (table)

Tier Source What it proves
Tier‑1 https://hashai.co.uk/ the claim about AI mining optimization (what the AI does)
Tier‑1 https://docs.hashai.co.uk/features/community-share-pool the Share Pool mechanics (28-day deposit, ETH claim, 15% early withdrawal fee)
Tier‑1 https://etherscan.io/token/0x292fcdd1b104de5a00250febba9bc6a5092a0076 the token contract and the Max Total Supply

No comments to display

Back to top