Skip to main content

Homebrew Robotics Club

Homebrew Robotics Club (BREW) — 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).

Homebrew Robotics Club — an AI/Robotics / DePIN project/community that builds open‑source tools and a marketplace around “humanoid robotics”: paid robot actions (pay‑to‑access), telepresence/teleoperation, robot packages and data. The BREW token is an SPL on the Solana network; the repositories separately describe the Solana‑based x402 protocol for payment/access to robot endpoints (payment can be in SOL).

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 set of open‑source tools and a planned marketplace for “robot actions”, robot packages and data.
  • Who it’s for: developers/hobbyists and teams that want to integrate and monetize robot functions.
  • Why onchain/token: onchain payments are used to control access to robot actions (x402/Solana); the role of the BREW token as a mandatory utility in the payment flows is not confirmed.
  • What you can actually touch (Tier‑1): x402 pay‑to‑access robot actions (README) — https://github.com/homebrewroboticsclub/Ros-X402-Node

How it works (very briefly)

  1. The developer/user does: calls a robot endpoint/command (REST/ROS integrations) or launches the orchestration service.
  2. The system does: for paid actions, creates a payment session and requires payment via the x402 protocol (Solana) before executing the robot action.
  3. The user gets: execution of the robot action/command (for example, demo actions) and/or orchestration of several robots.
  4. Where the blockchain is: payments/payment verification — onchain on Solana (x402); the BREW token exists as an SPL asset.
  5. Token role: the BREW token is claimed as a community/ecosystem token; the confirmed utility in the x402 protocol is not the BREW token but Solana settlement (often SOL).

Quick links: AI thesis fit

Project passport

Field Value
Project name Homebrew Robotics Club
Also known as (aliases) HBRC, BREW, $BREW
Logo (logo) ../assets/225_homebrew-robotics-club_logo.svg
Token symbol (ticker) BREW
Category AI/Robotics | DePIN
Primary chain (chain) Solana
Type non-EVM
Network status mainnet
Consensus (consensus) PoS (Solana)
Launch date (launch_date) —
Project status (status) active (website + GitHub available)
Token (standard) SPL
Token contract 2hXQn7nJbh2XFTxvtyKb5mKfnScuoiC1Sm8rnWydpump
Token model (token_type) community / ecosystem
Max supply —
Issuance —
Tokenomics (tokenomics, brief) on the website: 70% community launch, 15% ecosystem, 15% team (streamflow locking/vesting — claimed)
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) voice-to-action, AI vision, AI programming assistant
Use‑case (use_case) paid robot actions + packages/data marketplace
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary 3 / 3 / 0 / 3
Last verified 2026-02-11

General project overview

Homebrew Robotics Club describes itself as a club/project that builds a software layer and applied use cases for humanoid robots, making robots “useful in the real world” (paid actions, teleop on demand, task routing). The whitepaper also describes the idea of Homebrew Exchange: a marketplace of robot packages (software packages) and a marketplace of data (sensor/performance datasets), in order to increase the “out‑of‑the‑box” functionality of robots and create an economy around extensions.

The open‑source repositories contain specific integrations: for example, a ROS package that exposes robot capabilities as REST endpoints and requires payment via the Solana‑based x402 protocol before executing actions.

Features/modules

  • Homebrew Exchange (concept): a marketplace of robot packages + a marketplace of data (whitepaper).
  • Paid robot actions / x402: pay‑to‑access control of robot action execution via Solana (GitHub README).
  • Orchestration/raid control: a service that registers robots, monitors health and routes commands (GitHub README).
  • Voice‑driven MCP server (Brewie): voice commands, LLM orchestration of actions and an AI vision module (GitHub README).

Typical scenarios

  • Scenario 1 (paid action): a client calls /api/v1/robot/... → receives HTTP 402 with a reference → pays onchain → repeats the request → the robot executes the action.
  • Scenario 2 (orchestration): an operator registers robots in the service → sends “dance/buy‑cola” → the service selects an executor (closest/lowest_price) and performs the x402 handshake.
  • Scenario 3 (voice): a user speaks a command → the voice agent recognizes it → the LLM plans sub‑tasks → the server calls robot actions and (if enabled) payment modules.

Getting started (wallet/network)

  • What you need: to participate in the token — a Solana wallet; for development — access to the repositories/tools and/or the community (Discord).
  • Network/chain: Solana.
  • Fees: Solana fees for x402 payments and operations with the SPL token.

Architecture/tech (non‑AI)

  • Components: ROS packages (Noetic), a REST gateway for robot actions, the x402 payment layer (Solana), an orchestration service (Node.js), auxiliary AI modules (voice agent, vision).
  • Participant roles: robot developers/operators; clients that call robot actions; the community that publishes packages/data.
  • Where logic runs: robot control and AI commands — offchain; payment/payment verification (x402) — onchain (Solana).
  • Dependencies: Solana RPC; selected LLM/AI APIs (for example, Together API in Brewie MCP); the ROS ecosystem.

Token/economics (expanded, no forecasts)

  • Token utility: the website lists the $BREW token and its distribution (community/ecosystem/team), but specific “BREW is paid for X” scenarios are not recorded in the whitepaper/repositories.
  • Protocol necessity drivers: paid access to robot actions is implemented via x402 (Solana), which does not require the BREW token specifically (it can be SOL); therefore the necessity of BREW remains low‑medium.
  • Who pays fees: Solana users during onchain operations (x402 settlement and SPL operations).
  • Where fees go: — (no Tier‑1 scheme of fee distribution found).
  • Issuance/burn: —.
  • Security/incentive mechanisms: pay‑to‑access enforcement (x402); staking/slashing parameters are not described.
  • Distribution and token issuance schedule: the website lists 70/15/15; lock details are mentioned as streamflow (without onchain SSOT in this card).
  • Treasury: —.

Governance

  • Who makes decisions: —.
  • How protocol parameters change: via updates to the repositories/community.
  • Where decisions are discussed/made: Discord, GitHub.
  • Keys/multisig: —.

Security and incidents

  • Audits: —.
  • Bug bounty: —.
  • Incidents: —.
  • Threat model: robot/voice control security risks; key compromise risks (x402); risks of external AI APIs.

Project status and timeline

  • Current status: active development of open‑source repositories + website/whitepaper.
  • Key releases/milestones: —.
  • Roadmap: described on the website and in the whitepaper as short/medium/long‑term phases.

Ecosystem/integrations

  • Integrations: Solana (x402 settlement + SPL token), ROS Noetic, Node.js services, LLM/voice tooling.
  • Partners: —.
  • Where it’s actually used: as open‑source tooling; production deployments are not confirmed.

AI component of the project

  • What is real AI here? The whitepaper claims AI‑assisted programming and voice‑to‑action; the repositories contain an implementation of a voice agent + LLM orchestration and a mention of AI vision (as a module), but without measurable quality metrics.
  • What is truly onchain? Solana payments via the x402 protocol for access to robot actions; the BREW token as an SPL mint.
  • Why is a token needed? The $BREW token is claimed on the website with a distribution; the role of the token in protocol payments/access is not confirmed (x402 runs on Solana settlement, often SOL).
  • Red flags (based on the information found): token‑washing (the utility of BREW is unclear), AI‑washing (many promises without KPIs), physical‑world safety (voice control + payments).

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 3
Onchain necessity medium 3
Token necessity low‑medium 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): There are signs of AI reality per Tier‑1 (see AI_1..AI_4), so the AI_0 flag (intent‑only) does not apply.
  • Evidence: Tier‑1 — see Evidence/links in AI_1..AI_4.
  • Why sufficient / why not (one line): AI_0=1 is admissible only when AI_1..AI_4=0; here ai_score without AI_0 = 3.
  • Conflict note (if any): none.

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the voice agent recognizes commands, passes them to the LLM and orchestrates robot action calls; an AI vision module is claimed.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/homebrewroboticsclub/brewie-mcp-server/main/README.md ; https://homebrew.build/whitepaper
  • Why sufficient / why not (one line): the existence of the described implementation confirms the AI part at least at the level of a prototype/tool.
  • Conflict note (if any): none.

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there are reproducible open‑source repositories for voice control and paid robot actions via x402.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/homebrewroboticsclub/Ros-X402-Node/main/README.md ; https://raw.githubusercontent.com/homebrewroboticsclub/brewie-mcp-server/main/README.md
  • Why sufficient / why not (one line): the README contains instructions and descriptions of the execution/payment flows.
  • Conflict note (if any): none.

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —.
  • Context (version/date/how measured): —.
  • Evidence: Tier‑1 — https://homebrew.build/whitepaper
  • Why sufficient / why not (one line): the whitepaper does not publish measurable quality metrics of the AI modules.
  • Conflict note (if any): none.

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

  • AI_4 (decision): 1
  • Claim (one line): there are technical descriptions of the voice agent, the LLM flow and the payment enforcement in x402 (at the README level).
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/homebrewroboticsclub/Ros-X402-Node/main/README.md ; https://raw.githubusercontent.com/homebrewroboticsclub/Raid-app-x402/main/README.md
  • Why sufficient / why not (one line): the documentation is sufficient to understand the architecture and reproduce the services.
  • Conflict note (if any): none.

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Solana mainnet
  • Addresses/identifiers: SPL mint BREW: 2hXQn7nJbh2XFTxvtyKb5mKfnScuoiC1Sm8rnWydpump
  • Evidence: Tier‑1 — https://explorer.solana.com/address/2hXQn7nJbh2XFTxvtyKb5mKfnScuoiC1Sm8rnWydpump?cluster=mainnet
  • Why sufficient / why not (one line): the token’s mint address is confirmed via Solana Explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: x402 payment enforcement: the robot action is executed only after a confirmed onchain payment on Solana.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/homebrewroboticsclub/Ros-X402-Node/main/README.md
  • Why sufficient / why not (one line): the README describes the creation of a payment session, the onchain transfer and transaction verification before executing actions.
  • Conflict note (if any): payment goes through Solana settlement (often SOL), not through the BREW token.

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain, the trustless payment verification before executing a robot action (the core of the x402 approach) disappears.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/homebrewroboticsclub/Ros-X402-Node/main/README.md
  • Why sufficient / why not (one line): the payment verification scheme relies on confirmed Solana transactions.
  • Conflict note (if any): the payment layer could also be implemented in a centralized way, but that would be a different trust model.

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, BREW, on Solana.
  • Evidence: Tier‑1 — https://explorer.solana.com/address/2hXQn7nJbh2XFTxvtyKb5mKfnScuoiC1Sm8rnWydpump?cluster=mainnet
  • Why sufficient / why not (one line): the token’s mint address is confirmed via Solana Explorer.
  • Conflict note (if any): none.

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): the x402 payment layer is described as Solana settlement (SOL), without a tie to BREW.
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/homebrewroboticsclub/Ros-X402-Node/main/README.md
  • Why sufficient / why not (one line): the README describes amounts in SOL and verification of the transfer instruction.
  • Conflict note (if any): BREW token utility may appear later, but it is not confirmed now.

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

  • TK_2 (decision): 0
  • Claim (one line): the available Tier‑1 sources contain no staking/slashing/collateral parameters for BREW.
  • Evidence: Tier‑1 — https://homebrew.build/
  • Why sufficient / why not (one line): the website gives only the token distribution, without incentive parameters.
  • Conflict note (if any): none.

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): the governance role of the BREW token is not described as a working mechanism.
  • Evidence: Tier‑1 — https://homebrew.build/
  • Why sufficient / why not (one line): the website contains no description of a DAO/voting.
  • Conflict note (if any): none.

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): without a confirmed protocol utility, the BREW token looks replaceable for the core functions (x402 payments can work without it).
  • Evidence: Tier‑1 — https://raw.githubusercontent.com/homebrewroboticsclub/Ros-X402-Node/main/README.md
  • Why sufficient / why not (one line): the payment enforcement is described in SOL, not in BREW.
  • Conflict note (if any): none.

Evidence (table)

Tier Source What it proves
Tier‑1 https://homebrew.build/ Positioning (paid robot actions, teleop, open robotics) and the 70/15/15 token distribution.
Tier‑1 https://homebrew.build/whitepaper Whitepaper: Homebrew Exchange (marketplace of packages/data), AI‑assisted programming and voice‑to‑action as a roadmap.
Tier‑1 https://github.com/homebrewroboticsclub The existence of an active codebase (ROS/x402/voice agent, etc.).
Tier‑1 https://raw.githubusercontent.com/homebrewroboticsclub/Ros-X402-Node/main/README.md Paid robot actions via x402: creation of a payment session, onchain verification and execution gating.
Tier‑1 https://raw.githubusercontent.com/homebrewroboticsclub/brewie-mcp-server/main/README.md Voice‑driven MCP server: voice commands → LLM → robot actions; AI vision and BrewPay are claimed.
Tier‑1 https://explorer.solana.com/address/2hXQn7nJbh2XFTxvtyKb5mKfnScuoiC1Sm8rnWydpump?cluster=mainnet Onchain page of the SPL mint (Solana Explorer).
Tier‑2 https://solscan.io/token/2hXQn7nJbh2XFTxvtyKb5mKfnScuoiC1Sm8rnWydpump Explorer/aggregator of onchain data (for navigation).
Tier‑2 https://coinmarketcap.com/currencies/homebrew-robotics-club/ Aggregator: reference profile and navigation links.

No comments to display

Back to top