Skip to main content

HUMAN Protocol

HUMAN Protocol — 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).

HUMAN Protocol — an AI/Data | Infra project on the Ethereum network, token (symbol: HMT).

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 protocol and a set of smart contracts/oracles for launching and performing “a human does the work → gets paid” tasks.
  • Who it’s for: companies/task requesters, executors (workers), integration developers and oracle operators.
  • Why onchain/token: onchain is used for escrow/settlement and recording results; the HMT token is the means of payment for tasks in the protocol.

How it works (very briefly)

  1. The requester publishes a job: describes the work and the terms (including via a “smart bounty”/escrow).
  2. The network distributes tasks: the Exchange/oracles select and hand out tasks to executors.
  3. Executors perform the work: answers/results are collected and pass quality checks (via oracles).
  4. Where the blockchain is: escrow and settlement, as well as recording the hash/pointer to the results — on Ethereum.
  5. Token role: HMT is used as the unit of settlement/payment for performing tasks in the protocol.

Quick links: AI thesis fit

Project passport

Field Value
Project name HUMAN Protocol
Also known as (aliases) HUMAN, HMT
Logo (logo) ../assets/451_human_logo.svg
Token symbol (ticker) HMT
Category AI/Data | 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 0xd1ba9bac957322d6e8c07a160a3a8da11a0d2867
Token model (token_type) utility (payments)
Max supply 1 000 000 000 HMT (total supply)
Issuance —
Tokenomics (tokenomics, brief) HMT is used to pay for tasks (smart bounties) and to distribute payouts to protocol participants.
Governance cross-chain governance (HMT)
Admins/keys —
Audit yes
Bug bounty yes
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI data labeling + model evaluation (human experts)
Use‑case (use_case) data annotation jobs + escrow payments
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 1 / onchain_score 2 / token_score 2 / evidence_score 2
Last verified 2026-02-11

General project overview

HUMAN Protocol is an open‑source protocol that describes and automates the flow “the requester publishes work → the network distributes tasks → the results are checked → payouts happen according to the rules”. In the Tier‑1 technical documents, the declared focus is on scenarios where machine systems need human checks/labeling, in particular for preparing datasets and controlling the quality of model answers.

Features/modules

  • Smart bounties (escrow contracts): the requester reserves HMT and sets the job parameters.
  • Orchestration via Exchange + oracles: task distribution and quality evaluation of the results.
  • Integrations/SDK: tools for developers and operators of protocol components.

Typical scenarios

  • Scenario 1: a requester publishes a data labeling job → receives a dataset/labels after a quality check.
  • Scenario 2: a developer integrates their own tool/workflow → uses the smart contracts and oracles for settlement/checks.
  • Scenario 3: an operator runs a protocol component (oracle) → receives fees for its role in processing jobs.

Getting started (wallet/network)

  • What you need: an EVM wallet (for actions on the network) and access to the protocol’s products (docs/SDK).
  • Network/chain: Ethereum.
  • Fees: Ethereum network fees (gas) + possible fees of protocol components (see the Tier‑1 documentation).

Architecture/tech (non‑AI)

  • Components: smart contracts (escrow/smart bounties), Exchange, Recording Oracle, Reputation Oracle (and other oracles), integrations/SDK.
  • Participant roles: task requesters (requesters), executors (workers), oracle operators, integration developers.
  • Where logic runs: critical settlement/escrow — onchain (Ethereum), distribution and quality evaluation — offchain in components/oracles with the results recorded.
  • Dependencies: offchain storage for data/results + an onchain layer for settlement.

Token/economics (expanded, no forecasts)

  • Token utility: HMT is used as the means of settlement and escrow for paying for jobs (smart bounties).
  • Protocol necessity drivers: the protocol is built around automatable “payment for verifiably completed work” contracts, where HMT figures as the unit of settlement.
  • Who pays fees: job initiators and participants making transactions on the network (gas).
  • Where fees go: payouts are distributed among the parties of the process (executors/components), according to the protocol rules (see the Tier‑1 whitepaper).
  • Issuance/burn: total supply 1 000 000 000 HMT; circulating supply 750 000 000 HMT (per the official HMT token page).
  • Security/incentive mechanisms: the role of the oracles is quality checking and triggering payouts; details — in the Tier‑1 whitepaper.
  • Distribution and token issuance schedule: allocation (Tier‑1): 25% Operating Trust, 23.4% Presale Contributors, 20.5% Strategic Partners, 10% Coinlist, 8.2% Ecosystem Fund, 7% Team, 3.7% Purchasers, 1.3% Advisors, 1% Issuing Foundation; the vesting/unlock schedule is not established per Tier‑1.
  • Treasury: —.

Governance

  • Who makes decisions: governance is described as a cross-chain architecture; proposals are created by magistrates (exclusive addresses), voters with governance tokens vote.
  • How protocol parameters change: via proposals → voting (snapshot voting power) → aggregation across chains → queue/execution; a timelock before execution is possible.
  • How to participate: voters deposit governance tokens and self-delegate to activate their voting right (see the Tier‑1 governance docs).
  • Keys/multisig: not established per Tier‑1 (within this card) — apart from the concept of a magistrate (exclusive address) in the governance docs.

Security and incidents

  • Audits: a public audit report is claimed in links_* (see Audit report(s)).
  • Bug bounty: a bug bounty program is claimed in links_*.
  • Incidents: — (not established per Tier‑1).
  • Threat model: the main risks depend on trust in the offchain components (oracles/exchange) and on the correctness of the smart contracts/validation processes.

Project status and timeline

  • Current status: mainnet (Ethereum).
  • Key releases/milestones: — (not established per Tier‑1).
  • Roadmap: milestones of the official repository (see links_*).

Ecosystem/integrations

  • Integrations: SDK/tools for developers and component operators (see links_* Docs).
  • Partners: — (not established per Tier‑1).
  • Where it’s actually used: the focus in the Tier‑1 description is large‑scale tasks/labeling; specific public cases/usage examples are not recorded per Tier‑1.

AI component of the project

  • What is real AI here? In Tier‑1 sources the protocol is described as infrastructure useful for ML/AI workflows (data labeling and evaluation of output quality), but it is not itself an “AI model/inference”.
  • What is truly onchain? Escrow/settlement and recording of pointers/hashes of results in smart contracts on Ethereum.
  • Why is a token needed? HMT is described as the means of settlement/escrow for paying for jobs and distributing payouts to the participants of the process.
  • Red flags (based on the information found): if a “strong AI component” is claimed but there are no Tier‑1 artifacts (model/metrics/architecture); mixing “AI applicability” (labeling for ML) with “AI in the protocol”.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 1
  • Claim (one line): The protocol is declared as infrastructure for ML‑related tasks: data labeling and evaluation of inference quality.
  • Evidence: Tier‑1 — https://hmt.ai/whitepaper
  • Why sufficient / why not (one line): This confirms AI applicability/intent (human‑in‑the‑loop for ML), but does not prove the existence of its own AI model/metrics.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): No Tier‑1 confirmation of a “built‑in AI component” (model/inference) as part of the protocol was found.
  • Evidence: Tier‑1 — https://docs.humanprotocol.org/ ; https://hmt.ai/whitepaper
  • Why sufficient / why not (one line): Tier‑1 describes the protocol and the market for work/checks, not its own AI model/inference.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): There is a Tier‑1 demo/example of the protocol’s operation, but it is not a demonstration of an “AI feature” (rather a demo of launching jobs).
  • Evidence: Tier‑1 — https://docs.humanprotocol.org/
  • Why sufficient / why not (one line): To set 1, a demo showing specifically an AI feature/output is needed; per Tier‑1 this is not established.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://hmt.ai/whitepaper
  • Why sufficient / why not (one line): No Tier‑1 metrics/benchmarks of an AI component (model/quality) applicable to the assessment of AI reality were found.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): There is a tech description of the protocol (contracts/oracles), but no tech description of its own AI model/versions was found.
  • Evidence: Tier‑1 — https://hmt.ai/whitepaper ; https://docs.humanprotocol.org/
  • Why sufficient / why not (one line): The documents describe the protocol architecture; AI_4 requires a Tier‑1 tech description of the AI component.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: HMT token: 0xd1ba9bac957322d6e8c07a160a3a8da11a0d2867
  • Evidence: Tier‑1 — https://etherscan.io/token/0xd1ba9BAC957322D6e8c07a160a3A8dA11A0d2867 ; https://hmt.ai/whitepaper
  • Why sufficient / why not (one line): There is an onchain artifact (ERC‑20 token) and a Tier‑1 description of the use of Ethereum smart contracts.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: smart bounties/escrow for jobs and triggers for distributing payouts according to conditions.
  • Evidence: Tier‑1 — https://hmt.ai/whitepaper
  • Why sufficient / why not (one line): The whitepaper describes the smart contract architecture (escrow + release/distribute), i.e. the onchain logic is broader than a simple “the token exists”.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: no Tier‑1 justification was found that without the blockchain the protocol “breaks down” (rather than turning into a centralized settlement service).
  • Evidence: Tier‑1 — https://hmt.ai/whitepaper
  • Why sufficient / why not (one line): OC_3 requires an explicit argument “which key property is lost”; not recorded per Tier‑1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The protocol has a token, HMT (EIP‑20 / ERC‑20 compatible).
  • Evidence: Tier‑1 — https://hmt.ai/whitepaper ; https://etherscan.io/token/0xd1ba9BAC957322D6e8c07a160a3A8dA11A0d2867
  • Why sufficient / why not (one line): The whitepaper directly describes HMT, and the onchain artifact confirms the existence of the token.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): HMT serves as the means of exchange/payment for performing jobs/tasks in the protocol.
  • Evidence: Tier‑1 — https://hmt.ai/whitepaper ; https://hmt.ai/lightpaper
  • Why sufficient / why not (one line): The Tier‑1 documents directly describe HMT as the medium of exchange/primary mechanism of value transfer in the network.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): No Tier‑1 description of mandatory collateral/penalties in HMT as a key part of the protocol mechanics was found.
  • Evidence: Tier‑1 — https://hmt.ai/lightpaper
  • Why sufficient / why not (one line): Per Tier‑1, the slashing/collateral conditions required for TK_2=1 are not established.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): The Tier‑1 documentation describes governance: voting on proposals with governance tokens (derived from HMT) and cross-chain aggregation of votes.
  • Evidence: Tier‑1 — https://docs.humanprotocol.org/features/governance/
  • Why sufficient / why not (one line): Tier‑1 describes the actors, the proposals/voting flow and the binding of voting tokens to HMT.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability of the token with another payment asset is not established per Tier‑1.
  • Evidence: Tier‑1 — https://hmt.ai/whitepaper
  • Why sufficient / why not (one line): TK_4 requires an explicit argument “it can be replaced without loss of meaning”; in the current Tier‑1 sources this is not formulated.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://hmt.ai/whitepaper The purpose of the protocol and the “human labor → ML/AI workflows” link; the use of Ethereum smart bounties and the role of HMT as the means of settlement.
Tier‑1 https://hmt.ai/lightpaper HMT as the primary mechanism of value transfer; jobs/smart bounties (escrow) and participant roles.
Tier‑1 https://docs.humanprotocol.org/ Tier‑1 description of the protocol/architecture and roles (including oracles).
Tier‑1 https://humanprotocol.org/hmt Total supply/circulating supply of HMT and token allocation (official token page).
Tier‑1 https://docs.humanprotocol.org/features/governance/ Governance architecture (hub-and-spoke), actors (magistrate/voters), proposals/voting flow and timelock.
Tier‑1 https://etherscan.io/token/0xd1ba9BAC957322D6e8c07a160a3A8dA11A0d2867 Onchain artifact: the HMT ERC‑20 token (contract/network).
Tier‑1 https://github.com/humanprotocol/human-protocol The existence of a public repository (open source), which reduces the risk of “marketing only”.
Tier‑1 — No Tier‑1 source for claim “the protocol has its own AI model/quality metrics” was found / not confirmed by Tier‑1.

No comments to display

Back to top