Skip to main content

BuildAI

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

BuildAI — an AI/Agents | Infra project on the Ethereum network, token (symbol: Build).

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 product that positions itself as a set of AI agents/solutions for task automation (including customer support and workflow).
  • Who it’s for: business teams and users who connect AI agents; integration developers.
  • Why onchain/token: onchain, the token is observable; the necessity of the token for the operation of the product is not established per Tier‑1 sources.

How it works (very briefly)

  1. The user does: selects an AI agent/feature and sets a request/task.
  2. The system does: performs the processing/automation via the AI agent (offchain).
  3. The user gets: a response/action/result.
  4. Where the blockchain is: onchain, the Build token is observable (the contract in the Explorer).
  5. Token role: per Tier‑1 sources, it is not confirmed that the token is mandatory for the operation of the product.

Quick links: AI thesis fit

Project passport

Field Value
Project name BuildAI
Also known as (aliases) Build
Logo (logo) ../assets/574_buildai_logo.svg
Token symbol (ticker) Build
Category AI/Agents | 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 0xEFF9CDb294872b6553F4E9631Fb4D1fa4F9C5e6B
Token model (token_type) —
Max supply 10,000,000 Build (max total supply)
Issuance fixed
Tokenomics (tokenomics, brief) Max total supply in the Explorer; the role of the token in the product is not established per Tier‑1 sources.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI workflow agents for automation
Use‑case (use_case) business automation + AI assistants
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 1 / onchain_score 1 / token_score 0 / evidence_score 3
Last verified 2026-02-11

General project overview

BuildAI positions itself as a product/portfolio of AI agents and related applications for task automation (including support and workflow). A Tier‑1 description is available on the official website and in the GitBook documentation.

Features/modules

  • AI Agents: a set of agents for dialogues and performing actions (claimed).
  • Applications/tools: listed in the portfolio on the website (for example, an extension, dapp tools).
  • Documentation and roadmap: described in the GitBook (see links_*).

Typical scenarios

  • Scenario 1: a user asks the agent a question/task → receives a response/action.
  • Scenario 2: a team connects an agent for support → automates typical responses/processes.
  • Scenario 3: a user studies the docs → connects/configures the agent features.

Getting started (wallet/network)

  • What you need: access to the website/documentation; for onchain operations — an EVM wallet and ETH.
  • Network/chain: Ethereum (the token is observable via the Explorer).
  • Fees: Ethereum fees (gas) for operations with the token; the product’s fee model is not established per Tier‑1 sources.

Architecture/tech (non‑AI)

  • Components: offchain services/interfaces and applications; the onchain part (at minimum) — the token (see the Explorer).
  • Participant roles: users/clients; developers/operators of the product.
  • Where logic runs: AI logic — offchain; token/transactions — onchain.
  • Dependencies: —.

Token/economics (expanded, no forecasts)

  • Token utility: not established per Tier‑1 sources.
  • Protocol necessity drivers: not established per Tier‑1 sources.
  • Who pays fees: users — in terms of Ethereum network fees for operations with the token.
  • Where fees go: to Ethereum validators (network fees).
  • Issuance/burn: max total supply 10,000,000 Build (see the Explorer).
  • Security/incentive mechanisms: —.
  • Distribution and token issuance schedule: —.
  • Treasury: —.

Governance

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

Security and incidents

  • Audits: not found per Tier‑1 sources.
  • Bug bounty: not found per Tier‑1 sources.
  • Incidents: —.
  • Threat model: for offchain AI services, the key risks are the absence of verifiable quality/security artifacts; for onchain — the standard token risks.

Project status and timeline

  • Current status: mainnet (in terms of the token on Ethereum).
  • Key releases/milestones: —.
  • Roadmap: see links_* (GitBook).

Ecosystem/integrations

  • Integrations: listed on the website (a portfolio of applications/tools).
  • Partners: —.
  • Where it’s actually used: not established per Tier‑1 sources.

AI component of the project

  • What is real AI here? A set of AI agents/tools for automation (claimed on the Tier‑1 website/documentation).
  • What is truly onchain? Onchain, the Build token is observable (Explorer); the AI logic and the interfaces — offchain.
  • Why is a token needed? Not established per Tier‑1 sources.
  • Red flags (based on the information found): absence of Tier‑1 confirmation of the necessity of the token and of quality metrics of the AI component (AI_3=0).

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): In Tier‑1 sources, the product is described as an AI solution/agents, not only as a plan.
  • Evidence: Tier‑1 — https://buildaierc.com/ ; https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): We apply AI_0 in the absence of a description of the feature; here the feature is described (see AI_1), hence 0.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): AI agents/tools for task automation and interaction with users (including support/workflows).
  • Evidence: Tier‑1 — https://buildaierc.com/ ; https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): The website and the docs describe the purpose and examples of applications/agents.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): A public app/demo URL for checking “what you can touch” is not recorded per Tier‑1 sources.
  • Evidence: Tier‑1 — https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): AI_2=1 requires a confirmed app/demo URL in links_* and Evidence; under the conservative rule we set 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://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): Tier‑1 quality metrics/benchmarks were not found in Tier‑1 sources.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): A technical description of the architecture/model versions sufficient for AI_4=1 was not found in Tier‑1 sources.
  • Evidence: Tier‑1 — https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): With insufficient technical data we conservatively set 0.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: the Build token (ERC‑20) — 0xEFF9CDb294872b6553F4E9631Fb4D1fa4F9C5e6B
  • Evidence: Tier‑1 — https://etherscan.io/token/0xEFF9CDb294872b6553F4E9631Fb4D1fa4F9C5e6B
  • Why sufficient / why not (one line): The existence of an onchain token contract and its observability in the Explorer is sufficient for OC_1=1.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: not established per Tier‑1 sources (other than the token).
  • Evidence: Tier‑1 — https://build-ai.gitbook.io/docs/ ; https://etherscan.io/token/0xEFF9CDb294872b6553F4E9631Fb4D1fa4F9C5e6B
  • Why sufficient / why not (one line): OC_2=1 requires specific useful onchain logic; per Tier‑1 sources this is not confirmed.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the criticality of onchain for the product is not established per Tier‑1 sources.
  • Evidence: Tier‑1 — https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): In the absence of explicit Tier‑1 argumentation we set 0.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, Build (ERC‑20).
  • Evidence: Tier‑1 — https://etherscan.io/token/0xEFF9CDb294872b6553F4E9631Fb4D1fa4F9C5e6B
  • Why sufficient / why not (one line): The Explorer confirms the existence of the token and the symbol.
  • 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): The use of the token as a mandatory payment for the service is not established per Tier‑1 sources.
  • Evidence: Tier‑1 — https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): In the absence of a Tier‑1 description of pay‑to‑use mechanics we set 0.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): Token‑based incentives/collateral/penalties are not established per Tier‑1 sources.
  • Evidence: Tier‑1 — https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): No description of staking/slashing/collateral was found in Tier‑1 sources; we set 0.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): The use of the token for governance is not established per Tier‑1 sources.
  • Evidence: Tier‑1 — https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): TK_3=1 requires a Tier‑1 mechanic of governance use; in its absence — 0.
  • 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 established per Tier‑1 sources.
  • Evidence: Tier‑1 — https://build-ai.gitbook.io/docs/
  • Why sufficient / why not (one line): TK_4=1 requires proof of replaceability; in its absence — 0.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://buildaierc.com/ Positioning of the product and examples of AI agents/applications.
Tier‑1 https://build-ai.gitbook.io/docs/ Official documentation and roadmap.
Tier‑1 https://etherscan.io/token/0xEFF9CDb294872b6553F4E9631Fb4D1fa4F9C5e6B Onchain fact: the Build token, contract and max total supply.
Tier‑2 https://www.coingecko.com/en/coins/buildai Token profile (context/navigation).
Tier‑2 https://coinmarketcap.com/currencies/buildai/ Token profile (context/navigation).
Tier‑3 — —

No comments to display

Back to top