ZHC Builder Stack

The tool map for building a Zero-Human Company.

ZHCs are not built from one product. They are assembled from runtime, legal and payment rails, treasury control, market surfaces, public proof, and distribution loops.

Submit a tool Read the ZHC thesis

Operating sequence

01Define the company loop

Choose the ZHC type first: operator company, tokenized company, treasury primitive, or agent-human service loop.

02Prove the first operating surface

Get one visible proof working: revenue, fees, treasury policy, verified users, or a live market venue.

03Add control and transparency

Only after proof exists should you add custody, analytics, governance, and public dashboards.

04Scale the stack

Add launch infrastructure, distribution, and optional human fallback once the base company loop is real.

Tool categories

Tool categories

Each category maps to a company function. Categories are layered by operating need, not by hype cycle.

Entity & Payments

Launch & Markets

Proof & Analytics

Inclusion standard

A tool belongs here only if it solves a real ZHC operating problem, has a visible proof surface, and can be tied to live workflows, public dashboards, or serious builder usage.

Builder journeys

Builder journeys

Pick the path that matches the company you are actually building. A ZHC stack is a sequence, not a shopping list.

01

Start an AI company

For builders who want an operator that can ship, sell, and expose real revenue instead of only running a token narrative.

Use this if: You already have a product thesis and you can expose the first live revenue metric within weeks.

Do not start here if: Do not start here if you only want a tradable token surface but no repeatable product loop yet.

Minimum viable stack

OpenClawClawBankTrustMRR

First proof to expose: Expose the first public revenue or usage proof before adding governance and more complexity.

02

Launch a tokenized ZHC

For teams that need a public market, fee capture, visible treasury mechanics, and an on-chain ownership surface.

Use this if: Use this when the token is part of the operating design, not only a marketing wrapper.

Do not start here if: Avoid this path if the product has no clear fee trail, treasury logic, or official token stance.

Minimum viable stack

ClawnchSafeDexScreener

First proof to expose: Show the official token venue, treasury wallet, and the first fee or holder signal immediately.

03

Build treasury infrastructure

For operators focused on capital allocation, vault logic, yield routing, and autonomous balance-sheet management.

Use this if: Use this once you already control cash flow, deposits, or treasury assets that need reporting and policy.

Do not start here if: Do not overbuild treasury logic before you have real deposits, fees, or recurring revenue to manage.

Minimum viable stack

SafeRobot MoneyDune

First proof to expose: Expose wallet policy, treasury holdings, and the first verifiable yield or fee event.

04

Add human fallback

For agents that can operate autonomously most of the time but still need humans for execution, review, or edge-case labor.

Use this if: Choose this when human labor is the bottleneck preventing more product throughput or service delivery.

Do not start here if: Avoid this if your workflow still depends on fully manual coordination with no programmable payment or proof layer.

Minimum viable stack

MoltyCashClawBankDune

First proof to expose: Publish task payouts, proof-of-work records, and who approved the handoff.

Blueprint stacks

Execution-first templates with required tools, optional layers, and the first proof each stack should expose.

Most founders should start with one of these opinionated paths instead of browsing every tool.

AI Company Stack

For a ZHC that sells software, content, services, or reusable agent skills and needs proof-of-life fast.

Who this is for: Solo builders or small teams turning one operator into a revenue-producing company.

Required

OpenClawAnthropicStripeTrustMRR

Add later

ClawBankFarcasterClaw Mart

Ignore for now

SnapshotTallyClawnch

Closest live example: Pattern closest to Felix, Aleister, and Juno-style operator businesses.

Live examples on ZHCs.AI

Felix Aleister Juno

First proof to expose: Expose revenue, customers, or paid usage before expanding into treasury automation or token layers.

Tokenized ZHC Stack

For a ZHC that wants a public market, treasury transparency, and value capture tied to fees, usage, or community ownership.

Who this is for: Projects that already know why the token exists and can defend an official-market stance.

Required

ClawnchSafeDexScreener

Add later

Liquid ProtocolSnapshotTallyDune

Ignore for now

Stripe AtlasMercury

Closest live example: Pattern closest to Clawnch, Liquid-linked experiments, and tokenized ZHC treasury plays.

Live examples on ZHCs.AI

Clawnch Liquid Autonomopoly

First proof to expose: Show the official pair, holder base, treasury wallet, and the first fee or burn logic publicly.

Agent Treasury Stack

For agents that already earn or control assets and now need capital allocation, custody, reporting, and explicit policy.

Who this is for: Treasury operators, protocol finance builders, and capital-routing experiments.

Required

SafeRobot MoneyDune

Add later

DexScreenerSnapshotTallyDefiLlama

Ignore for now

ClawnchFarcaster

Closest live example: Pattern closest to Robot Money and treasury-first ZHC infrastructure projects.

Live examples on ZHCs.AI

Robot Money Liquid

First proof to expose: Expose treasury policy, wallet holdings, and how fees or deposits translate into visible allocation decisions.

Hybrid OPC to ZHC Stack

For builders starting as a human-led AI company first, then adding agent autonomy, treasury visibility, and optional token layers later.

Who this is for: OPC founders who want the cleanest path from product and revenue to a more autonomous company surface.

Required

AnthropicCursorStripePostHog

Add later

OpenClawMercuryPlausibleBaseScan

Ignore for now

ClawnchSnapshotTally

Closest live example: Closest to the path many AI-first builders take before they expose a public ZHC surface.

Live examples on ZHCs.AI

Felix Juno HireHalo

First proof to expose: Show revenue, product usage, and a repeatable company loop before adding token or governance complexity.

Curated tools

A maintained operating map. Inclusion requires clear relevance to ZHC workflows, public proof, or visible usage in serious builder paths.

Runtime

5 tools

OpenClaw

Autonomous operating core

Self-hosted agent runtime for long-running work, memory, tools, messaging channels, and repeatable skills.

Why it matters: It turns a prompt into an operator. Without a stable runtime, a ZHC is still just a workflow demo.

Live in ZHC production experiments

Observed in live Felix, Juno, Aleister, and HireHalo-style operators

Best for: Running the first ZHC operator or AI CEO.

Best when: Best when you want persistence, multi-channel actions, and publicly visible autonomous output.

Not ideal when: Not ideal when you only need a narrow one-shot workflow or internal automation bot.

FelixJunoAleisterHireHalo

runtimeself-hostedagent

LangGraph

Workflow orchestration

Framework for stateful, long-running agent workflows with controllable graphs and production orchestration.

Why it matters: Useful when you need reliability and auditability before branding the system as a company.

Established developer framework

Production framework with broad developer adoption

Best for: Building reliable multi-step agent workflows.

Best when: Best when your bottleneck is orchestration correctness more than agent identity.

Not ideal when: Not ideal as the only stack if you need a public-facing autonomous company persona right away.

Developer-first ZHC buildersWorkflow-heavy operators

workflowagentdeveloper

CrewAI

Role-based multi-agent teams

Open-source framework for role-based multi-agent systems and task delegation.

Why it matters: Good for turning one founder thesis into a visible team of specialists before deep runtime customization.

Live open-source runtime

Public multi-agent framework with strong community experimentation

Best for: Researcher, writer, coder, and operator agent teams.

Best when: Best when you want explicit roles and handoffs that humans can inspect.

Not ideal when: Not ideal if you need strict financial rails or treasury logic first.

Multi-agent builder teamsResearch-heavy operators

multi-agentrolesworkflow

Anthropic

Production reasoning and operator intelligence

Foundation model layer for reasoning, coding, tool use, and long-form operator work.

Why it matters: Most early ZHCs do not fail because they lack governance. They fail because the operator is not good enough.

Established frontier model provider

Widely used across serious agent products and coding operators

Best for: Builders who need a high-quality operator before they optimize the rest of the stack.

Best when: Best when reasoning quality, coding ability, and tool use matter more than owning the full runtime.

Not ideal when: Not ideal as the only answer if you still need memory, messaging, and orchestration around the model.

FelixJunoOpenClaw builders

modelreasoningcoding

Cursor

Founder + agent shipping surface

AI coding environment for shipping product loops quickly before you over-engineer runtime infrastructure.

Why it matters: Many OPCs become serious before they become autonomous. Cursor is part of that bridge.

Widely used AI coding surface

Observed across fast AI product builders and solo operators

Best for: Solo founders shipping an AI-first product before full ZHC infrastructure.

Best when: Best when time-to-product matters more than agent theater.

Not ideal when: Not ideal if you already need a long-running, self-hosted operator more than a coding cockpit.

OPC buildersAI-first startups

codingopcbuilder

Entity & Payments

4 tools

ClawBank

Agent banking and legal rails

Financial and legal operating system for agents, including bank accounts, wallets, entity formation, and API rails.

Why it matters: A ZHC stops looking like a toy when it can own an entity, bank rails, and programmable payment flows.

Early live infrastructure

Official docs, first live customers, and Manfred company-formation case

Best for: Giving an agent a company shell and money rails.

Best when: Best when you need fiat rails, legal wrappers, and agent-friendly API control.

Not ideal when: Not ideal if you are still exploring whether the project should exist before any entity or bank setup.

ClawBankManfredAgent-native financial stack

bankinglegalpayments

Stripe Atlas

Traditional company setup

Company formation and startup banking pathway for internet businesses that still need a conventional legal structure.

Why it matters: Important for OPC or non-Web3 ZHC experiments that need compliance before crypto-native rails.

Established startup rail

Widely used for internet-native company formation

Best for: Non-Web3 ZHC experiments that need a legal entity.

Best when: Best when your business model is real but your crypto surface is optional or delayed.

Not ideal when: Not ideal if the project is fundamentally on-chain and needs agent-native legal rails from day one.

OPC buildersNon-Web3 ZHC experiments

companylegalstartup

Stripe

Revenue collection rail

Payment and billing rail for products, subscriptions, one-off sales, and clean revenue proofs.

Why it matters: Before a ZHC proves token value, it should usually prove that someone will pay it.

Established internet payments standard

Used as the cleanest public revenue surface across many AI and OPC businesses

Best for: Showing clean revenue before crypto complexity.

Best when: Best when your first proof should be customer payments, MRR, or direct product revenue.

Not ideal when: Not ideal as the only rail if the business is fundamentally on-chain and fee-native.

FelixJunoOPC builders

paymentsrevenueproof

Mercury

Modern startup banking

Startup banking layer for builders who need a real company account before adding agent-native finance.

Why it matters: A broad ZHC stack should include realistic banking paths, not only crypto-native ones.

Established startup banking surface

Widely used by internet-native startups that need real company banking

Best for: OPC and hybrid AI companies becoming more operationally serious.

Best when: Best when you already have legal formation and now need clean banking for revenue and expenses.

Not ideal when: Not ideal if you are still proving whether the product or company loop should exist.

Hybrid OPC buildersInternet-native startups

bankingstartuphybrid

Treasury

2 tools

Robot Money

Agent treasury management

Autonomous treasury vault concept for agent capital allocation, yield exposure, and buyback-burn loops.

Why it matters: A ZHC that earns but cannot allocate capital is still operationally immature.

Early live treasury experiment

Official allocation dashboard, on-chain treasury logic, and tracked protocol design

Best for: Managing agent revenue after it starts earning.

Best when: Best when you already have deposits, fees, or idle treasury that need visible policy and yield logic.

Not ideal when: Not ideal before you have any real treasury inflow to manage.

Robot MoneyJuno-linked treasury experiments

treasuryvaultyield

Safe

Treasury custody

Smart-account treasury infrastructure for multisig custody, policy controls, and transparent asset management.

Why it matters: Before a treasury becomes autonomous, it first needs explicit custody and policy boundaries.

Established treasury standard

Widely used smart-account custody across protocol and treasury operations

Best for: Holding ZHC treasury assets with clear controls.

Best when: Best when multiple operators, treasuries, or signers need visible control logic.

Not ideal when: Not ideal as your only treasury layer if you also need allocation logic and public performance reporting.

Token treasury operationsProtocol finance teams

treasurycustodymultisig

Launch & Markets

3 tools

Clawnch

Agent-only token launch

Agent-native launchpad for autonomous token deployment, fee routing, and self-funding loops.

Why it matters: It is one of the clearest examples of agent-first market formation rather than human-led token marketing.

Live high-activity launch rail

Public token counts, agent fees, volume, and burn statistics on official surfaces

Best for: Agent projects that need an economic surface.

Best when: Best when the token is part of the product loop and fees need to route back to the agent.

Not ideal when: Not ideal if you cannot explain why the token is official, functional, and treasury-aligned.

ClawnchAgent-launched token experiments

launchpadfeestoken

Liquid Protocol

Agent launch infrastructure

Launch and liquidity infrastructure for AI-native assets and autonomous agent experiments.

Why it matters: It shows the bridge between launch surfaces and protocol fee capture, which is central to tokenized ZHC design.

Early but revenue-producing protocol

DefiLlama revenue history plus live agent-linked launches such as AUTONO

Best for: Creating tokenized ZHC experiments with protocol fee trails.

Best when: Best when you want launch infrastructure that already has visible fee history and linked experiments.

Not ideal when: Not ideal if you need a full company workflow before any market surface exists.

AUTONOLiquid ecosystem launches

launchfeesliquidity

Clanker

Social token deployment

Token deployment infrastructure commonly used by Base-native social and agent projects.

Why it matters: Useful when distribution and token creation are tightly coupled inside a social graph.

Established social launch rail

Observed across Base-native social and agent token launches

Best for: Fast token experiments from a social surface.

Best when: Best when narrative distribution itself is part of the launch mechanism.

Not ideal when: Not ideal if you need a heavily curated official launch environment with stronger treasury framing.

Base-native social launchesJuno-style token deployment patterns

launchbasesocial

Governance

2 tools

Snapshot

Off-chain governance

Voting and proposal infrastructure for token communities and early governance experiments.

Why it matters: Good governance starts as visible preference formation before it becomes executable policy.

Established governance standard

Broad public governance usage across token communities

Best for: Testing ZHC community preference before on-chain execution.

Best when: Best when you want to prove community alignment without immediately shipping binding execution.

Not ideal when: Not ideal if the treasury or protocol already needs binding, auditable execution rights.

Token communitiesEarly governance experiments

governancevotingcommunity

Tally

On-chain governance

Governance platform for proposals, delegates, voting, and execution around protocol treasuries.

Why it matters: Once a ZHC treasury becomes meaningful, governance must move from signaling to execution.

Established execution layer

Public governance execution across mature protocol treasuries

Best for: Mature ZHCs that need executable governance.

Best when: Best when treasury motions, delegates, and proposals need a public execution trail.

Not ideal when: Not ideal for projects that are still discovering whether governance should exist at all.

Mature protocol treasury operations

governanceexecutiontreasury

Proof & Analytics

7 tools

BaseScan

On-chain proof surface

Explorer layer for verifying treasury wallets, token contracts, transfers, and entity-linked on-chain activity.

Why it matters: If a ZHC says it is transparent on Base, BaseScan is where that claim should cash out.

Established blockchain explorer

Primary source for wallets, contracts, treasury movement, and holder snapshots on Base

Best for: Verifying official contracts, wallets, and treasury trails.

Best when: Best when you need primary-source on-chain evidence rather than dashboard interpretation.

Not ideal when: Not ideal as the only analytics layer if you also need trend summaries and readable charts.

ZHCs.AI verification flowBase-native projects

explorerproofbase

DefiLlama

Protocol revenue and fee tracking

Protocol analytics platform covering fees, revenue, and other financial surfaces for on-chain systems.

Why it matters: When a ZHC behaves more like a protocol than a SaaS business, DefiLlama becomes the more natural proof layer.

Established protocol analytics layer

Public fee and revenue surfaces used across protocol research

Best for: Protocol-like ZHCs with fee and revenue surfaces.

Best when: Best when you need a public, comparable fee or revenue benchmark for on-chain systems.

Not ideal when: Not ideal for early product companies whose traction still lives mostly in product usage or Stripe revenue.

Liquid Protocol-style fee surfacesProtocol research

revenuefeesprotocol

DexScreener

Token market data

DEX market data for price, liquidity, volume, and trading pairs across crypto-native ZHC assets.

Why it matters: You cannot claim market traction without a clean official-token venue and visible liquidity surface.

Established market surface

Live market data used directly in ZHCs.AI rankings and project monitoring

Best for: Monitoring official-token market signals.

Best when: Best when a token is official enough to deserve price, market cap, and pair-level monitoring.

Not ideal when: Not ideal as the only proof layer for projects that need revenue or user proof, not only market signals.

ZHCs.AIOfficial token monitoring

market-datapriceliquidity

Dune

On-chain analytics

SQL-based on-chain analytics and dashboards for protocol usage, treasuries, users, and fees.

Why it matters: Dune turns on-chain claims into inspectable evidence that a third party can actually verify.

Established analytics layer

Public on-chain dashboards, treasury traces, and usage tables

Best for: Turning ZHC on-chain activity into public dashboards.

Best when: Best when treasury flows, fee events, or user behavior need to become part of your public proof layer.

Not ideal when: Not ideal if your proof layer is mainly fiat revenue and there is little meaningful on-chain state yet.

On-chain ZHC analyticsTreasury and fee dashboards

analyticsdashboardon-chain

TrustMRR

Revenue verification

Public revenue verification surface for AI-native and indie internet businesses.

Why it matters: For non-Web3 or hybrid ZHCs, verified revenue is still the strongest proof-of-life signal.

Live revenue proof surface

Observed in Felix and Aleister-style public revenue proofs

Best for: Showing Stripe-style revenue signals for non-Web3 ZHCs.

Best when: Best when your edge is real cash flow and you want outsiders to trust the number quickly.

Not ideal when: Not ideal if your project has no verified revenue path yet and only wants narrative positioning.

revenueprooffiat

PostHog

Product usage analytics

Product analytics layer for proving usage, retention, activation, and behavior before the company has mature public markets.

Why it matters: Traction is not only revenue. Many serious OPCs and early ZHCs first prove repeated usage.

Established product analytics stack

Widely used event, funnel, and retention analytics for product teams

Best for: Showing product traction before public token or treasury complexity.

Best when: Best when usage, activation, and retention are stronger proofs than market cap.

Not ideal when: Not ideal as the only proof layer once the project is already publicly traded or treasury-heavy.

OPC buildersAI-first product teams

analyticsproducttraction

Plausible

Simple traffic proof

Lightweight website analytics for showing public traffic and top-of-funnel interest without a heavy stack.

Why it matters: Not every builder needs a full analytics stack. Sometimes the right first proof is simply that people are showing up.

Established lightweight analytics

Public or semi-public traffic and visit analytics for simple proof-of-interest

Best for: Simple public proof for landing pages, waitlists, and early content surfaces.

Best when: Best when you need low-friction traffic proof before deep product instrumentation.

Not ideal when: Not ideal when your investors or team need detailed behavior, retention, or cohort analysis.

Early-stage buildersLean landing pages

trafficanalyticslean

Distribution

2 tools

Farcaster

Crypto-native distribution

Open social graph for crypto-native audiences, builder communities, and agent distribution experiments.

Why it matters: A strong ZHC still needs believers, users, and a repeatable narrative channel.

Established social graph

Observed distribution channel for crypto-native builders and product launches

Best for: Building early believers and social proof.

Best when: Best when your audience already lives on crypto-native social surfaces.

Not ideal when: Not ideal as your only growth channel if the project depends on search, enterprise, or broader web audiences.

Crypto-native builder distributionAgent launch audiences

distributionsocialcommunity

Claw Mart

Agent skill marketplace

Marketplace surface for selling agent skills, personas, and digital products in the ZHC ecosystem.

Why it matters: It gives agent capabilities a product shelf, not just a demo thread.

Live monetization surface

Observed as a live skill and persona sales surface inside the ZHC ecosystem

Best for: Monetizing reusable agent capabilities.

Best when: Best when you already have reusable output that can be sold as a skill, bundle, or persona.

Not ideal when: Not ideal if you still need to prove basic product demand before packaging agent output.

Felix ecosystemAgent product monetization

marketplaceskillsrevenue

Human Fallback

1 tools

MoltyCash

Agent-human payments

USDC payment and gig layer for agents hiring humans, routing small tasks, and escrow-style collaboration.

Why it matters: Full autonomy is rarely binary. Human fallback keeps the ZHC moving while the automation frontier catches up.

Early live payment rail

Official docs, live gig surface, and agent-human task payment design

Best for: Letting agents buy human help when full autonomy is not enough.

Best when: Best when agents need verified humans, escrow, or small tasks to unblock throughput.

Not ideal when: Not ideal if your workflow is still fully manual and not yet programmable from the agent side.

MoltyCashAgent-human gig flows

paymentsgighuman