Get ready to understand the real market size, the technology’s maturity, and the crucial factors that will shape investments in robotics and physical AI. If you’re considering investing or just curious about the industry’s true potential, this post will equip you with the knowledge to distinguish fact from fiction.

The Reality Check: How Large Is the Physical AI Market Today?

Jensen Huang’s $50 trillion figure for physical AI touts a massive future, but the current landscape tells a different story. Today, the global installed base of humanoid robots hovers around 16,000 to 20,000 units—a tiny fraction of the trillion-dollar market Huang envisions.

To put it into perspective:

• Current global humanoid robots in operation: ~16,000 units

• Estimated units in operation (generous estimate): ~20,000 units

• Annual production ramp-up: From 150 robots in 2025 to roughly 3,000 per year (based on companies like Figure AI ramping from 12 to 250+ robots per month)

• Deployments in actual industrial settings: Less than 10%, mostly research labs or academic institutions

This stark growth figure underscores a paradox: while companies are ramping up production, actual deployment in manufacturing or service environments remains limited.

Why the Discrepancy?

The market’s hype is rooted in future potential—promises of automation replacing human labor, multi-planetary mining, and AI-driven industries. However, the ground reality is that most robots are in R&D labs, not on factory floors. For example, U.

S. and European companies are focusing heavily on research, while Chinese firms like Unitree and Elon Musk’s Tesla are aggressively reducing costs and building volume, but actual deployment in business operations is still minimal.

Essential takeaway: The market valuation today is largely speculative, based on future ambitions, not current deployment.

The Cost Structure and Value Chain in Physical AI

Here’s what you need to understand: the actual value in building humanoid robots isn’t primarily in the chips—it’s in actuators, mechanical components, and the precision mechatronics.

Breakdown of the Bill of Materials (BOM):

• Actuators and gearboxes: ~60% of total BOM

• Structure and batteries: ~25%

• Sensors and perception systems: ~10-15%

• Chips/computing: ~8% (projected to decrease further from 8% to 5%)

This breakdown challenges the common narrative that semiconductor chips (like Nvidia GPUs) will be the main value drivers. The real profits fuel actuator manufacturing, mechanical precision components, and control systems—areas dominated by Chinese companies like Zua Wei and Innovants, who are vertically integrated and aggressively lowering costs.

Implication for investors:

The future of physical AI is a precision mechatronics challenge, not just a compute or AI software story. Companies that master actuation, mechanical design, and sensing will be the true winners.

The Chinese Advantage

Chinese firms like Unitree and others are significantly reducing costs—slashing robot prices by 50% while maintaining gross margins at around 67%. Their vertical integration and control of raw materials (like rare earth magnets) give them a strategic edge that’s tough to beat.

For example:

Unitree’s flagship robot’s BOM cost dropped from $50,000 to around $9,000 in recent years—an 80% cost reduction, while margins stayed steady.

They manufacture key components in-house, undercutting Western competitors on price and margin.

This price competitiveness, combined with raw material control, means Western OEMs are facing a structural margin squeeze.

The Market’s Actual State: Deployment, Not Debutante Ball

The narrative often centers around impressive demos and pipeline promises. But actual industrial deployment is still in its infancy:

• Production volume of humanoid robots in 2026: estimated at around 20,000 units worldwide

• Units actively used for industrial work: Less than 10% of total units

• Most robots are in research or academic setups, not on assembly lines or warehouses

Key Insight:

The “industry” is still building the ramp rather than saturating markets. The hype around mass deployment is premature; the actual adoption curve in industrial environments is slow and cautious.

Why the $50 Trillion Valuation Is Overestimation

Given current deployment levels, how can the industry be worth trillions? The key factors:

• The installed base of humanoids is tiny—roughly 20,000 globally.

• Most actuation components are manufactured in China, with a dominant cost advantage.

• The majority of revenue comes from deployed robots within China, not a global market infrastructure.

The projected growth rates are wildly exaggerated:

• Tesla: Targeting 50,000 units in 2026, but only shipped hundreds in 2025.

• Unitree: Planning for 20,000 units in 2026, which is small compared to the $50 trillion market size.

Bottom line:

The “$50 trillion” figure is a future narrative built on optimistic assumptions, speculative growth, and unproven deployment levels. The real current market is worth a few billion dollars, not trillions.

Where Is The Actual Value Being Generated?

Deployers, not builders, are extracting market value today. Companies like Amazon and logistics providers are already leveraging automation—using simple, purpose-built robots to save billions in operational costs.

Key points:

• Amazon operates >1 million robots across warehouses, generating $4-10 billion in annual savings—now, not in 2030.

• Most profitable physical AI currently is in logistics and manufacturing, not humanoid service robots.

• The gap between prototype and deployment is massive: most humanoids are still prototypes or research demos.

The takeaway:

Focus on companies that operate robots at scale today. These are the true cash flows, and their profitability insulates them from China’s cost compression or hyped future markets.

The Choke Point: Actuators and Precision Mechanics

The real bottleneck for physical AI’s mass adoption isn’t chips or AI—not even software. It’s precision mechatronics:

Actuators and gearboxes account for roughly 60% of BOM Cost but are also the least scalable or least commoditized.

Building human-like hands or dexterous manipulators remains unsolved at scale.

Companies like Leader Drive dominate the choke point with proprietary gearboxes (harmonic drives), but their valuations are disconnected from current margins and production realities.

Example:

1. Leader Drive trades at a triple-digit price-to-sales multiple, but margins are contracting due to Chinese price pressures.

2. Producing high-precision mechanical parts at scale, with cost advantages, is an insurmountable barrier for Western players lacking Chinese manufacturing efficiency.

The Role of Geopolitics & Raw Material Control

Another critical factor: raw material supply chains—especially magnets and rare earths—are dominated by China.

• Magnet supply chain control creates a significant barrier for Western OEMs.

• Trade wars, tariffs, and export controls further limit access to these critical components.

Implication:

Without raw materials or control over key mechanical components, Western companies cannot compete on price or scale. China’s vertical integration is a near-insurmountable advantage.

The Myth of the “Chat GPT Moment” for Physical AI

Despite the hype, we are still in the early stages of physical AI’s development:

1. No internet-scale grounded dataset for robots—most demos are confined to controlled environments.

2. Dexterous manipulation and proprioception are far from solved; current robots have limited degrees of freedom and sensor feedback.

3. The “human-level” general-purpose robot is likely more than a decade away, making current valuations highly speculative.

In short:

The narrative that physical AI will soon replace humans is premature. The real advances are in cost reduction, component manufacturing, and scaling purpose-built robots for controlled tasks.

What Should Investors Do?

1. Avoid the hype-driven “futures” and focus on the current actual deployment base.

2. Recognize that mass production and cost efficiencies are driven by Chinese manufacturing.

3. Invest in companies with proven, scaled operations in logistics, manufacturing, or deployment rather than speculative OEMs.

4. Be wary of high valuations on pre-revenue or pre-deployment robotics companies.

Two key areas for potential growth and real profit:

1. Operational deployers—like Amazon—already benefiting from automation.

2. Component suppliers with vertical integration and cost advantages—notably in actuators and mechanical parts.

Final Thoughts: Separating Fact from Fiction

The excitement around a $50 trillion physical AI market masks an important reality:

1. We are early in manufacturing ramp-up, not in mass deployment.

2. Most robots today are prototypes or in research.

3. The real profits are being realized by companies that operate and scale existing automation solutions.

Be cautious of falling for inflated valuations based on future promises. Instead, look for scale, margin stability, and proven deployment.

Want to explore more?

Check out the full detailed report I wrote on Substack here.

Follow me for updates and real-time insights on X.

Key Takeaways

• The current global humanoid robot base is around 20,000 units—far from the trillions touted.

• Actual market value is in deployment and operation, not just manufacturing ramp.

• Chinese firms lead due to cost and raw material advantages, making Western OEMs struggle with pricing power.

• The real bottleneck isn’t chips—it’s precision actuators and mechanical components—a chokepoint dominated by Chinese companies.

• Investors should focus on profitable deployers and component suppliers rather than speculative OEMs.

• Stay patient, stay informed, and remember: the hype often outpaces reality. The market’s fundamentals are what will ultimately sustain or crush your investments.

• In this article, I’ve captured my 3 months of real experience building agentic workflows for my crypto and equity research work

• as a researcher, the hardest part is synthesizing myriad data, stats, opinions, and insights into a cohesive story; prior to agents this process took weeks to days depending on the depth of the final output, now I can squeeze the same quality of output to hours and days

• the real deal isn’t setting up the LLM or the agent harness, the real kicker is the second brain - that to me is the single biggest takeaway building a repeatable agentic research model

• In this piece, I drill down the exact systems, sub-systems, and the exact commands you can use to replicate the framework (and apply it to your own unique use cases)

• do note, this is for me, and as such there might be areas you might wanna overlook, I recommend copy pasting the whole article inside your favorite LLM of choice, and then asking him to explain it back, and also interviewing you to build your own custom agentic setup by learning the mental model, architecture, and system wide thinking extracted from my specific approach

happy reading...

Introduction

Every research note you write today starts from zero.

You opened a tab this morning, typed in the token, the sector, the angle you wanted to think through. The model asked you what you meant. You explained the framework. You explained that you cite sources inline, that conviction tiers are High / Medium / Speculative, that you do not use em dashes (yeah ik this is the number one AI giveaway lmao). You spent the first forty minutes of the session building the context the model would forget the moment you closed the tab. When you opened a different tab tomorrow, on a different project, you did the same thing again. Last week, on this same project, you did it for the third time. You have explained your research framework to an AI four times, because it has no memory of the first three.

This is not researching, its paying the same cost over and over for context you have already built, in conversations that compound nowhere. The work you did three weeks ago on this token is buried in a chat history you will never search. The CT take that flagged the kill condition is in a screenshot somewhere on the desktop. The note got published, did well, and is now structurally inaccessible to your own future research. Six months in, you have produced forty research notes, and the cumulative knowledge sitting in queryable form is approximately what it was the day you started.

The real cost of treating AI as a chatbot is not the subscription price, Its the opportunity cost of your time better spent elsewhere doing quality creative stuff.

The alternative is not a better chatbot. It is a different relationship with the tool entirely.

You type `claude` inside a project folder. Before the cursor returns, the agent has read three files. A global identity document at `~/.claude/CLAUDE.md` that tells it who you are, what you are building, what your voice rules are, and what research workflow you follow. A project document at the folder root that tells it the wiki is on v2, that kill-my-thesis returned PUBLISHABLE forty minutes ago, that the next step is voice calibration on draft v1. A memory index of every correction you have made across the prior fifty sessions, including the one from three weeks ago when you flagged a sourcing pattern it had been using wrong. The agent does not greet you. It tells you where you left off, and it tells you what the next step is. The session begins already briefed.

That shift is the conceptual core of this article. From AI as a tab in your browser to AI as an operating layer in your file system. From a tool that forgets you between sessions to infrastructure that compounds across all of them. From re-deriving context every morning to a knowledge environment that the agent reads from and writes to as the primary mode of work.

This article documents that build from scratch. The system has been running in production since January 2026, and what follows is my specific experience creating it from nothing. (note: I have zero coding/tech skills so this is easy to do for anyone).

The endgame of this guide

Before the architecture, the output. Proof before pitch.

The system described here runs two AI agents, five language models, and a stack of data tools. On a typical week, it produces a daily intelligence brief synthesized from five data sources and delivered to Telegram at 6:30 AM IST before markets open, between 8 and 12 research notes across tokens, equities, and macro, an automated evening position alert that pulls live prices against open trades and sends them at 7:00 PM, and a knowledge base with 19 cross-referenced pages across tokens, sectors, theses, and macro frameworks, updated after every session and readable by both agents.

The tracked research record across 41 published calls: 66 percent win rate, 244 percent average return on closed positions.

That is not the output of a researcher using AI as a search assistant. It is the output of an operation where the agent is the primary research operator and the researcher is the editor.

What it costs ($$) to make it happen?

The cost question comes early because you should make the “is this worth my time” decision before you’re halfway through the article. Here is the honest answer response:

Full breakdown with line items in the appendix.

A few notes on the figures, because the cost model is non-obvious and most readers will read the table wrong on first pass. Grok access for CT sentiment and kill-my-thesis comes through the X Premium Plus subscription, not a separate xAI API bill. TradingView MCP is free; the cost is the TradingView Pro subscription required to run the desktop app. Hermes runs locally on a Mac at no additional cost, so the minimum viable build does not require a VPS. A $6 to $12 VPS becomes worth adding once the daemon is producing daily output you depend on while traveling or sleeping, and that decision belongs to Phase 2, not Phase 1.

The minimum viable stack at $51 a month gives you a persistent, identity-aware research agent, CT sentiment via Grok’s native X search, and professional chart analysis via TradingView MCP. That is not a trivial capability set for $51.

The full stack at $150 to $200 a month is what this article documents. It is the operating cost of a solo research operation that produces institutional-grade output across crypto, equities, and macro. For reference, a single Bloomberg terminal seat runs $2,000 a month. A junior research analyst at a fund costs $8,000 to $12,000 a month. The comparison is imperfect but the order of magnitude is real.

What this is and what it is not

This is a system design document. Every section is a layer of a working architecture, documented at the level of specificity required to actually build it. Terminal commands are exact. File paths are real. Cost estimates are pulled from live invoices. The adversarial layer has rejected publishable theses on $ETH, $KAS, and $NEAR in the past 90 days, and the verdicts are quoted in Section 6 with the actual report language rather than paraphrase.

This is not a prompt engineering tutorial. It is not a list of AI tools to evaluate. It is not a speculative vision of how agents might work someday.

The single most important concept in the article is the one already named above. A chatbot takes a message and returns a response. Context resets every session. The AI has no access to your files, no ability to run commands, no persistent state, no memory of what you told it last week. An AI agent embedded in your file system is architecturally different across every one of those dimensions. It reads your identity from a configuration file before every session. It writes and edits files. It executes shell commands. It calls live data tools. It maintains a memory system that persists across sessions and compounds with every correction you make. It is infrastructure, not a tab.

That infrastructure is what this article shows you how to build.

What you need

A Mac is the preferred environment. Linux works for everything in this stack except the TradingView MCP, which requires the Mac desktop application running in remote debug mode. Windows is not covered.

You do not need to write code. You need terminal comfort. If you have ever run `npm install` or `pip install` and edited a plain text configuration file without breaking it, you have the required baseline. Every step in the article is configuration and command execution, not programming.

Plan for 10 to 15 hours of initial setup. Most of that goes into the first pass through Sections 2 through 5: installing Claude Code, building the KMS folder structure, wiring in the MCPs, and configuring the multi-LLM pipeline. After the build is running, the ongoing operating cost is 1 to 2 hours a day, and a meaningful portion of that is reading the morning brief on the phone before the workday begins.

The last requirement is the one most readers underestimate. The willingness to run the system manually before automating it. Sections 2 through 8 describe a manual research workflow. Section 4 (Hermes) describes how to automate it. The automation only works if the manual workflow is clean, and the manual workflow only gets clean by being run by hand for long enough to feel where it breaks. Phase 1 before Phase 2. Always. Section 9 returns to this principle and gives it the weight it deserves.

How this article is structured

Nine sections, an appendix, and a progressive build path threaded through all of them.

Section 1 maps the full architecture: five layers, the two-agent split, the multi-LLM routing logic, and the four knowledge persistence mechanisms. Read it first regardless of where you plan to start building.

Section 2 covers Claude Code. Installation, the CLAUDE.md identity layer, the memory system, the skills framework. This is the foundation. Build it before anything else.

Section 3 covers the KMS, the structured second brain that turns scattered research into compounding knowledge. Folder architecture, the universal project structure, the LLM-maintained wiki, and AGENTS.md as the single source of truth both agents read.

Section 4 covers Hermes, the autonomous agent. Installation, Telegram setup, cron jobs, the auth.json key vault, the Claude Code delegation pattern, and VPS configuration. This is Phase 2 of the build. Sections 2, 3, 5, 6, and 7 work completely without Hermes, and if you are not ready for a VPS or a background daemon on first read, skip Section 4. Come back when the manual system is producing daily output and you have something worth automating.

Section 5 covers the MCP stack: eight data tools that give the agent access to live markets, the data scripts efficiency principle that keeps the cost model bounded, and the TradingView MCP setup that requires the most careful configuration of any tool in the stack.

Section 6 covers the multi-LLM architecture: five models, four roles, and the one structural argument that determines the entire routing logic. This is the most non-obvious chapter and the one where the system’s integrity actually lives. The three real kill-my-thesis verdicts on $ETH, $KAS, and $NEAR are quoted verbatim.

Section 7 covers the research workflow: a nine-step protocol with no-skip rules and a full session walkthrough from project setup to published note with real timings.

Section 8 covers content operations: the publishing sequence, the call tracker, the trade journal, and the flywheel that turns one research session into three publishable artifacts without doubling the production effort.

Section 9 covers where the build is now, what is automated versus still manual, and what the next twelve months build toward. It also closes a loop this introduction opened.

Read in order on first pass. Return to individual sections as reference.

Section 1: The Architecture

The system has five layers. Each one exists because a specific thing breaks without it. Understanding what each layer fixes is more useful than understanding how it works, so start there.

The five failure modes of manual research, and what fixes each:

Fix all five and you have a research operation. Miss any one of them and the system has a hole that shows up in the output.

The five layers

Layer 1: Identity: CLAUDE.md files tell the agent who you are, what rules it follows, what project it is currently working on, and where everything lives in your file system. Two types: a global file that applies to every session, and a project file that applies to the current research folder. The agent reads both before it says a word. The result: every session begins already briefed.

Layer 2: Second Brain: The KMS (Knowledge Management System) is a structured folder architecture that gives the agent a persistent, organized environment to read from and write to. It contains a wiki that grows after every research session, a memory system that survives across sessions, and a single source of truth file that both agents stay synchronized on. This is the layer that makes knowledge compound rather than disappear.

Layer 3: Data: MCPs (Model Context Protocol tools) are the mechanism by which the agent accesses live data. Without them, the agent is limited to its training cutoff. With them, it has real-time access to crypto prices, equity filings, macro indicators, on-chain DEX data, and live chart analysis. Eight MCPs are active in this stack. The data layer is what makes the agent’s analysis current rather than stale.

Layer 4: Intelligence: Four language models, each with a specific role. The model that writes well is not the model that argues most rigorously against its own output. The model with native X search access is not the model with the best knowledge compression. Routing tasks to the wrong model is not just suboptimal, for adversarial work, it is actively harmful. The multi-LLM layer assigns each task to the model structurally suited for it.

Layer 5: Automation: Hermes is the second agent. It runs as a daemon on a server, listens for scheduled triggers and Telegram commands, and executes pipelines without human initiation. Daily intelligence brief, position alerts, wiki updates, skills monitoring, all of it runs without you opening a terminal. This is the layer that makes the system an operation rather than a tool.

The two-agent split

Two agents, one shared knowledge environment, a clear division of labor.

Claude Code is the researcher. Hermes is the operations manager. You are the editor-in-chief.

The shared memory folder is the architectural detail that makes this split work. Both agents read and write to the same physical location. Claude Code writes feedback memories and user profile updates. Hermes writes project event logs and watch condition triggers. Neither agent needs to brief the other, they read the same files.

A note on Hermes for first-time builders: Sections 2, 3, 5, 6, and 7 of this article, covering Claude Code, KMS, the MCP stack, the multi-LLM layer, and the research workflow, are fully functional without Hermes. Hermes is Phase 2. The correct build sequence is to run the manual research system first, understand what each step costs you in time and friction, and then automate what you have proven works. Automating a process you do not yet understand produces faster confusion, not faster output. Skip Section 4 on first read if you are not ready for a VPS.

The multi-LLM logic

One model doing everything is the most common mistake in AI research setups. The reasoning for avoiding it has nothing to do with benchmark scores.

Consider the tasks involved in one research note: searching X for CT sentiment, building a structured knowledge base from raw data, stress-testing the thesis for structural flaws, and writing the final 1,500-word note in a consistent voice. These tasks have different capability requirements. More importantly, one of them, the adversarial layer, has an independence requirement.

If Claude Opus 4.7 synthesizes the wiki and Claude Opus 4.8 runs the kill-my-thesis check, you are asking the same model family, same training data, same RLHF process, same embedded priors, to critique its own output. That is not independence. It is a model reviewing itself with a slightly different temperature setting.

Grok 4 is trained by xAI on different data with different objectives. Its priors are not Claude’s priors. When Grok returns a NEEDS WORK verdict on a thesis that Claude built, that verdict reflects a genuinely different perspective. That is what makes the adversarial layer structurally valid rather than performative.

Cost discipline follows from this routing. Gemini handles Hermes synthesis and workers. Opus is reserved for the deep wiki builds where compression quality is the bottleneck. Grok runs on CT sentiment and kill-my-thesis. 90% of Anthropic token usage is Sonnet 4.6. That is intentional, save the expensive models for the tasks where model selection actually changes the output.

The four knowledge layers

Four distinct persistence mechanisms, each with a different scope and update frequency. Three of them store what the agent knows. The fourth tells it how to behave, and it is the one read first.

The CLAUDE.md hierarchy: the instruction and context stack

Before the agent touches AGENTS.md, WIKI/, or MEMORY/, it reads the CLAUDE.md files. These are plain text documents that scope the agent’s behavior for the current session. They operate at three levels:

• `~/.claude/CLAUDE.md`: global. Your identity, universal voice rules, research principles, the KMS folder map. Applies to every session regardless of which directory you open.

• `~/KMS/CLAUDE.md`: KMS root. System-wide context: cross-project notes, pending work, session closing protocol. Applies to all KMS sessions.

• `~/KMS/[project]/CLAUDE.md`: project level. Status, decisions made, angles explored, kill conditions, what’s next. Applies only to the current project.

The project-level CLAUDE.md is the mechanism that makes every project resumable without re-briefing. Open a token research folder and the agent already knows the wiki is built, kill-my-thesis returned NEEDS WORK on the Toccata sell-the-news risk, and the next step is fixing that section before drafting v1. No recap required.

Every project in the KMS gets its own CLAUDE.md. This is not optional housekeeping, it is the document that accumulates the institutional memory of that specific project across every session you run on it.

The remaining three layers:

AGENTS.md is the single source of truth that both Claude Code and Hermes read. It is human-readable and human-maintained. When it is current, both agents are synchronized without any inter-agent communication.

WIKI/ is what makes this system different from a good note-taking habit. It is not written by you, it is maintained by the agent, updated after every research session, and queryable by every future session. By your tenth token research note, the wiki has ten cross-referenced pages. By your fiftieth, you have institutional memory that no individual session could hold.

MEMORY/ is the compound learning layer. When you correct the agent, wrong approach, wrong format, wrong assumption, that correction gets written to a memory file. Next session, the agent reads it before starting. It does not make the same mistake twice.

The rest of this article builds each of these layers from scratch.

Section 2: Claude Code

Claude Code is a local terminal agent with tool access, persistent context, and a configurable identity layer. It is not a chatbot. The distinction is operational, not semantic, and it changes what the tool is capable of at a fundamental level.

The chatbot vs. agent distinction

A chatbot takes a message and returns a response. That is the entire interaction model. Context resets every session. The AI has no access to your files, no ability to execute commands, no persistent state, no memory of what you told it last week, and no connection to live data. You bring everything to it. It gives you a response. You close the window and it forgets you exist.

Claude Code is architecturally different across every one of those dimensions:

- It runs in your terminal and has access to your file system

- It reads, writes, and edits files directly

- It executes shell commands

- It calls external tools (MCPs) to pull live market data, filings, and on-chain information

- It maintains a memory system that persists across sessions

- It reads your identity and behavioral rules from CLAUDE.md before every session

The practical result: open a Claude Code session inside a research project folder and the agent already knows who you are, what research workflow you follow, what project you are working on, what has been done so far, and what the next step is. It does not ask. It begins from that context.

That is not a better chatbot. It is a different tool.

Installation

Prerequisites: Node.js 18 or higher, npm.

# Install
npm install -g @anthropic-ai/claude-code

# Verify
claude --version

# First launch — will prompt for your Anthropic API key
claude
```

Your API key lives at console.anthropic.com. For most researchers starting out, the $20/month Pro plan is sufficient, it includes a generous token allowance and covers the interactive research sessions that Claude Code is used for. If you hit rate limits regularly or want direct control over model selection, switch to API billing.

Mac users: run from Terminal or iTerm2. VS Code integrated terminal also works. Avoid running Claude Code inside terminal multiplexers with unusual shell configurations on first setup, diagnose the base case first.

The CLAUDE.md system

This is the most important concept in the Claude Code setup. Everything else: MCPs, memory, skills, builds on top of it.

Every session you have ever had with a chatbot required you to re-establish context. Who you are, what you are researching, what format you want, what rules apply, what you covered last time. You did this every single session because the chatbot has no memory of you. The overhead compounds: 5 minutes of context-setting per session, 3 sessions per day, 5 days a week, that is 65 hours a year spent re-explaining yourself to a tool.

CLAUDE.md eliminates that overhead entirely. It is a plain text file that Claude Code reads at the start of every session. The agent arrives already briefed.

Two types, two scopes:

Global CLAUDE.md: `~/.claude/CLAUDE.md`

Applies to every Claude Code session regardless of which directory you open. This is your identity layer, who you are, what universal rules apply, how you work.

What belongs here:

```markdown
# Identity
[Your name, background, what you are building, your platforms and audiences]

# Voice rules
- No em dashes. Ever.
- Claim first, evidence second. Always.
- Source inline: "Per [source], [data]" — never footnotes.
- Specific numbers, ~ for approximations. Never "significant growth."
- Close in one line.

# Research principles
- Data hierarchy: on-chain first, fundamentals second, narrative third
- Conviction tiers: High / Medium / Speculative — publish with one, always
- Kill-my-thesis runs after wiki, before every draft. No exceptions.
- Wiki before draft. No exceptions.

# KMS structure
[Your full folder map — the agent needs to know where everything lives
to navigate your file system correctly]

# Workflow
[The step-by-step research protocol — so the agent follows the same
sequence every session without being reminded]
```

Keep the global CLAUDE.md stable. It contains what is universally true about you and your work. It is not a scratchpad for session notes or project state, that belongs in the project CLAUDE.md.

Project CLAUDE.md: `/KMS/[project-folder]/CLAUDE.md`

Created inside every project folder. Read when you open that project in Claude Code. Overrides global rules where they conflict. Contains everything that is specific to this project and this session.

What belongs here:

```markdown
# Project: Kaspa ($KAS) — CB Token Research
Last updated: 2026-05-28

## Status
| Phase | Status |
|---|---|
| Data collection | COMPLETE |
| CT sentiment (Grok) | COMPLETE — crowding MEDIUM, Kadena comp flagged |
| Wiki | COMPLETE v2 (Toccata sell-the-news risk addressed) |
| Kill-my-thesis | COMPLETE — PUBLISHABLE (v2 wiki) |
| Draft v1 | IN PROGRESS |
| Draft vX-final | PENDING |

## Angles
- Primary: Toccata activation as smart contract entry point, June 5-20 window
- Secondary: ASIC miner centralization — reframe as security feature not risk
- Kill condition: no measurable dev demand within 30 days of Toccata launch

## Key data points
- Price: $0.034, market cap $830M, FDV $1.2B (CMC, May 28)
- Kadena comparable: pumped 40% pre-launch, retraced 60% over 90 days post

## Prior CB coverage
- KAS note May 2025 — did not cross-post to X

## Next steps
1. Fix Toccata sell-the-news section in wiki v2
2. Rerun kill-my-thesis on wiki v2
3. Draft v1 from updated wiki
```

This document is what makes every project resumable in under 60 seconds. Open the folder, open Claude Code, the agent reads the CLAUDE.md, and it knows exactly where you left off. No recap. No re-briefing. The status table is the first thing updated at the start of every session and the last thing updated at the end.

Every project in KMS gets one of these. Token research, equity research, macro notes, builds, general research, all of them. This is not optional.

The memory system

The CLAUDE.md hierarchy covers what is true about you and your projects at session start. The memory system covers what the agent learns during sessions and needs to retain across them.

Physical location: `~/.claude/projects/[hashed-path]/memory/`. In a properly configured KMS setup, this is symlinked to `~/KMS/MEMORY/`, the same folder Hermes reads and writes. One physical location, two agents.

Four memory types:

• user: Who you are, your expertise level, your background, your preferences. Informs how the agent calibrates explanations and recommendations. A CA-qualified researcher with institutional finance experience gets a different level of explanation than someone running their first research project.

• feedback: This is the most important type. Every time you correct the agent, wrong approach, wrong format, wrong assumption, wrong model for a task, the agent writes that correction to a feedback memory file. Every future session reads those files before starting. The agent does not make the same mistake twice across sessions. This is what makes Claude Code behave differently from a chatbot even for identical prompts over time. The corrections compound. By the fiftieth session, the agent has internalized 50 sessions worth of corrections about how you specifically work.

• project: Active project state, decisions made, timelines, catalyst events to watch. Used for things that change relatively quickly and need to be tracked across sessions without polluting the project CLAUDE.md.

• reference: Where to find things in external systems. Which Linear project tracks pipeline bugs. Which Grafana board gets watched during incidents. Which Telegram channel carries position alerts.

Memory files use a standard frontmatter format:

```markdown
---
name: no-em-dashes
description: Rule 1 in writing-style-master.md. No em dashes in any content, any format.
metadata:
  type: feedback
---

Never use em dashes in any written content. Replace with a period, comma,
or colon. No exceptions across Discord notes, Substack essays, X posts,
or internal documents.

Why: Em dashes are explicitly prohibited in writing-style-master.md.
This was a recurring issue before the memory system was established.
How to apply: Before writing any content, scan for em dashes and eliminate.
```

The memory index file: `MEMORY.md`, is always loaded into the agent’s context at session start. It is a one-line-per-memory index pointing to the individual files. Keep it under 200 lines. If it grows beyond that, the index itself becomes a performance problem.

The skills system

Skills are Claude Code’s slash command layer. They are plain text markdown files that get injected into the agent’s context when invoked. Not code, documentation. You write what the agent should do when the command is called, and the agent follows it.

Invoked with a forward slash: `/coinbureau-research`, `/kill-my-thesis`, `/ct-sentiment-grok`.

Active skills in this stack:

Skills live in `~/KMS/TOOLBELT/skills/`. Each skill is a folder containing a `SKILL.md` file and any reference materials the skill needs. The `SKILL.md` is what gets injected into context on invocation.

The value of the skills system is consistency across sessions. The kill-my-thesis protocol runs the same way every time because the skill file specifies exactly how it runs. The coinbureau-research skill ensures the format, conviction tier, and CMC post requirements are followed on every note without the agent needing to remember them from session to session.

Starting your first session

Once Claude Code is installed and your global CLAUDE.md is written, the first session is:

```bash
cd ~/KMS
claude
```

The agent reads `~/.claude/CLAUDE.md` (global identity and rules) and `~/KMS/CLAUDE.md` (KMS root context). It is now operating with your full context loaded.

For a specific project:

```bash
cd ~/KMS/COIN-BUREAU/token-research/kaspa
claude
```

Now it additionally reads the project CLAUDE.md and knows exactly what state this research is in.

The first thing to do in any new session: let the agent read the project CLAUDE.md and confirm its understanding of current status before doing anything. A single prompt: “what is the current state of this project and what is the next step?”, surfaces any drift between what is in the CLAUDE.md and what you remember from the last session. Fix the CLAUDE.md if there is drift. Then proceed.

Section 3: KMS: The Second Brain

Agents are stateless. Every session starts with no memory of the last one. The CLAUDE.md hierarchy and the memory system in Section 2 fix the agent’s behavior, they tell it who you are, how you work, and what rules apply. But behavior is not knowledge. The agent still needs somewhere to put the research itself, somewhere structured enough that future sessions can find it, query it, and build on top of it.

That is what the KMS solves. Not by improving the agent’s memory, but by making its knowledge environment persistent and structured. The agent operates inside a file system that is organized like a research institution rather than a downloads folder.

The core problem

Most researchers using AI today have their knowledge scattered across four locations that do not talk to each other:

• Chat histories that are technically searchable but practically not

• Browser bookmarks that get saved, never reviewed, and never categorized

• Notes apps (Notion, Obsidian, Apple Notes) with no consistent project structure

• Their own heads, which is not a system

The result: every research session starts from approximately zero context. Token X was researched in March. The wiki page on it does not exist because there was no wiki. The on-chain data that supported the thesis is buried in a ChatGPT conversation from week 7. The Tier 1 CT take that flagged the kill condition is in a screenshot somewhere on the desktop. The note got published, did well, and is now structurally inaccessible to your own future research.

Six months in, you have produced 40 research notes and the cumulative knowledge sitting in queryable form is roughly the same as what you started with. You are not compounding. You are re-deriving.

The KMS is the structural fix. One location. Consistent organization. LLM-maintained. Always current.

The Karpathy llm-wiki principle

The conceptual core of the KMS is borrowed from Karpathy’s notion of an llm-wiki: a knowledge base maintained by language models, not by humans. The human validates and edits. The LLM reads, writes, restructures, and queries.

The reason this matters: a wiki maintained by a human has the same problem as every notes app. It decays. You write the page on day one, update it twice, forget it exists by month two, and never look at it again. The wiki and the work drift apart.

A wiki maintained by the agent has the opposite property. After every research session, the agent updates the relevant pages, adds the new data, cites the new sources, links to the new note. The wiki and the work stay in sync because keeping them in sync is built into the workflow rather than left to discipline.

The compound effect is what makes this category-different from a good notes app. By the tenth token research note, the wiki has ten cross-referenced token pages. By the fiftieth, you have a knowledge base that contains competitive context, historical positions you have taken, theses that worked, theses that did not, and the patterns that distinguish the two. That is not something any chatbot can replicate and not something a manual notes practice produces at any volume.

The five top-level folders

The KMS sits at `~/KMS/` and has exactly five top-level folders. The structure is rigid by design, once the agent learns this layout, it navigates the file system without asking.

The brand separation between COIN-BUREAU/ and ROCH-LABS/ is not housekeeping. It is a structural rule. They are different audiences, different voices, different publishing channels, and different conviction frameworks. Research done for one does not automatically become content for the other. Cross-pollination requires a conscious decision, and that decision is easier to make consciously when the folders enforce the separation rather than blur it.

OPERATIONS/ holds the artifacts that are neither research nor content: the call tracker, the trade journal, the invoice templates, the BD pipeline, the X analytics. WIKI/ is covered in detail below. TOOLBELT/ holds the operational infrastructure, scripts, MCP references, skills, the voice master file.

The universal project structure

Every research project, regardless of brand, regardless of asset class, regardless of build type, uses an identical internal folder structure. This is the rule that pays the most compounding interest. Once the agent knows the structure, every project is navigable from the first second.

```
[project-name]/
├── CLAUDE.md                    ← project state, status, decisions, next steps
├── research/
│   ├── raw/                     ← source data: articles, transcripts, market data
│   ├── wiki/                    ← synthesized knowledge base (built before drafting)
│   └── outputs/                 ← all versioned drafts (v1.md, v2.md, v3-final.md)
└── process/
    ├── raw/                     ← AI workflow artifacts: terminal screenshots, MCP outputs
    └── research-process.md      ← AI workflow documentation: tools used, prompts fired
```

The CLAUDE.md at the project root is what Section 2 covers, the resumability document. Below it sit two parallel layers, and the distinction between them is the single most important structural choice in the entire KMS.

The research/ vs process/ separation

This is a content strategy, not housekeeping.

`research/` is the object layer. The actual work product. Source data in `raw/`, synthesized knowledge in `wiki/`, all versioned drafts in `outputs/`. Everything in here is about the asset being researched. A token wiki, an equity model, a macro framework. The output that gets published.

`process/` is the meta layer. How the AI was used to produce the work. Terminal screenshots showing Claude Code mid-session. MCP invocation outputs. Kill-my-thesis verdict documents. The sequence of tools fired, the model routing decisions made, and the verdicts at each step. None of this content is about the asset. All of it is about the workflow.

The reason these have to be physically separated: every `process/` folder is latent content marketing. Documenting how the work was done is itself a publishable artifact, and if it is mixed in with the work it becomes invisible. Pulled out into its own folder with its own discipline, it becomes a second pipeline.

One research session produces three publishable pieces:

1. The research note itself, the primary output, goes to CB Discord or Substack

2. The `research-process.md` documentation, the how-I-researched-this piece, potential Substack essay or YouTube walkthrough

3. The `process/raw/` screenshots, the AI workflow in action, potential X thread

Pieces 2 and 3 cost approximately 10 minutes of overhead per session once the documentation habit is built. Over a year, that overhead produces 50+ secondary content assets that are completely distinct from the research itself. This is what the process/ layer makes structurally possible.

Version control discipline

Inside `research/outputs/`, no draft is ever overwritten. One file per version. Always.

```
research/outputs/
├── kaspa-v1.md            ← first draft: structure and data
├── kaspa-v2.md            ← voice calibration applied
├── kaspa-v3.md            ← bear case sharpened, kill conditions named
└── kaspa-v3-final.md      ← approved, published
```

The `-final` suffix is reserved. It means the article shipped. Anything without it is still draft, regardless of how polished it looks. This is a small discipline that solves a recurring problem: knowing which version is the source of truth six weeks after publication. You go back to the folder, find the `-final` file, and that is the canonical version. Every prior version is preserved for reference, comparison, and the occasional retrospective post.

The same rule applies to wikis. `kaspa-fundamentals-v1.md`, `kaspa-fundamentals-v2.md`. The kill-my-thesis layer in Section 6 frequently sends a wiki back for revisions, and preserving the v1 wiki alongside the corrected v2 is what makes the adversarial process auditable. You can read v1, read the verdict, read v2, and see exactly what changed.

The WIKI/ system

The WIKI/ folder at `~/KMS/WIKI/` is the second brain proper. It is the LLM-maintained, cross-session knowledge base, the artifact that makes 50 research sessions accumulate into something queryable.

Structure:

```
WIKI/
├── index.md          ← master index, read first before every research session
├── log.md            ← append-only session log
├── theses/           ← master thesis pages (AI compute scarcity, BTC reserve asset, etc.)
├── tokens/           ← one page per token researched
├── sectors/          ← sector synthesis pages (RWA, DePIN, stablecoins, AI-crypto)
├── equities/         ← equity research pages (VRT, ORCL, etc.)
└── macro/            ← macro framework pages (yield curve, M2, DXY regimes)
```

The `index.md` is the entry point for every research session. Before the agent starts new work, it reads the index to check whether the topic has already been researched. A new note on Kaspa does not start from zero, it starts from whatever the existing `tokens/kas.md` page contains. A new RWA sector piece reads `sectors/rwa.md` first.

A token wiki page contains everything the agent needs to write or update a note without redoing the data collection:

```markdown
# Kaspa ($KAS) — Wiki

## Thesis
[2-3 sentence structural thesis]

## Key Metrics (as of [date])
| Metric | Value | Source |
|---|---|---|
| Price | $0.034 | CMC |
| Market cap | $830M | CMC |
| FDV | $1.2B | CMC |
| 30D price change | +18% | CMC |

## Protocol Fundamentals
[TVL, on-chain activity, competitive positioning, mining economics]

## Toccata Activation — The Catalyst
[What it is, timeline, mechanism, comparable precedents]

## CT Sentiment (Grok x_search, [date])
- Crowding: MEDIUM
- Bull signal: [top signal]
- Bear signal: [top bear take]

## Kill Conditions
1. [Specific measurable condition that breaks the thesis]
2. [Second condition]
3. [Third condition]

## Prior Coverage
[Links or references to published notes on this token]
```

The index entry for this same token is one line:

```
- [KAS](tokens/kas.md) — Smart contract activation (Toccata) thesis. MED conviction. Entry $0.034. Last updated 2026-05-28.
```

The index is one line per wiki page, sorted by category. The agent reads it in under a second. It is the table of contents for everything you have ever researched.

Initializing the WIKI is two commands:

```bash
mkdir -p ~/KMS/WIKI/{theses,tokens,sectors,equities,macro}
touch ~/KMS/WIKI/index.md ~/KMS/WIKI/log.md
```

The `log.md` is append-only. After every research session, the agent adds a one-line entry:

```
## [2026-05-28] research | $KAS — Toccata activation thesis; kill-my-thesis flagged Kadena sell-the-news comp, wiki v2 PUBLISHABLE
```

The log is the chronological record of every session. The index is the topical record. Together they give you both axes, what was researched when, and what is the current state of knowledge on any topic. By the hundredth session, the log is the most honest research diary you have ever kept, because it was generated as a byproduct of the work rather than as a separate journaling discipline.

AGENTS.md: the single source of truth

One file at `~/KMS/AGENTS.md` that both Claude Code and Hermes read. It contains the full operational state of the system: your identity, the KMS folder map, the active research workflow, the MCP stack with their gotchas, your current open positions with entry zones, the Hermes automation state including every active cron job, and the pending work list.

The discipline is updating it at the end of every significant session. The closing prompt is built into the system: ”Update AGENTS.md with anything that changed today so both agents stay in sync.”

This file is what makes the two-agent architecture work without any inter-agent communication. Claude Code does not message Hermes. Hermes does not message Claude Code. Both of them read AGENTS.md at session start and operate from the same shared state. When AGENTS.md is current, both agents are synchronized. When it drifts, both agents drift in the same direction, which is still better than drifting in different directions.

AGENTS.md is human-readable and human-maintained. The agents read it but neither agent rewrites it autonomously. This is intentional. The single source of truth needs to be auditable, and the only way to keep it auditable is to keep it under your hand.

TOOLBELT/: the operations layer

The last top-level folder is the one that holds the moving parts of the system rather than the knowledge it produces:

```
TOOLBELT/
├── voice-references/
│   ├── writing-style-master.md    ← always read before writing the final draft
│   └── note-template.md           ← scaffold for new research notes
├── mcps/
│   ├── mcps-master.md             ← every MCP with cost, gotchas, call examples
│   └── tradingview-mcp/           ← the most finicky MCP gets its own folder
├── scripts/                       ← Python data collection scripts
│   ├── morning-crypto.py
│   ├── morning-equities.py
│   ├── morning-macro.py
│   ├── kill-my-thesis-grok.py
│   └── ct-sentiment-grok.py
└── skills/                        ← Claude Code skill files
    ├── coinbureau-research/
    ├── kill-my-thesis/
    └── ct-sentiment-grok/
```

The TOOLBELT is what the agent invokes during a session. The scripts are the cost-efficient data collection layer covered in Section 5. The MCP master file is the reference the agent reads before calling any external tool. The skills are the slash command layer. The voice references are read before final drafts.

Putting all of this under a single TOOLBELT folder, separated from research output, means the agent has one place to look for “how do I do this” and another place to look for “what do I know about this.” Mixing the two, putting voice rules inside a research folder, or putting scripts inside an OPERATIONS folder, produces the kind of structural ambiguity that the entire KMS exists to eliminate.

What the structure delivers

Run this system for three months and the second brain stops being a folder hierarchy and starts being infrastructure. New sessions open inside a project and the agent already knows the wiki state, the prior coverage, the open kill conditions, and the next step. New tokens get researched against ten existing wiki pages rather than from a blank context. New theses get drafted on top of a knowledge base that grows after every session rather than disappears after every chat.

The agent is stateless. The environment is not. That is the trade the KMS makes, and it is the trade that turns AI from a tab in your browser into the operating layer of a research operation.

Section 4 covers the second agent: Hermes, that runs in this same environment without human initiation. If you are not ready for a VPS, skip ahead to Section 5: the MCP stack is what gives this knowledge environment its connection to live markets, and it works on Claude Code alone.

Section 4: Hermes: The Automation Layer

A note before you start reading this section. Sections 2, 3, 5, 6, and 7 of this article cover a fully functional research system. Claude Code, the KMS second brain, the MCP stack, the multi-LLM routing, and the eight-step research workflow all run without Hermes. If you are not ready to set up a VPS or run a background daemon, skip this section entirely on your first pass. The system described in the rest of the article works on a Mac alone. Hermes is Phase 2. Come back here when the manual workflow is clean and you have something worth automating.

The reason that callout matters: automating a research process before you have run it manually for a few weeks produces faster confusion, not faster output. The right build sequence is to feel the cost of doing each step by hand, and only then to automate the steps where the cost is structural rather than situational. Most readers who try to set up Hermes on day one quit during the VPS configuration, and they quit having learned nothing about research itself. There is no rush.

The thesis

Claude Code requires a human to start it. Hermes does not.

That is the only distinction that matters operationally, and it is the entire difference between a tool and an agent. Everything else in this section is implementation detail that follows from that one sentence.

Claude Code is interactive. You open a terminal, you type `claude`, the session starts. The agent is capable and present, but it is also waiting. Without you, it does nothing. Most AI products sit in this category, including every chatbot, every IDE assistant, and every research copilot that bills itself as an agent but only runs when you click the button.

Hermes is autonomous. It runs as a daemon on a server. It listens for scheduled triggers and Telegram commands. It executes pipelines without anyone opening a terminal. At 6:30 AM IST it pulls macro data, crypto prices, CT sentiment, and a Gemini synthesis, and the brief lands on your phone before you have brewed coffee. At 7:00 PM IST it checks open positions against live prices and sends the result. None of that requires you to be at your laptop. None of it requires you to remember to run anything.

The shift from interactive to autonomous is what changes the operation from a tool you use into a system that runs.

What Hermes actually is

Hermes is an autonomous agent that runs as a daemon. It can run on a VPS, on a local machine left on overnight, or as a scheduled service. It has three trigger types: cron schedules, Telegram commands sent by you, and event triggers from other pipelines.

In this stack, the division of labor is clean. Hermes handles everything on a schedule or triggered by an event. Claude Code handles everything that requires decision-making alongside a human. There is almost no overlap. Hermes does not draft research notes. Claude Code does not run morning briefs.

The interface is Telegram. Not a web dashboard, not an email client, not a CLI you log into. Every output Hermes produces is delivered to a Telegram chat. Every command you give Hermes is typed into the same chat. This sounds primitive and it is the right primitive: it works on your phone, it works from anywhere, it has a chronological log built in, and it costs nothing to operate.

Installation

```bash
# Install
npm install -g hermes-agent

# Initialize inside the KMS root
cd ~/KMS
hermes init
```

The init command creates the Hermes home directory and the configuration files that govern the agent:

```
~/.hermes/
├── config.yaml      ← daemon configuration, model defaults, schedule registry
├── .env             ← API keys (per-key environment variables)
├── auth.json        ← multi-provider key vault (covered below)
└── skills/          ← Hermes-side skill files, parallel to Claude Code skills
```

Launching Hermes is always from the KMS root:

```bash
cd ~/KMS && hermes
```

The reason for that pattern: Hermes reads AGENTS.md and the KMS folder map at startup. It needs to be launched from a location where the relative paths in AGENTS.md resolve correctly. Launching from elsewhere works but produces confusing errors when a cron job tries to read or write a file at a path that does not exist relative to the working directory.

Telegram bot setup

Hermes has no interface except Telegram, so the bot is not optional. Setting it up is two steps in the Telegram app and one configuration line.

In Telegram, message @BotFather and create a new bot. You get a bot token. Message @userinfobot and you get your chat ID. Drop both into ‘~/.hermes/.env’:

```bash
TELEGRAM_BOT_TOKEN=your_bot_token_here
TELEGRAM_CHAT_ID=your_chat_id_here
```

After that, every cron job, every alert, every status update, every delegated pipeline output lands in that chat. Pin the chat. It becomes your operational dashboard.

API key management: auth.json

This is the configuration detail that goes wrong most often, so it gets explained carefully.

Hermes runs multiple LLMs. Grok 4 for CT sentiment and kill-my-thesis. Gemini 2.5 Flash for the data workers. Gemini 2.5 Pro for morning brief synthesis. Claude Sonnet 4.6 for delegated execution via `claude -p`. Three providers, multiple keys per provider, sometimes a need to rotate keys when one is throttled.

The `auth.json` file at `~/.hermes/auth.json` is the central key vault. It holds a pool of keys for each provider with a simple active/inactive flag:

```json
{
  "xai-oauth": [
    {"key": "xai-...", "active": true},
    {"key": "xai-backup-...", "active": false}
  ],
  "google": [{"key": "AIza...", "active": true}],
  "anthropic": [{"key": "sk-ant-...", "active": true}]
}
```

When a Hermes pipeline needs a key, it follows a three-way fallback in this exact order:

1. Check the environment variable (e.g., `XAI_API_KEY` if running in a shell that exported it)

2. Check `~/.hermes/.env` for the same variable

3. Parse `auth.json` and pull the first key marked `active: true` for the provider

The reason this fallback exists is one sentence of technical detail: terminal commands spawned by Hermes run in fresh shells that do not inherit the Python environment of the parent process, so environment variables exported in your shell config are invisible to those spawned commands. Without the `auth.json` fallback, half the pipelines work in interactive testing and silently fail at 6:30 AM when the cron fires in a shell that has none of your exports. The fallback is what makes the system work in production rather than only when you are watching it.

Practical rule: put every API key in `auth.json` at setup time. Treat the environment variable and `.env` paths as conveniences for local testing, not as the source of truth. The source of truth is ‘auth.json’.

The three active cron jobs

Three scheduled pipelines run in this stack as of May 2026. They are what Phase 2 actually does on a day-to-day basis.

**========== 📷 INSERT IMAGE HERE → png-visuals/visual-08-morning-brief-pipeline.png ==========**

Creating a cron job is one command:

```bash
hermes cron create \
  --schedule "30 6 * * * IST" \
  --command "morning-brief" \
  --name "Morning Brief"
```

The schedule string follows standard cron syntax with an explicit timezone suffix. The command references a registered skill in `~/.hermes/skills/`. The name is what shows up in the Telegram status replies when you ask Hermes what is scheduled.

Listing the active schedule from anywhere:

```bash
hermes cron list
```

Three jobs is the right number. Each one has a clear purpose and a measurable output. Adding a fourth job needs justification beyond “it would be nice to have.” Most readers will start with just the morning brief, run it for a month, and add the evening alert once the brief is working reliably. That is the right pace.

The Claude Code delegation pattern

Hermes is the orchestrator. Claude Code is the executor. The pattern that makes the two-agent architecture work is Hermes calling Claude Code as a subprocess for tasks that require structured file editing.

The canonical invocation:

```bash
claude -p "Update ~/KMS/WIKI/tokens/[token].md with [new data block]" \
  --allowedTools Read,Edit,Write \
  --model claude-sonnet-4-6 \
  --dangerously-skip-permissions
```

What this does: Hermes spawns a non-interactive Claude Code session, hands it a specific prompt, restricts it to the read/edit/write tool set, pins it to Sonnet 4.6 for cost, and skips the interactive permission prompts that would otherwise block the daemon. The Claude Code session runs to completion, writes the file, and exits. Hermes pipes the result to Telegram.

This is Phase 2 in operation. The morning brief uses this pattern for the wiki update phase: Hermes produces the synthesized brief, then delegates the wiki update to Claude Code with the brief content as input. The wiki page is updated by Claude Code while Hermes coordinates the pipeline around it.

The reason this delegation pattern is structurally important rather than a convenience: Hermes is good at scheduling, orchestration, and routine pipelines. It is not as good at structured file edits across a knowledge base. Claude Code is. Asking each agent to do what it is best at, and letting them communicate through the file system rather than through an API, is the design choice that keeps both agents simple. Neither one is asked to be a complete system on its own.

What Hermes cannot do

Two tools in the stack are Mac-only and cannot run inside a Hermes daemon on a Linux VPS:

- TradingView MCP. Requires the Mac desktop application launched in remote-debug mode. Cannot run headless. Cannot run on Linux.

- Llama AI (DefiLlama AI). Browser-based product. Requires an authenticated Mac browser session and the user signed in. Browser automation through Hermes is on the Phase 3 roadmap but not live yet.

Both of these run inside interactive Claude Code sessions on your Mac, when you are sitting at the machine. Hermes handles everything else.

This is not a limitation of the architecture. It is a deliberate split. The chart analysis and the deep on-chain pulls are exactly the steps where you want to be present and looking at the screen anyway. Automating them would deliver no leverage. Automating the morning brief, the position alerts, and the wiki updates is where the leverage actually lives, and that is what Hermes is configured to do.

VPS vs local

The question every reader at this point: do I need a VPS?

Running Hermes on a VPS gives you 24/7 availability independent of whether your laptop is on, asleep, or in another country. Minimum specification: 2 vCPU, 4GB RAM, Ubuntu 22.04 LTS. Hetzner CX22 at €4.50/month (about $6 USD) or DigitalOcean Basic at $12/month. Both are sufficient for the full Hermes workload, including the morning brief pipeline.

The alternative is running Hermes locally on your Mac. Same software, same configuration, same `auth.json`. The only difference: when your Mac is off or asleep, Hermes is not running. Cron jobs scheduled during those windows do not fire. For a researcher who keeps their machine on overnight and is fine missing a morning brief during travel, this is acceptable. For anyone who travels frequently or wants the system to be reliable independent of personal habits, the VPS is the right answer.

The right path for most readers: run Hermes locally for the first month while you stabilize the cron jobs and confirm the pipelines work. Move to a VPS once the system is producing daily output you depend on. The migration itself is straightforward: provision the VPS, copy `~/.hermes/` and the KMS folder, install the Node and Python dependencies, restart the daemon. An afternoon of work, once.

What this gives you

Three cron jobs, one Telegram chat, one daemon running on a $6/month server. The Morning Brief lands at 6:30 AM IST every day. The Evening Position Alert lands at 7:00 PM. The wiki updates itself after every brief without you opening a terminal. The system runs.

The leverage Hermes adds is not faster research. It is research that happens while you are doing other things. The hours you previously spent reading overnight headlines, pulling macro data, checking open positions, and updating the wiki are now hours where the output is already on your phone when you wake up. The agent did the work. You walk in at 7:00 AM and read the brief.

That is the practical end of Phase 2. The system runs without you. You are the editor.

Section 5 covers the data layer that feeds both agents: the eight MCPs, the Python scripts that batch the most expensive calls, and the cost discipline that keeps the whole stack at sub-$250 per month.

Section 5: MCP Stack: The Data Layer

You are about to set up eight data tools and then learn why you should not use most of them for routine data calls. That is not a contradiction. It is the architecture.

MCPs (Model Context Protocol tools) are the mechanism by which an AI agent accesses live data. Without them, Claude Code reasons from its training cutoff: August 2025 for Claude Sonnet 4.6. With them, it has real-time access to crypto prices, equity filings, macro indicators, on-chain data, and live chart analysis. The MCP stack is built for coverage: you configure all eight so that when you need something specific, the tool is already wired in and the agent knows how to call it. But for the daily data collection that runs in every research session, prices, rates, dominance, Fear & Greed, pre-built Python scripts batch those calls into single executions that are faster, cheaper, and more reliable than firing individual MCP calls one by one. The MCPs handle depth and specificity. The scripts handle routine breadth.

That distinction governs how the entire data layer is used.

What MCPs are

MCPs are standardized tool servers. Claude Code connects to them at session start and can call their functions as native tool use, the same way it calls Read or Edit on a local file, except the data comes from an external source. The agent knows the tool’s schema, can pass parameters, and parses the response directly into context.

Configuration lives in `~/.claude/settings.json`. Every MCP registered there is available to Claude Code for any working directory:

```json
{
  "mcpServers": {
    "coinmarketcap": {
      "command": "npx",
      "args": ["@coinmarketcap/mcp"]
    },
    "fred": {
      "command": "npx",
      "args": ["@federal-reserve/fred-mcp"]
    }
  }
}
```

Each entry tells Claude Code how to start the MCP server process. The agent handles the rest, connection, authentication via the key in `.env`, schema discovery, and tool routing.

The active stack

Eight MCPs cover the full data surface of a crypto and macro research operation. The table below is the reference for what each one does, what it costs, and where it goes wrong.

Five of the eight are completely free. The three with usage limits (CMC, Alpha Vantage, FRED) all have pre-built scripts that batch their most common calls into single executions. The only MCP in the stack that requires a paid subscription outside normal API costs is TradingView, and that cost is the Pro plan for the desktop app, not the MCP itself.

The data scripts principle

This is the single most important operational rule in the data layer. Read it once and apply it without exception.

Never call the CoinMarketCap, FRED, or Alpha Vantage MCPs individually when a pre-built script covers the need. One script call returns a full data blob in a single API execution. Ten individual MCP calls return the same data at ten times the rate limit cost.

Three scripts cover the routine data collection for every research session:

```bash
# Crypto: full watchlist prices, BTC dominance, Fear & Greed index, top 24h movers
python3 ~/KMS/TOOLBELT/scripts/morning-crypto.py

# Macro: FRED rates (10Y, 2Y, DXY, Fed funds, M2, balance sheet), yield curve spread, commodities
python3 ~/KMS/TOOLBELT/scripts/morning-macro.py

# Equities: watchlist quotes, top tech movers (NVDA, AMD, MSFT, GOOGL, META)
python3 ~/KMS/TOOLBELT/scripts/morning-equities.py
```

Each script returns a structured JSON blob saved directly to `research/raw/`. The agent reads it, parses it, and proceeds to the next step. Total execution time for all three: under 90 seconds.

Call MCPs directly only for what the scripts do not cover:

- SEC EDGAR: specific filings by CIK or ticker

- Financial Datasets: insider transactions, KPI tables, institutional holdings

Everything else runs through the scripts.

One practical note for pre-listed tokens, tokens not yet on CoinMarketCap or trading only on a single DEX. The morning-crypto.py script has a `DEX_OVERRIDES` dictionary for exactly this case. Add the token address and the GeckoTerminal pool URL, and the script pulls the price from the pool directly rather than CMC. This is how tokens like $POD were tracked before their CMC listing.

TradingView MCP: setup and capabilities

TradingView MCP is the most capable tool in the stack and the most specific to configure. It controls a live TradingView Desktop instance via remote automation, not a web scraper, not an API, but direct automation of the running application.

The single most common mistake: launching TradingView by double-clicking the app. That opens TradingView without the remote debug port active. The MCP cannot connect to a standard TradingView session. It needs to be launched via the debug script every time:

```bash
~/KMS/TOOLBELT/mcps/tradingview-mcp/scripts/launch_tv_debug_mac.sh
```

Run this in a separate terminal before starting Claude Code. TradingView opens with the debug port active. Claude Code connects through the MCP. From that point, the agent can control the chart directly.

Capabilities once connected:

```
chart_set_symbol       → switch to any ticker (BTC/USDT, AAPL, DXY)
chart_set_timeframe    → 1m, 5m, 1h, 4h, 1D, 1W, 1M
chart_manage_indicator → add, remove, configure indicators by full name
data_get_study_values  → pull current numeric values from any visible indicator
data_get_ohlcv         → pull price bars with summary=true for a compressed view
capture_screenshot     → save chart screenshot to process/raw/
alert_create           → set a price alert from the agent
pine_set_source        → inject Pine Script code
pine_smart_compile     → compile and check errors
```

A typical chart analysis sequence for a token research session:

```
chart_set_symbol → "KASUSDT" on Binance
chart_set_timeframe → "1W"
chart_manage_indicator → add "Volume Profile Fixed Range"
chart_manage_indicator → add "Relative Strength Index"
data_get_study_values → pull RSI value and volume profile levels
capture_screenshot → region: "chart", save to kaspa/process/raw/tv-weekly-2026-05-28.png
```

The screenshot saves to `process/raw/`, the AI workflow folder, not the research data folder. Chart analysis screenshots are AI workflow artifacts. The data they contain (key levels, RSI reading, volume nodes) gets written into the wiki. The image itself is process documentation.

**For Linux and Windows users:** TradingView MCP is not available outside Mac. For chart analysis, the TradingView web platform covers basic needs. Alpha Vantage via the morning-equities.py script provides technical indicator data programmatically. The rest of the stack, all seven other MCPs, work on any platform.

MCP installation: general pattern

Most MCPs in this stack are npm packages with a standard registration pattern. The exact package name varies by MCP, check the documentation for each one, but the structure is consistent:

```bash
# Install the MCP package globally
npm install -g @provider/mcp-package-name

# Or run without installing via npx (simpler, slightly slower at first call)
# No install step needed — add directly to settings.json

# Register in ~/.claude/settings.json
{
  "mcpServers": {
    "provider-name": {
      "command": "npx",
      "args": ["@provider/mcp-package-name"],
      "env": {
        "API_KEY": "your-key-here"
      }
    }
  }
}
```

API keys go in the `env` block of the settings entry, or in a `.env` file that the MCP process reads at startup. Check each MCP’s documentation for which pattern it expects.

Before invoking any MCP in a research session, read `~/KMS/TOOLBELT/mcps/mcps-master.md`. It documents every active MCP with its exact call syntax, rate limits, common errors, and the workarounds that have been found in production. The gotcha column in the table above is the summary. The master file is the detail.

What the data layer gives you

Eight tools covering the full surface of a professional research operation. Real-time crypto markets. SEC filings from the last 24 hours. Macro data updated as FRED publishes it. Live chart analysis with indicator values pulled directly into the agent’s context. Pre-listed token prices handled via GeckoTerminal through the DEX_OVERRIDES dictionary in morning-crypto.py.

The agent does not browse. It calls structured tools and receives structured data. That data goes directly into `research/raw/`, feeds the wiki build, informs the kill-my-thesis adversarial check, and ultimately shows up as sourced claims in the published note.

Section 6 covers the intelligence layer that processes this data, the four-model pipeline where each model is assigned the task it is structurally best suited for.

Section 6: Multi-LLM Architecture

Using one model for everything optimizes for convenience. Routing tasks to the model structurally best suited for each one optimizes for output quality. The difference between the two approaches does not show up on benchmark leaderboards. It shows up in win rate.

This section covers the four-model stack, the routing logic that assigns each task to the right model, and the one structural argument that determines the entire architecture: the model that builds the wiki cannot be the model that adversarially checks the wiki, because they are the same model.

That argument is the philosophical core of this entire article. Everything else in the stack is configuration. This is the part that has to be reasoned about.

Why task-model matching matters

Consider the tasks inside a single research note. The agent needs to search X for CT sentiment, find Tier 1 takes, and assess crowding. It needs to compress raw data from 12 sources into a 2,000-word structured wiki. It needs to stress-test the resulting thesis for structural flaws, missing data, and unstated assumptions. It needs to write the final 1,500-word note in a consistent voice with no em dashes, every claim sourced, and the bear case named.

These four tasks have different capability requirements. The model with native X search access is not the model with the strongest knowledge compression. The model that writes well is not the model that argues most rigorously against its own output. The model with the best cost-to-quality ratio for routine work is not the model you want running the once-a-day synthesis where compression quality compounds across the entire brief.

Routing all four tasks to the same model is the default behavior of every chatbot-style AI product. It is also the source of the most common failure mode in AI research: the agent that is fine at everything and excellent at nothing, producing notes that read like they were generated rather than reasoned through.

The fix is not finding a better single model. The fix is treating model selection as routing.

The independence problem

One of the four tasks above carries a requirement that the other three do not. The adversarial layer (kill-my-thesis) must be structurally independent from the synthesis layer (wiki building). If it is not, the entire adversarial step is performative rather than functional.

Here is the failure mode in concrete form. Claude Opus 4.7 builds the wiki. The wiki contains the thesis, the data, the bull case, the kill conditions. You then ask Claude Opus 4.8 to act as a hostile counterparty and tear the wiki apart. Opus 4.8 reads the wiki, identifies some surface flaws, returns a verdict, and you proceed to draft.

The problem is that Opus 4.8 and Opus 4.7 are the same model family. Same training corpus. Same RLHF process. Same embedded priors about what counts as a strong argument, what counts as a weak one, and what counts as a reasonable extrapolation from incomplete data. When the synthesis model writes “the catalyst is structurally bullish because of X, Y, and Z,” the adversarial model from the same family is predisposed to find X, Y, and Z reasonable. It was trained to. It will catch typos and obvious gaps. It will miss the assumptions that the entire family was conditioned to make.

That is not independence. It is a model reviewing itself with a slightly different temperature setting.

Grok 4 is built by xAI. It was trained on different data with different objectives by a different team with a different worldview about what an honest argument looks like. Its priors are not Claude’s priors. When Grok returns a NEEDS WORK verdict on a thesis Claude built, that verdict reflects a genuinely different perspective rather than a same-family second opinion. The independence is architectural, not stylistic.

This is the argument that determines the entire model stack. The synthesis layer uses Claude. The adversarial layer cannot use Claude. The two layers have to be from different model families or the integrity of the adversarial step collapses.

The five-model stack

Grok 4 (xAI). Role: CT/X sentiment and adversarial kill-my-thesis.

Grok has two roles in this stack and both depend on the same property: it is outside the Claude family.

For CT sentiment, the additional reason is functional. Grok has native X search. Claude does not. If you want overnight X chatter on a token, the Tier 1 accounts that have weighed in, the crowding level, and the bull/bear takes that are circulating, Grok is the only model that can pull that data directly. Every other model in the stack would need a web search wrapper that returns lower-fidelity results.

When CT sentiment runs: before building the wiki for any token, equity, or macro note. After raw data collection, before synthesis. Always.

```bash
python3 ~/KMS/TOOLBELT/scripts/ct-sentiment-grok.py \
  'KAS Kaspa Toccata smart contracts' \
  'kaspa/research/raw/ct-sentiment-grok.md'
```

The topic string matters. “KAS Kaspa” is not enough. “KAS Kaspa Toccata smart contract activation sell-the-news risk” gives Grok the search angle and produces a meaningfully sharper output. Be specific.

A typical Grok CT output (abbreviated, with handles redacted):

```
## CT Sentiment, $KAS (Kaspa)
Date: 2026-05-28
Crowding level: MEDIUM

Bull signals:
- Toccata activation expected June 5 to 20 window. Smart contract devs
  already building on testnet (per @[handle], 1.2K likes on thread).
- ASIC miner centralization narrative reversal: centralization framed
  as security feature, not a risk (per @[handle], 847 likes).

Bear signals:
- Sell-the-news risk flagged via Kadena comparable. PoW chain that added
  smart contracts in 2022 pumped 40% pre-launch, retraced 60% over 90 days
  post-launch. Cited by multiple Tier 1 accounts.
- No measurable dev demand data for Kaspa smart contracts yet.
  Toccata could launch to silence.

Tier 1 take:
- @[handle]: "Toccata is Kaspa's Ethereum moment or its Kadena moment.
  We'll know in 30 days."
```

Cost: $0.10 to $0.50 per run. Runs on every research note. Non-negotiable.

For the adversarial layer, Grok runs the same way. After the wiki is built, before the first draft, Grok reads the wiki and produces a structured seven-section report. The primary output is a Key Line Audit: the weakest claim in the thesis’s supporting argument, the specific data that would confirm it, and the specific data that would invalidate it. The secondary output is the verdict (PUBLISHABLE, NEEDS WORK, or DO NOT PUBLISH), plus three kill conditions and a structural bear case.

```bash
python3 ~/KMS/TOOLBELT/scripts/kill-my-thesis-grok.py \
  'kaspa/research/wiki/kaspa-fundamentals.md' \
  'kaspa/research/raw/kill-my-thesis-grok.md'
```

Cost: $0.50 to $2.00 per run. Runs on every research note. The win rate of this entire system depends on this step functioning correctly.

What the adversarial layer actually catches

The verdicts below are real outputs from kill-my-thesis runs on three of the last research notes produced by this system. The language is taken from the actual reports, not paraphrased.

$ETH, May 2026. Verdict: NEEDS WORK.

> L2 fee bleed is not addressed in the thesis. CROPS is cited as a bullish catalyst but the source is a blog post, not a protocol mandate. No quantified timeline for revenue recovery. Vyper FV timeline is speculative. The 3-month estimate has no team confirmation.

What this caught: a bullish thesis on ETH built around CROPS and a revenue recovery story, with the bullish catalysts treated as scheduled rather than aspirational. The CROPS reference was a blog post, not an EF mandate. The Vyper formal verification timeline came from estimation, not confirmation. The note was rewritten to acknowledge both. It published with a Medium conviction tier instead of High.

$KAS, May 2026. Verdict: NEEDS WORK.

> Sell-the-news risk from the Kadena comparable is absent. Kadena added smart contracts in 2022, pumped 40% pre-launch, retraced 60% over 90 days post-launch. No developer demand data for Kaspa smart contracts exists. Toccata could launch to silence.

What this caught: the Toccata thesis was framed as a smart contract activation that would bring developer activity to Kaspa. The Kadena precedent (a PoW chain that added smart contracts to no real developer demand) was not in the wiki. The wiki v2 added the comparable with specific numbers (40% pre-launch pump, 60% retracement over 90 days) and a kill condition: no measurable dev demand within 30 days of Toccata launch. Kill-my-thesis returned PUBLISHABLE on the revised wiki.

$NEAR, May 2026. Verdict: NEEDS WORK.

> More than 50% of NEAR Intents volume is CEX arbitrage wash volume. The thesis cites $72M/day as proof of product-market fit but does not adjust for wash. Zero guaranteed token value capture despite real AI product.

What this caught: a NEAR thesis built on AI Intents traction, with $72M/day in volume cited as evidence the product was working. The verdict flagged that more than half of that volume was CEX arbitrage rather than organic activity, and that the underlying token had no guaranteed value capture mechanism regardless of how well the product performed. The note was restructured around the qualified version of the volume number and the explicit token value capture question.

All three of these notes shipped. None of them shipped the way they were originally drafted. The adversarial layer is not theater. It is the step that changes what gets published.

If the synthesis model had also been the adversarial model, none of these three verdicts would have looked the same. Same family, same priors, same blind spots. The independence is what produced the catches.

Gemini 2.5 Pro + Gemini 2.5 Flash (Google). Role: morning brief synthesis and data workers.

The Hermes automated pipeline runs on Google’s Gemini family. Five data workers (crypto, equities, macro, YouTube, web news) run on Gemini 2.5 Flash in parallel. The brief synthesis pass runs on Gemini 2.5 Pro. Validation and scoring passes run on Gemini 2.5 Flash.

The reason Google rather than Anthropic for the Hermes pipeline is a billing constraint worth being explicit about. Calling the Anthropic API directly from Hermes draws from a separate “extra usage” credit pool, not the Claude Max plan that covers interactive Claude Code sessions. The Max plan is unaffected by Hermes calls only when Hermes invokes Claude Code via the `claude -p` CLI subprocess, not via direct API. Gemini through Google AI Studio billing is cost-effective for the synthesis volume and sidesteps the credit pool problem entirely.

Model IDs: `gemini-2.5-pro` (synthesis), `gemini-2.5-flash` (workers, validation)

Claude Opus 4.7. Role: heavy wiki synthesis in Claude Code sessions.

Opus 4.7 is reserved for wiki builds inside interactive Claude Code sessions where the source set is large enough that compression quality is the bottleneck. For most standard research sessions, Sonnet 4.6 handles wiki building. Opus is pulled in when the source volume is deep enough that compression failure shows up in the output.

Model ID: `claude-opus-4-7`

Cost discipline: Opus is expensive per token. It runs on selected deep wiki builds, not as a daily default. The morning brief synthesis has moved to Gemini, so the Opus budget is available for the rare deep research session where it earns its cost.

Claude Sonnet 4.6. Role: research, drafting, file editing, everything interactive.

This is the workhorse. Every interactive Claude Code session runs on Sonnet 4.6 by default. MCP calls. File reads and writes. Research-process.md updates. Wiki building (when not delegated to Opus). Article drafting. Code review. Everything that is not explicitly routed to another model goes here.

Model ID: `claude-sonnet-4-6`

The reason Sonnet rather than Opus for the bulk of work: cost and diminishing returns. Sonnet 4.6 runs at a fraction of Opus pricing with roughly 90% of the output quality on research and writing tasks. The remaining 10% of quality difference is real but only matters on a small subset of tasks. Routing everything to Opus produces marginally better output at multiple times the cost. Routing everything to Sonnet produces strong output at sustainable cost. Reserving Opus for the few tasks where the quality delta is structural (synthesis, primarily) captures the upside without the bleed.

The routing table

The full task-to-model mapping, in one place:

The design principle compressed into one line: the synthesis layer and the adversarial layer never use the same model family. That is the integrity of the architecture. Everything else is cost optimization.

Cost discipline

The reason this routing matters financially: model selection determines the monthly cost of the entire system more than any other variable.

Sonnet 4.6 handles roughly 90% of token usage across the stack. Interactive Claude Code sessions, wiki edits, draft generation, file management. All Sonnet. The bulk of the cost lives here, and Sonnet is priced to make that bulk sustainable.

Opus 4.7 runs on selected large wiki builds in Claude Code sessions. Roughly 2 to 3% of Anthropic token usage. The cost per call is high, but the call frequency is low, so the absolute monthly cost stays bounded. Morning brief synthesis has moved to Gemini 2.5 Pro, billed through Google AI Studio at a rate that keeps the Gemini cost line modest relative to what Opus synthesis was costing.

Grok runs on every CT sentiment and every kill-my-thesis. Roughly 5% of total spend, but a critical 5%. The cost is $0.10 to $2.00 per run, which is meaningful, but the per-note ceiling is around $2.50 across both Grok calls combined. On 30 research notes per month, that is $75 worst case. The win rate improvement pays for it many times over.

The rule, stated simply: expensive models run only on the tasks where model selection materially changes the output. CT sentiment changes when you switch from Claude to Grok (because Claude does not have X search). Adversarial checks change when you switch from Claude to Grok (because of independence). Brief synthesis in Hermes runs on Gemini Pro: billing and volume both fit better outside the Anthropic stack. Wiki synthesis in Claude Code sessions runs on Opus when source volume warrants it. Article drafting does not meaningfully change between Sonnet and Opus. So drafting runs on Sonnet and the budget gets spent where it produces a different output.

This is what keeps the full stack at sub-$250 per month. The routing is not just an architectural choice. It is the cost model.

What this layer gives you

Five models, four roles, one structural rule: the model that synthesizes the thesis cannot be the model that adversarially checks it. Grok handles the independence-critical work because it is outside the Claude family. Gemini 2.5 Pro handles Hermes synthesis because billing and volume both fit better outside the Anthropic stack. Opus handles deep wiki compression in Claude Code sessions when source volume warrants it. Sonnet handles the bulk of interactive work at the right cost-to-quality ratio.

The three real kill-my-thesis verdicts on $ETH, $KAS, and $NEAR are the proof that the architecture works as designed. Same-family critique would have missed those catches. Cross-family critique caught all three. The notes shipped sharper for it, and the win rate of the system depends on this layer holding.

Section 7 covers the research workflow that ties all of this together: a nine-step protocol that routes each step through the right model and the right tool, with no-skip rules and a full session walkthrough from first command to published note.

Section 7: The Research Workflow

Nine steps. Some are non-negotiable. Some adapt by research type and by whether Hermes is running. Every shortcut in this sequence has been tested and found to degrade output quality, usually visibly by the time the note is published.

This section documents the protocol and then walks through a complete session from project setup to published note with real timings. The steps are the architecture. The walkthrough is what they feel like to run.

Where research sessions come from

Research sessions are not triggered by any single upstream system. They are triggered by whatever catalyst makes a topic worth a fresh pass: a CB community member asking for more depth on a token they hold, an X post that surfaces a thesis angle, a macro release that opens a window, a position in the trade journal nearing a catalyst date. The QCOM edge inference angle in late May 2026 came from a morning brief that flagged @karpathy’s 60/40 inference shift thesis and a QCOM +11.6% Friday move. The $OCT research had nothing to do with the morning brief. Both were equally valid sessions.

The morning brief is a parallel intelligence layer, not a workflow trigger. It runs daily at 6:30 AM IST and reads two curated streams (selected YouTube channels and X handles), synthesizes the past 24 hours of relevant output, and surfaces research ideas, tokens, equities, and macro angles worth investigating. The output lands in Telegram and feeds `~/KMS/OPERATIONS/intelligence/idea-tracker.md`. Some of those ideas become research sessions. Most do not. The brief is one input among several.

The workflow below describes what happens once a topic has been chosen, regardless of how it surfaced.

Phase 1 vs Phase 2 readers

Two reader states for this section, and the difference is narrower than it sounds.

Phase 1 (no Hermes yet): Every research session starts without baseline market data already in hand. You run the data collection scripts at session start to pull current prices, macro context, and equity quotes. You invoke ct-sentiment-grok.py directly from the terminal.

Phase 2 (Hermes running): Hermes ran the same data collection scripts as part of the morning brief at 6:30 AM IST. The baseline market data is already in your Telegram. When the research session starts later in the day, you reference that data as background context rather than running the scripts again. CT sentiment is invoked by sending Hermes a Telegram command.

The distinction is about data efficiency, not workflow triggering. Phase 2 saves the cold-start data pull. The targeted MCPs for the specific research topic and the actual research steps look the same in both phases.

Step 1: Setup

Create the project folder in the correct KMS location. The location is determined by brand and asset class.

```bash
# CB token research
mkdir -p ~/KMS/COIN-BUREAU/token-research/kaspa/{research/{raw,wiki,outputs},process/raw}

# ROCH Labs equity research
mkdir -p ~/KMS/ROCH-LABS/equity-research/QCOM/{research/{raw,wiki,outputs},process/raw}

# General research
mkdir -p ~/KMS/RESEARCH/agent-first-stack/{research/{raw,wiki,outputs},process/raw}
```

Create CLAUDE.md at the project root. Populate it with the project name, initial status (all phases PENDING), and a blank next steps section. This file is updated at every step throughout the session. It is not a one-time setup artifact.

Create `process/research-process.md` immediately. Log the session start: what you are researching, why, what the first step is. Update it at every decision point. Not at the end. Throughout.

Open Claude Code from the project folder:

```bash
cd ~/KMS/COIN-BUREAU/token-research/kaspa
claude
```

The agent reads the global CLAUDE.md, the KMS root CLAUDE.md, and the project CLAUDE.md in that order. It knows who you are, what system it is operating in, and what project it just opened. Start.

Step 2: Data collection

Phase 2 path. If Hermes is running, baseline market data from the morning brief is already in Telegram. You have current prices, macro context, equity quotes, and overnight signals without running anything. Use that as background context. The morning brief also includes a watchlist status table with every open position, which is useful when the research topic is a token already in the journal.

Then run the targeted tools for the specific research topic.

Phase 1 path. Run the data scripts manually at session start to pull the same baseline data Hermes would have generated:

```bash
python3 ~/KMS/TOOLBELT/scripts/morning-crypto.py
python3 ~/KMS/TOOLBELT/scripts/morning-macro.py     # if macro context is relevant
python3 ~/KMS/TOOLBELT/scripts/morning-equities.py  # if equity context is relevant
```

Each script returns a structured JSON blob saved to `research/raw/`. Total execution time for all three: under 90 seconds. Then proceed to the same targeted tools Phase 2 users would call.

Targeted tool priority order, by research type.

For tokens:

1. CoinMarketCap or CoinGecko: confirm price, market cap, FDV, circulating supply

2. Llama AI (browser-based): TVL, protocol revenue, competitive intel

3. TradingView MCP: chart analysis, key levels, indicator readings

4. Article Extractor: project documentation, recent research reports, news

5. YouTube Transcript: team presentations, podcasts, analyst takes

One note for pre-listed tokens not in CoinMarketCap: morning-crypto.py has a `DEX_OVERRIDES` dictionary that points to GeckoTerminal pool URLs. Add the token there and the script pulls the price from the DEX pool directly.

For equities, replace items 2 and 3 with SEC EDGAR (10-K, 10-Q, 8-K, earnings transcripts) and Financial Datasets (earnings, KPIs, insider trades). For macro notes, FRED covers most of the structural data and YouTube Transcript covers the analyst commentary.

Everything that informs the wiki must be saved to `research/raw/` before the wiki is written. No drafting from memory or from browser context that was not exported.

Llama AI: the honest manual bottleneck

Llama AI is built by DefiLlama and is not a chatbot trained on on-chain data. It is an agent harness that queries live data in real-time. When you type a research prompt, it pulls from DefiLlama’s full dataset (TVL, protocol revenue, fee data, chain comparisons), reaches into Dune Analytics for custom on-chain queries, queries block explorers to analyze smart contracts and transactions directly, and can cross-reference X. That combination, live multi-source on-chain intelligence from a single prompt, is not replicated by any MCP in this stack. Llama AI gives you protocol economics, competitive positioning, and smart contract behavior in one pass.

For any token research note where the thesis depends on protocol fundamentals, the Llama AI pull is the single most informative data source in the pipeline. The friction is worth tolerating because what it returns is not available elsewhere at the same depth.

It also has no MCP. It runs in a browser. It requires an authenticated session. The output has to be manually exported as markdown and saved to `research/raw/` by hand.

This is the last remaining manual step in the data collection pipeline, and the article will not paper over it. Both Phase 1 and Phase 2 users hit the same friction here. Hermes cannot run Llama AI on a VPS. Claude Code cannot trigger it through an MCP. You open the browser, type the prompt, wait for the response, copy the markdown, paste it into a file in `research/raw/`. That is the workflow.

Browser automation for Llama AI is on the Phase 3 roadmap. The plan is documented: Hermes opens a browser session via the browser-use Python library, logs into Llama AI with stored credentials, types the prompt, polls for completion, saves the markdown, and pings Telegram when done. Until that ships, the manual step stays. Plan around it. Allocate five to ten minutes per research session for the Llama AI loop and do it once, not iteratively.

Step 2b: CT sentiment

This step has gone through three versions. The current one matters because it is the version this stack actually runs.

Stage 1 (abandoned): A bun-based CLI skill that called the X API directly. Technically correct, structurally too expensive. X API credits burned faster than the signal justified, and the cost per CT sentiment run made it impractical to run on every note. Pulled from the workflow within weeks of trying it.

Stage 2 (transitional): Llama AI manual x-search. Llama AI has an x-search capability built in, and the monthly subscription was already paid. The workflow: open Llama AI in browser, run the CT sentiment prompt, copy the markdown, paste into `research/raw/ct-sentiment.md`. It worked. The friction was the manual copy step on every research session, which compounded across multiple notes per week.

Stage 3 (current, since May 2026): Grok 4 via Hermes. The current flow is the cleanest of the three and the one that ships.

For Phase 2 users, the invocation is a single Telegram message to Hermes:

```
run ct research on kaspa
```

Hermes interprets this as a request to run the ct-sentiment-grok skill, fires the script with the correct topic string and output path, and the markdown lands directly in the project’s `research/raw/ct-sentiment-grok.md`. There is no Telegram notification when it completes. This is not a brief, it is a targeted research tool. The output goes to the file system, Claude Code reads it from there in the next interactive session.

For Phase 1 users, run the script directly from the terminal:

```bash
python3 ~/KMS/TOOLBELT/scripts/ct-sentiment-grok.py \
  'KAS Kaspa Toccata smart contracts' \
  'kaspa/research/raw/ct-sentiment-grok.md'
```

Same output, same destination, same downstream behavior. The Hermes wrapper is convenience, not a different process.

The topic string is the most important parameter. “KAS Kaspa” gives Grok a broad search. “KAS Kaspa Toccata smart contract activation sell-the-news risk” gives it a focused one and produces a meaningfully sharper output. Be specific.

CT sentiment runs on every token, equity, and macro note. It is skipped for builds and general research projects that do not map to a tradeable instrument.

Step 3: Wiki first

Build the wiki before writing a single word of the note. Not after. Not in parallel. Before.

The wiki is not a draft. It is a structured knowledge dump: all the data organized, all sources cited, all angles mapped, every kill condition named. It is the document the draft is written from. The quality of the wiki determines the quality of the draft more than any other single variable.

For token, equity, and macro research: `research/wiki/[name]-fundamentals.md`. Structure: opening thesis, key metrics table with sources, protocol fundamentals or business model breakdown, catalyst analysis, CT sentiment section (crowding level, top signals, Tier 1 takes), kill conditions (specific and measurable, not vague), prior coverage notes.

For builds: two files. `research/wiki/[name]-spec.md` (technical specification) and `research/wiki/[name]-context.md` (strategic positioning, differentiation, reader framing).

Good wiki, 2-hour draft. Bad wiki, 6-hour draft with data holes and a kill-my-thesis NEEDS WORK verdict. The time invested at this step is recovered in every subsequent step.

Step 4: Kill-my-thesis

After the wiki, before drafting. Always.

```bash
python3 ~/KMS/TOOLBELT/scripts/kill-my-thesis-grok.py \
  'kaspa/research/wiki/kaspa-fundamentals.md' \
  'kaspa/research/raw/kill-my-thesis-grok.md'
```

The report has two primary outputs, and reading order matters.

The first is the Key Line Audit: the weakest claim in the thesis’s supporting argument, the specific data that would confirm it, and the specific data that would invalidate it. This is the actionable output. It tells you exactly what to fix in the wiki or what to watch for in the market before publishing. Read this section first.

The second is the verdict:

PUBLISHABLE: The thesis holds under adversarial pressure. Proceed to draft.

NEEDS WORK: A specific section or claim fails. The report names it. Fix that section in the wiki (save as v2), rerun kill-my-thesis on the updated version, and proceed only when the verdict changes to PUBLISHABLE. This adds 30 to 60 minutes to the session. It is not optional.

DO NOT PUBLISH: The thesis has a structural flaw serious enough that the note should not ship in its current form. Escalate. Decide whether the thesis is salvageable or whether the research was directionally wrong.

The three real verdicts on $ETH, $KAS, and $NEAR in Section 6 all returned NEEDS WORK on first run. All three notes published stronger for it. The adversarial layer is not a bureaucratic checkpoint. It is the step that keeps the win rate from collapsing over time.

Step 5: Pyramid Worksheet

Before drafting, complete the planning worksheet at `process/pyramid-worksheet.md`. The template is at `~/KMS/TOOLBELT/skills/pyramid-principle/worksheet-template.md`. This step takes five to ten minutes and determines the structural quality of everything written after it. Notes written without it tend to be correct but poorly organized. The data is there, the structure is not, and revision time exceeds the time the worksheet would have taken.

Five required fields:

Governing question. The single question this note answers, from the reader’s perspective. Not what you want to say. What the reader is asking.

Governing answer. Subject plus predicate plus claim. Not a topic (”Toccata is a major event for Kaspa”) but a thesis (”Toccata is a buy trigger on developer demand confirmation, not on launch date, because the Kadena precedent shows 60% post-launch retracement without real demand as the base case”).

SCQA. Situation (what CT currently believes about this token), Complication (the specific on-chain finding or CT signal that contradicts or complicates it, a named fact, not a vague tension), Question (is CT right?), Answer (your thesis).

Key Line. 2 to 4 supporting points stated as findings, not as categories. “Sell-the-news risk is real and quantified via the Kadena comparable” is a finding. “Risks” is a category. Every Key Line point must pass the blank assertion test: if you can replace the point with “there are two things about this” without losing anything, it is a category. Rewrite it.

Inductive leap. What all Key Line points together imply. The insight that emerges from the combination, stated in one sentence.

The worksheet does not constrain the draft. It focuses it. Every section header in the note should be a finding derived from the Key Line, not a category label. The inductive leap is the thesis in its sharpest form.

After the draft is complete, run the five post-draft checks in `~/KMS/TOOLBELT/skills/pyramid-principle/quick-reference.md’ before declaring the note done.

Step 6: Voice check

Read `~/KMS/TOOLBELT/voice-references/writing-style-master.md` before writing. Every time. Not because the rules are forgotten, but because cold-reading them before drafting keeps the register calibrated. The gap between reading the style guide and drafting should be minutes, not hours.

Key rules the guide enforces:

- Claim first, evidence second. Always. Never context before claim.

- Benchmark every data point. Raw number, comparison, implication. The comparison is the argument.

- No em dashes. Replace with period, comma, or colon.

- Source inline: “Per [source], [data].” Never footnotes.

- One voice marker per note maximum.

- Close in one line.

Step 7: Draft and iterate

v1: structure and data. Get everything on paper. Follow the wiki section by section. Do not edit while writing v1. The goal is a complete first pass, not a polished partial.

v2: voice calibration. Apply the style guide. Sharpen the opening so the first sentence is the sharpest specific fact or claim in the note, not a warmup. Fix the close. Cut the hedging language. Replace every vague modifier (”significant,” “substantial,” “notable”) with the actual number.

Never overwrite. New file per version.

```
research/outputs/
├── kaspa-v1.md
├── kaspa-v2.md
└── kaspa-v2-final.md
```

The `-final` suffix means the note published. Apply it only to the version that shipped.

Step 8: Publish

See Section 8 for the full publishing sequence. In brief: primary platform first, X cross-post immediately after, CMC creator post for token research, then tracker and journal updates.

Step 9: Update WIKI and trackers

After publishing, before closing the session:

1. Update `~/KMS/WIKI/tokens/[token].md` with publish price, conviction tier, and any post-publication insight worth retaining

2. Append to `~/KMS/WIKI/log.md`: `## [YYYY-MM-DD] research | [topic]: [one-line summary]`

3. Update `OPERATIONS/call-tracker/outputs/call-tracker.md` with the new row

4. Update `OPERATIONS/trade-journal/outputs/trade-log.md` with status (Watching / Open / skip)

5. Update `AGENTS.md` if anything significant changed: new MCP, new skill, position entered

The wiki update in step 1 is the step most researchers skip. It is also the step that determines whether the system compounds. Skipping it once is fine. Skipping it habitually means the wiki drifts behind the research, and future sessions start from progressively less current context. That is the compounding effect running in reverse.

What a complete session looks like

This is the experience of running the full protocol once, not the step list. A 1,500-word CB token note on Kaspa. Real timings. The session is triggered by a CB community member asking in #questions whether the Toccata smart contract activation is worth a fresh research pass, given the launch window opens in two weeks. The KAS position has been in the trade journal as Open Long since the prior note. A fresh look is warranted.

9:00 AM. Open terminal. `cd ~/KMS/COIN-BUREAU/token-research/kaspa`. Open Claude Code. The agent reads CLAUDE.md and reports current status: prior research from May 2025 archived, no active wiki, kill-my-thesis not yet run on the current cycle. The morning brief is open on the phone as background reference: KAS at $0.03373 overnight, +2.64%, Toccata window June 5 to 20 still on the catalyst tracker. One minute to confirm the session goal: fresh wiki and a publishable note within the working day.

9:01 AM. Targeted data pull. Tell Claude Code to confirm current market data via CoinMarketCap (price $0.034, market cap $830M, FDV $1.2B, 24h volume $47M). Launch TradingView MCP: chart_set_symbol to KASUSDT, 1W timeframe, add Volume Profile Fixed Range and RSI. Pull current readings (RSI 42, neutral; key resistance at $0.048, the 2025 high). Screenshot saved to `process/raw/tv-weekly-2026-05-28.png`. Five minutes.

9:06 AM. Llama AI pull (manual). Open the browser. Type the Kaspa research prompt into Llama AI: protocol economics, on-chain activity trend through the prior 90 days, Toccata testnet developer signups if available, competitive comparison with Kadena post-smart-contract activation. Wait for the response. Copy the markdown. Paste into `research/raw/llama-kaspa-2026-05-28.md`. Eight minutes including wait time. This is the manual bottleneck. It is what it is until browser automation ships.

9:14 AM. Trigger CT sentiment. Send Hermes a Telegram message: “run ct research on kaspa.” Hermes fires ct-sentiment-grok.py with the topic string “KAS Kaspa Toccata smart contract activation sell-the-news risk.” The output lands in `research/raw/ct-sentiment-grok.md` 45 seconds later. No Telegram notification. Tell Claude Code to read it. Crowding MEDIUM. Top bear signal: Kadena comparable, a PoW chain that launched smart contracts to no developer demand. Note it. The Kadena comparable becomes a kill condition in the wiki.

9:18 AM. Build wiki. Agent reads all raw data and builds `kaspa-fundamentals-v1.md`. Thesis, metrics table, Toccata analysis, CT sentiment section, three kill conditions. 20 minutes. Review the wiki. Kadena comparable is in there but the specific numbers (40% pre-launch pump, 60% retracement over 90 days) are missing. Add them in place. Still v1 of the wiki, no material structural change.

9:45 AM. Run kill-my-thesis. Two minutes. **NEEDS WORK.** Two issues flagged: Kadena comparable lacks quantification, and developer demand data for Kaspa smart contracts does not exist. The wiki was built by Claude. The adversarial check comes from Grok 4. A different model family, different training data, different priors. The catches reflect that independence rather than a same-family second opinion.

Fix both issues in wiki v2: add the Kadena numbers explicitly (40% pre-launch pump, 60% retracement over 90 days post-launch), add a kill condition stating “no measurable dev demand within 30 days of Toccata launch.” Save as `kaspa-fundamentals-v2.md`.

10:00 AM. Rerun kill-my-thesis on v2. Two minutes. PUBLISHABLE. Proceed.

10:02 AM. Pyramid Worksheet. Open `process/pyramid-worksheet.md`. Governing question: is Toccata a buy trigger for $KAS? Governing answer: Toccata is a buy trigger on developer demand confirmation, not on launch date, because the Kadena comparable establishes a 60% post-launch retracement without real demand as the base case. SCQA: CT is positioned for a catalyst trade (S), the Kadena on-chain data shows why launch-date entry is the wrong frame (C), the question is whether demand confirmation arrives within a tradeable window (Q), answer is wait for 30-day demand signal not launch date (A). Key Line: three findings. Inductive leap: the trade is confirmation-based, not launch-based. Saved to file. Eight minutes.

10:10 AM. Read writing-style-master.md. Five minutes. Register calibrated.

10:15 AM. Draft v1. Agent writes `kaspa-v1.md` from the v2 wiki. 20 minutes. Complete first pass: opening catalyst, on-chain data, Toccata mechanics, Kadena bear case, kill conditions, conviction tier (Medium given sell-the-news risk).

10:35 AM. Voice calibration for v2. Opening sharpened to lead with the Toccata window (June 5 to 20) rather than a warmup sentence. Em dash spotted in paragraph 3, replaced with a period. “Significant” in paragraph 5 replaced with the specific number (”+18% in 30 days”). Close tightened to “Watching closely.” 20 minutes.

10:55 AM. Final review. Read through once as a skeptical reader. One data point sourced loosely (”per the team” instead of a specific announcement). Found the source, updated to an inline citation. Save as `kaspa-v2-final.md`.

11:05 AM. Publish. CB Discord, #research-feed. X cross-post via @degenrsc. CMC creator post drafted as `kaspa-cmc-post.md` (under 2,000 characters). Call-tracker row added. Trade-journal entry: Watching, entry zone $0.030 to $0.036, stop $0.026, trigger Toccata launch plus measurable dev activity within 30 days.

11:20 AM. Wiki and log update. `WIKI/tokens/kas.md` updated with publish price, Medium conviction, and the kill condition. `WIKI/log.md` entry appended. AGENTS.md scanned for anything significant to update (no change). Session closed.

Total time at the desk: 2 hours 20 minutes. Same note done manually with a chatbot and browser research: 8 to 10 hours.

The data hierarchy

When sources conflict, and they will, the priority order is fixed.

1. On-chain data (Llama AI, direct protocol queries): primary

2. Protocol fundamentals (revenue, TVL, user metrics with sources): secondary

3. Market data (price, volume, FDV from CMC or CoinGecko): tertiary

4. CT sentiment (Grok x_search output): signal, not evidence

Narrative never overrides on-chain data. If CT says one thing and on-chain says another, on-chain wins, and the CT signal goes into the bear case section of the wiki rather than the bull case. The kill-my-thesis step exists partly to enforce this hierarchy when data collection and narrative drift apart during wiki building.

Section 8 covers what happens after the note is published: the content operations flywheel that turns one research session into three publishable artifacts, and the tracker discipline that keeps the win rate measurable rather than aspirational.

Section 8: Content Operations

One research session produces three publishable pieces. Most researchers produce one. The delta is not effort, it is structure.

The three pieces:

1. The research note. The primary output. Published to CB Discord or Substack. 800 to 1,500 words, fully sourced, conviction tier assigned, kill conditions named. This is what the session was built to produce.

2. The process documentation. The `research-process.md` file and `process/raw/` screenshots. How the research was done, which tools were fired, in what sequence, what the kill-my-thesis verdict was, where the wiki required revision before the draft could proceed. This is latent content: an X thread on AI research workflow, a Substack companion on the process behind the note, a YouTube screen-share showing the system in action.

3. The AI workflow screenshots. Terminal views showing Claude Code mid-session, TradingView MCP pulling chart data, the kill-my-thesis verdict document, the CT sentiment output before the wiki was built. These are the visual proof that the system runs. Saved to `process/raw/` during the session as a byproduct of the work, not as a separate production effort.

Pieces 2 and 3 cost approximately 10 minutes of overhead per session once the documentation habit is built. Over 50 research sessions, that overhead produces 50 additional content assets: X threads, YouTube clips, Substack companion pieces, that are completely distinct from the research itself and that document a workflow most readers have never seen.

That is the flywheel. One session, three pieces, zero double production.

The universal publishing sequence

Every piece of content, regardless of platform or asset class, follows the same sequence after the draft is approved:

1. Publish to primary platform.

- CB token research: #degen-shots on CB Discord

- CB equity or macro: #research-feed on CB Discord

- ROCH Labs: rochlabs.com Substack

2. Cross-post to X immediately. @degenrsc. All content types, every time, no exceptions. The cross-post is not a summary or a teaser, it is the same note formatted for X, posted natively, the same day the primary platform sees it.

3. CMC creator post (token research only). Draft saved locally as `research/outputs/[token]-cmc-post.md` before publishing. Under 2,000 characters. Same voice as the main note, sharpest data points only, no filler, no softening. Conviction tier at the close. Entry zone and stop if applicable. Published manually on coinmarketcap.com as a verified creator post.

4. Log to call-tracker. One new row in `OPERATIONS/call-tracker/outputs/call-tracker.md`. Source (CB or ROCH Labs), asset, date, conviction tier, entry zone, stop, initial thesis in one sentence.

5. Log to trade-journal. Status: Watching (thesis built, no entry yet), Open (entered), or skip (equity or macro note with no direct trade setup). Skip is a valid status, macro notes and equity notes that are not actionable as a position go here.

The call tracker

Every published research call gets a row. The discipline is in committing to a thesis and a stop at the moment of publication, not in retrospect.

Current state as of May 2026: 41 tracked calls, 66% win rate (68% excluding $SWTCH), 244% average return on closed positions.

That track record is not the point of the tracker. The point is the accountability it creates. A researcher who publishes calls without tracking them has no feedback loop between thesis quality and outcome. The tracker closes that loop. It answers the only question that matters: is the research actually working?

The call-tracker template is in `~/KMS/TOOLBELT/skills/coinbureau-research/references/log-new-call-template.md`. Use it on every publish. Columns include source, asset, date, conviction tier, entry zone, stop, target 1, target 2, current status, outcome, and notes. Status states: Watching, Open, Closed (Win), Closed (Loss), Closed (BE).

The trade journal

The trade journal is separate from the call tracker and serves a different function. The call tracker is the research record. The trade journal is the position record.

The framework is PTJ (Paul Tudor Jones): thesis first, confirmation second, size discipline, stop placement, no averaging down. Every position in the journal has a thesis (why this asset), a confirmation signal (what triggers entry), a stop (the level that invalidates the thesis), and at minimum one target.

Status states: Watching, Open, Closed.

Watching means the thesis is built and published, but entry has not been triggered. The position monitor in the evening brief watches these. When the confirmation signal fires, Watching moves to Open.

Open means the position is live. The evening brief pulls live prices against every Open position daily and surfaces anything notable from CT on the tracked tickers. No position stays Open without a live stop.

Closed means the position has been exited. Outcome (Win, Loss, or Breakeven) and the post-mortem note go in the journal at close. The post-mortem is one sentence: what the thesis got right, what it missed, and whether the exit was disciplined or emotional.

Trade journal file: `OPERATIONS/trade-journal/outputs/trade-log.md`.

The CMC creator post

Token research only. Published on coinmarketcap.com as a verified creator post after the primary platform and the X cross-post.

Format rules:

- Under 2,000 characters, hard limit

- Same voice as the main note, no softening for a broader audience

- Lead with the sharpest data point in the note, not a summary of what the article covers

- Conviction tier at the close: HIGH, MEDIUM, or SPECULATIVE

- Entry zone and stop if there is a trade setup, omit if not

- No em dashes

- Save the draft as `research/outputs/[token]-cmc-post.md` before publishing manually

The CMC post is not a truncated version of the main note. It is the note’s sharpest argument compressed into a standalone piece. A reader who only sees the CMC post should understand the thesis, the key data point, the risk, and the conviction level.

Publishing stacks by platform

ROCH Labs:

Substack (rochlabs.com) is the primary record. Every long-form essay publishes there first.

YouTube (@rochlabs) follows with a screen-share walkthrough of the same article. Not a separate script, a live screen-share with verbal commentary over the written piece. Same content, different medium, different discovery surface.

X (@degenrsc) gets two versions: a native X article (the Substack essay reformatted for X) and a truncated standalone post. The native video from the YouTube walkthrough is uploaded directly to X, never as a YouTube link. X suppresses external links in the algorithm. Native video is treated differently.

Coin Bureau:

CB Discord is the primary channel. #degen-shots for token research. #research-feed for equity and macro.

X cross-post goes out the same day, same note, no delay.

CMC creator post goes out for all token research, same day.

The separation between CB and ROCH Labs content is structural. CB content does not automatically become ROCH Labs content. Cross-pollination, taking a CB thesis and developing it into a longer ROCH Labs essay, requires a conscious decision, and the ROCH Labs version is written from scratch rather than republished.

What the operations layer gives you

A published note with no tracker update is a research event with no institutional memory. Six months later, there is no way to know whether the thesis worked, what the entry and stop were, or whether the system is improving.

The operations layer, call tracker, trade journal, CMC post, cross-posting sequence, is what turns a content operation into a compounding one. The tracker builds a track record that is auditable. The trade journal enforces position discipline. The cross-posting sequence ensures every piece reaches every relevant surface. The CMC post builds a verified creator presence on the platform where retail investors actively research tokens.

None of this is glamorous. All of it is what separates a researcher who produces content from a researcher who runs a research operation.

Section 9 covers where this build goes next: the end state of a fully autonomous research studio, what Phase 3 looks like, and the honest timeline for getting there.

Section 9: The End State

The build has three phases. Phase 1 is complete. Phase 2 is live as of May 2026. Phase 3 is what the next six to twelve months build toward. The sequence matters more than any individual phase. Reversing it, or skipping ahead, produces an automation layer that runs on top of a workflow no one understands, which is the single most common failure mode in this category.

This section documents what is built, what is being built, and what cannot be built until the prior thing is.

Phase 1: Systemize. Complete. January to May 2026.

The principle that made Phase 1 necessary is the most important sentence in this entire article for anyone thinking about building something like it.

You cannot automate what you have not first systematized.

This is not obvious advice. The default behavior, for anyone who has watched Hermes deliver a morning brief at 6:30 AM, is to want that experience immediately. To spin up a VPS, install the daemon, schedule a cron, and skip the months of manual workflow that preceded it. Most builds in this category fail there. They fail because automating a messy process makes a messy process run faster. The automation does not clean the process. It compounds the entropy at machine speed, and then the operator has a fast, broken pipeline that fails in ways they cannot diagnose because they never understood the process manually in the first place.

Phase 1 of this build ran for four months and produced no automation. It produced a system. The KMS folder structure. The universal project template. The CLAUDE.md hierarchy across global, KMS root, and project levels. The wiki-first discipline. The kill-my-thesis adversarial layer running manually before any wiki was drafted into a note. The voice references. The call tracker. The trade journal. The publishing sequence. The nine-step research workflow with no-skip rules.

By the time Phase 2 began, every step in the workflow had been run manually dozens of times. The failure modes were documented. The gotchas were named. The boring parts were boring enough to be worth automating, and the non-boring parts (thesis selection, kill condition naming, conviction tier assignment, draft review) were obvious as non-automatable because they had been run manually long enough to feel the parts of the process that resist abstraction.

Phase 1 is the part nobody publishes about because it does not look like a system from the outside. There is no daemon. There is no Telegram bot. There are folders and markdown files and a researcher executing a process by hand. From the inside, it is the part that makes everything else possible.

Phase 2: Automate. Live as of May 2026.

Phase 2 is the part this article has been documenting throughout. What it actually delivers, in honest terms, is narrower than the surface impression of a fully autonomous research studio. Here is what is automated and what is still manual.

What is automated: the morning brief pipeline runs every day at 6:30 AM IST. Six Hermes workers fire in parallel (Grok x_search for overnight CT (W1), three Gemini Flash data workers for crypto, equities, and macro (W2–W4), one Gemini Flash worker for the curated YouTube transcripts (W5), one Gemini Flash worker for web news (W6)), Gemini 2.5 Pro synthesizes the six outputs into a single brief, a Gemini Flash pass validates the synthesis against the underlying worker data and flags hallucinations, and Telegram delivery lands on the phone before the day starts. The same pipeline then runs three internal phases: quality scoring against a rubric, idea extraction into the idea tracker, and wiki updates delegated to Claude Code via a Hermes subprocess call. The evening position alert runs at 7:00 PM IST on the same daemon, pulls live prices for every Open and Watching position in the trade journal, runs a Grok Tier 1 scan for anything notable on the tracked tickers, saves the brief to disk, and pushes it to Telegram. A monthly skills refresh job runs on the first of every month and reports any new Claude Code skills or Anthropic SDK changes worth knowing about.

What is still manual: Llama AI runs in a browser, requires an authenticated session, and cannot run on a Linux VPS, so every Llama AI pull during a research session is a human opening the browser, typing the prompt, waiting, and exporting the markdown. TradingView MCP requires the Mac desktop application launched in remote debug mode, so all chart analysis is a human Mac session. Research sessions themselves are still human-initiated, because the decision about what is worth researching this week is a judgment call that involves the call tracker, the trade journal, the morning brief, the prior conversations with the CB community, and the operator’s own reading of where the market is misallocating attention. And the publishing decision (draft v1 reads strong enough to ship; voice calibration applied for v2; final review passed; tracker updated; cross-post sent) is a human checkpoint at every step.

The honest Phase 2 picture is this. Hermes runs the intelligence infrastructure. The research pipeline still requires a human to initiate and conclude. The leverage is in the hours reclaimed from data collection, monitoring, and the morning intelligence routine that previously consumed two to three hours per day before any actual research could begin. Phase 2 does not run the research. It clears the runway.

Phase 2 took four months from conception to live automation, January through May 2026. The majority of that time was not building. It was running the manual workflow long enough to understand which steps were worth automating, which steps would break under automation, and which steps belonged to the human regardless of how good the tooling got.

Phase 3: Scale. Six to twelve months out.

Three components are being built toward, in this order.

The first is Llama AI browser automation. This is the next build and the one that removes the only remaining manual bottleneck in the data collection layer. The architecture is documented in the project plan: Hermes opens a browser session via the browser-use Python library, logs into Llama AI with stored credentials, types the research prompt, polls for completion, exports the markdown to the project’s `research/raw/` folder, and pings Telegram when done. First test runs a single session at a time. Once the single-session loop is reliable, the same pattern runs three parallel instances for sector deep dives that pull from multiple protocols simultaneously. When this ships, Phase 1 and Phase 2 readers alike stop spending five to ten minutes per research session on the Llama AI manual loop.

The second is a research orchestration skill. A single command that chains the full pipeline end to end. The command, typed into Telegram: `research Kaspa $KAS Toccata catalyst`. Hermes interprets the request, fires the targeted MCPs in parallel, runs Grok CT sentiment with a topic string derived from the request, triggers the Llama AI browser pull, hands the raw data set to the synthesis model for wiki building, runs Grok kill-my-thesis on the resulting wiki, drafts a v1 of the note in Sonnet 4.6, and pings Telegram with a link to the draft. The operator opens the draft. The draft is not blank. It is not a placeholder. It is a coherent v1 that needs voice calibration, conviction tier assignment, and a final review before publishing. The work of producing the draft has been done. The work of judging whether the draft should ship has not. That is the right split. One command from topic to draft.

The third is parallel specialist agents. A crypto agent, an equity agent, and a macro agent running simultaneously on their domains. Each one runs its own version of the orchestration skill, focused on its domain, with domain-specific MCPs and a domain-specific voice calibration step. The operator reviews and edits the output across all three. Does not produce it. This is the configuration that turns a solo research operation into something that produces output at a volume previously associated with small research teams, while keeping the editorial judgment in one person.

The timeline for Phase 3 is six to twelve months. The bottleneck is not tooling. The browser-use library exists. Hermes can spawn parallel subprocesses. Multi-agent orchestration patterns are documented in public agent frameworks. The bottleneck is the same one Phase 1 made explicit: the discipline of documenting and systematizing each new step before automating it. Llama AI browser automation cannot ship until the manual Llama AI workflow has been documented to the level of detail required for browser-use to replicate it deterministically. The orchestration skill cannot ship until the manual end-to-end pipeline has been run enough times to know where the model routing breaks, where the kill-my-thesis verdict needs to gate progression versus where it can be reviewed asynchronously, and where the human checkpoint cannot be removed. Phase 1 before Phase 2, always. Phase 2 before Phase 3, always.

What the agent does not replace

Phase 3 is not a fully autonomous research studio in the sense that the operator becomes optional. The judgment calls that remain human are the calls that determine whether the research is worth doing in the first place: what to research, why now, what thesis to build, what conviction tier the evidence supports, when a kill condition has triggered on an open position, when a thesis is salvageable and when it is directionally wrong. None of these are automatable in any near-term version of this build, and an honest description of the system has to name that limit explicitly rather than imply otherwise.

The leverage Phase 3 adds is the elimination of every hour that was previously going to mechanical work. Data collection. Synthesis. First-draft production. Routine monitoring. Cross-posting. Tracker logging. The reclamation of those hours is not marginal. For a solo operator, it is the difference between producing two notes a week and producing eight. The editorial judgment runs at the same rate either way, because the editorial judgment is the constraint that does not scale through tooling.

The researcher does not get replaced. The hours that were not actually research, that were always overhead masquerading as research, get reclaimed.

The loop, closed

The opening of this article was a single sentence: every research note you write today starts from zero.

That is the condition the system removes.

The note you write today, with the full build running, starts from a project CLAUDE.md updated at the end of the previous session. From a wiki page that has been refined across three prior research passes on the same token. From a morning brief synthesized four hours ago by Hermes from the curated streams. From a kill-my-thesis verdict produced by a model that was deliberately chosen because it cannot see the wiki the way the model that built the wiki sees it. From a call tracker with 41 prior rows that tell you what your thesis quality looks like under outcome data rather than under self-assessment. From a trade journal that knows what your open positions are without you having to remind it. Nothing in that session starts from zero. Everything compounds.

The researchers who build a structured second brain and a systematized workflow will compound their output measurably faster than the researchers who do not. The gap is small now. Most solo operators are still using AI as a chatbot in a browser tab, paying the re-derivation cost every session, watching their research disappear into chat history every time they close the window. By the time Phase 3 is the baseline expectation for competitive solo research operations, which I believe is the second half of 2027 at the latest, the operators who started building this in 2024 will be eighteen months ahead of the operators who started in 2026, in ways that cannot be closed by working harder. Compounding does not work that way.

Build the second brain first. The compounding starts on day one.

Watching closely.

Appendix: Cost Breakdown

The full monthly cost of the stack, line by line. These are live figures as of May 2026, pulled from actual invoices and API dashboards, not estimates.

Complete cost table

The three entry points

Minimum viable stack: ~$51/month

Claude Code Pro ($20) + X Premium Plus for Grok access (~$16) + TradingView Pro ($15).

This gives you: a persistent identity-aware research agent, CT sentiment analysis via Grok’s native X search (included in your X Premium Plus subscription, no separate API cost), and professional chart analysis via TradingView MCP (the MCP itself is free, you pay for the TradingView Pro subscription). Hermes runs locally on your Mac at no additional cost, though you lose it when the machine is off or asleep. It does not include Llama AI or kill-my-thesis adversarial checks. It is the right starting point for the first month while the KMS and research workflow are being built.

One important note on Grok: X Premium Plus gives you Grok 4 access and, through Hermes’s integration with the xAI API, the ability to run real-time X data research from within the Hermes agent. This is not a separate API subscription, it is the same access you already have from your X subscription, wired into the automation layer.

Core research stack: ~$90/month

Minimum viable stack plus Llama AI Pro ($30-50). Kill-my-thesis uses Grok 4, which runs through your existing X Premium Plus subscription at no additional cost.

This is the version that produces research at production quality. The adversarial layer is live. The deepest on-chain data source is accessible. The win rate improvement from the kill-my-thesis layer pays for the additional cost many times over across a year of publishing. This is the stack to run from month two onward.

Full stack: ~$150-200/month

Core stack plus Hermes full automation, morning brief pipeline (Grok W1 via X Premium Plus, Gemini Flash data workers, Gemini Pro synthesis, Gemini Flash validation), evening position alert, and monthly skills refresh. Add a VPS ($6-12) if you want 24/7 availability independent of your local machine, otherwise Hermes runs on your Mac and the cron jobs miss windows when the machine is off.

This is Phase 2. The intelligence infrastructure runs without you. The research pipeline still requires human initiation and judgment. The cost delta from core to full is primarily the Google AI Studio billing for the Gemini morning brief pipeline and the optional VPS. At 30 research notes per month, the Grok cost across CT sentiment and kill-my-thesis runs is covered by your X Premium Plus subscription. Everything else is fixed.

The progressive build path

Month 1 (~$51): Install Claude Code. Activate X Premium Plus if not already on it (unlocks Grok). Set up TradingView Pro. Build the KMS folder structure. Write the global CLAUDE.md and run the first five research sessions manually end to end. Do not install Hermes yet. Do not set up the morning brief. Run the workflow by hand, slowly, until every step is understood.

Month 2 ($90): Add Llama AI Pro. Run kill-my-thesis on every wiki before drafting, no exceptions. It uses Grok 4 through your existing X Premium Plus subscription, so there is no additional API cost. Note what the adversarial layer catches and what it misses. The win rate data starts accumulating here.

Month 3+ ($200): Install Hermes. Set up the morning brief pipeline. Configure the evening position alert. The automation layer runs on top of a workflow that has been executed manually enough times to understand where it breaks.

The path is Phase 1 before Phase 2. The cost table is designed to be entered progressively, not all at once.

What free covers

Five of the eight MCPs in the stack cost nothing: FRED, SEC EDGAR, Financial Datasets, Fear & Greed, and Whale Tracker are fully free. CoinMarketCap and Alpha Vantage are free tier with usage limits (333 calls/day and 500 calls/day respectively) that a solo research operation does not exceed when the data scripts are used correctly. All seven are effectively zero cost in practice.

The real cost of the stack is concentrated in five items: Claude Code / Anthropic API, xAI via X Premium Plus for Grok, Google AI Studio for Gemini, Llama AI Pro subscription, and the optional Hermes VPS. Those five items account for roughly 85% of the total monthly cost at full stack.

TradingView Pro is the only MCP-adjacent cost that requires a paid subscription. The MCP itself is free, it connects to your existing TradingView desktop application via remote debug mode. Pro is the minimum subscription tier that provides the chart capabilities used in this stack. Grok access, if you are already on X Premium Plus, costs nothing additional, it is part of that subscription and wires directly into Hermes.

Conclusion

This is the entire setup, and how I use claude code + Hermes to turn my research work into a fully agent first workflow.

My end game is to build a one-person agentic research studio with multiple agents with their own unique personas - think a trader agent, a macro agent, a prediction market agent, a fundamental analyst agent, a crypto onchain detective agent, a sales agent, a marketing agent, and an operations agent…not to mention an agent who acts like my Chief of Staff.

Still very early in that vision, and might take months to really fructify but I’m in no hurry. One thing is for sure, the agentic workloads have turned me into a better analyst, and it feels like playing a video game w/ multiple agents as your hands and legs as you navigate the game of markets, investing, and research.

Thanks for reading.

That frame is half right, and the half that is wrong is the half you are being asked to pay for. Physical AI is real as a destination. It is not real as a 2026 basket. The actual shipment floor this year is measured in low tens of thousands of units globally, not millions. The unit economics of the flagship products are collapsing under a deliberate Chinese price attack, not expanding. The layer of the bill of materials where value actually accrues is being commoditized by the same Chinese supply chain that already won drones and batteries. And the “revenue” inside the on-chain robotics basket is, on a verified basis, almost entirely subsidy-masked or simulated.

My governing view: the post-Jensen physical AI basket is mispriced exit liquidity. The sector is real, but the volume and the margin accrue to China, so the only defensible long is a narrow set of chokepoints and data-moats bought on weakness, not the basket. This essay builds that case from the shipment data up, names what I would own and what I would avoid, and is honest about the two places where my own thesis is underbuilt.

I. The $40 trillion number is a destination, not a 2026 entry: the global humanoid installed base is roughly 16,000 to 18,000 units

Start with the number that matters and almost nobody quotes: how many humanoid robots actually exist and do work today. Per cross-referenced 2025 disclosures and SemiAnalysis fieldwork, the global installed base of humanoid robots at the end of 2025 is approximately 16,000 to 18,000 units, and the overwhelming majority of those are non-full-size research and education platforms, not industrial labor. The headline that the market is “inflecting” to 50,000 to 100,000 units in 2026 is true only with three asterisks: it is a China story, a low-spec story, and a target story, not a global, full-size, shipped-and-deployed story.

Walk the actuals, because the actuals are the whole argument.

Figure, the US foundation-model-plus-hardware darling, built 150 robots in all of 2025. Per the company’s own CEO chart published in June 2026, Figure reached roughly 250 units per month by May 2026. That is a real ramp as a rate, and it is a roughly 3,000-per-year run-rate that is approximately 25 percent of the company’s stated 12,000-per-year BotQ line capacity. The “one robot per hour” headline that circulated implies roughly 720 per month, which is about three times the actual ~250. And every one of these is a production unit, a robot built, not a deployed-at-customer revenue unit. The gap between “built” and “doing paid work” is the entire commercial question, and it is wide.

Unitree, the Chinese cost leader, shipped approximately 5,500 units in 2025. Per SemiAnalysis, roughly 70 percent of those were non-full-size research and education units, and only on the order of 250 were in actual labor settings. Unitree’s 2026 target is 20,000 units. UBTech, the Hong-Kong-listed industrial humanoid name, shipped 1,079 full-size industrial units in 2025 at a 54.6 percent gross margin, targets roughly 5,000 in 2026 and 10,000 by 2027. Tesla’s Optimus shipped “hundreds” in 2025, all internal and for learning, against a 50,000 to 100,000 target for 2026 that realistically maps to “low thousands” of genuinely deployed units.

Now stack the targets against the prior-year actuals: Unitree is guiding 20,000 after 5,500, UBTech roughly 5,000 after 1,079, Tesla 50,000 to 100,000 after “hundreds.” These are 3x to 4x year-over-year ramps quoted as fact. The trade is not wrong that shipments are growing. It is wrong about where they are growing and how small the floor actually is. China’s domestic humanoid installed base went from roughly 18,000 in 2025 toward a 62,500 target for 2026 per state media, and that single national number is essentially the entire “global” 50,000 to 100,000 range that gets quoted as a worldwide inflection. The inflection is China plus low-spec plus targets. Own that sentence before you own the basket.

The honest counterpoint here: a 3,000-per-year run-rate at Figure and a 20,000 target at Unitree are still exponential against a base of zero, and exponentials are exactly what you want to be early to. I agree. The disagreement is not about direction. It is about what you are paying for that direction, and to whom the economics of it accrue, which is the rest of this essay.

II. The robot is a mechatronics problem, not a chip problem: actuation is 40 to 66 percent of the bill of materials and compute is 8 percent, falling to 5

The instinct that has worked for three years is “buy the picks and shovels, buy NVIDIA.” Applied to humanoids, that instinct buys the wrong tier of the chain. Per Yole Group, the silicon content of a humanoid robot is approximately 8 percent of the bill of materials today and is expected to fall toward 5 percent by 2035 as compute commoditizes and the rest of the body does not. The dominant cost is actuation: the reducers, motors, and screws that let the robot move are 40 to 66 percent of the bill of materials per Yole, Barclays, and Goldman teardowns. Structure and battery are roughly 20 to 25 percent. Sensing and perception are roughly 10 to 15 percent. Compute, the part the equity market fixates on, is the smallest slice.

This is not a footnote. It is the single most important reframe in the sector, because it tells you that the durable value-capture in humanoids is a precision-mechanical problem, not a semiconductor problem, and precision mechanics is a domain where the Western incumbents are being actively undercut rather than one where they have a widening moat.

Goldman’s own component-exposure work makes the point in their preferred language. In Goldman’s humanoid supply-chain exhibit, the components ranked highest on combined investment criteria before 2030 are harmonic reduction gears, scored 16 out of a possible 18, followed by dexterous hand modules at 15, then actuator assembly and planetary roller screws at 14, then sensors and compute tied at 13, then battery and camera at 12. Compute and sensors sit in the middle of Goldman’s own hierarchy, not the top. The top is reducers and hands. The names Goldman attaches to the reducer line are Harmonic Drive and LeaderDrive. The names attached to the hand line are Chinese: Zhaowei, Inovance.

If you accept Goldman’s hierarchy, and the hardware physics says you should, then the question for the long side is simple: who owns the reducer and the actuator, and is their margin expanding or contracting as volume scales? The answer is uncomfortable, and it is the next two sections.

III. China is running the BYD and DJI playbook on the hardest component: Unitree’s flagship fell from $50,000 to $27,300 in roughly 18 months at a 67 percent gross margin

Here is the data point that should reset how you price the entire humanoid OEM basket. Per a SemiAnalysis primary teardown published in June 2026, the Unitree G1 EDU Advanced, a 29-degree-of-freedom humanoid, has a median bill of materials of approximately $8,976. Unitree’s pre-tax average selling price on that unit is roughly 195,000 RMB, which at the disclosed 67.12 percent gross margin is approximately $27,300. The same class of robot was priced above $50,000 twelve to eighteen months earlier. Unitree compressed the price of a working humanoid by roughly 45 percent and is still earning a 67 percent gross margin on it, with some channel deals reported “well under $20,000.”

Read that the way a hardware investor reads it. A company that can cut the price of its flagship nearly in half and keep a two-thirds gross margin is not in a price war it is losing. It is running a deliberate cost-down campaign from a position of structural advantage, and it is doing it while tripling revenue year-over-year on a roughly 60 percent blended gross margin, spending roughly $300 million on AI research, in-housing its manufacturing, and pulling roughly $610 million from a STAR Market listing to fund the next leg. This is the BYD playbook and the DJI playbook applied to humanoids: own the hardest component, in Unitree’s case the quasi-direct-drive actuator, compound a cost advantage that competitors cannot match because they are buying that component rather than making it, and then eat the market from the bottom by collapsing price faster than anyone’s margin can survive.

The implication for the Western humanoid OEM basket is direct. If the reference product in the category sells a working unit at $27,300 and is heading under $20,000 while keeping 67 percent margins, then every pre-revenue Western OEM whose model assumes a $50,000-plus ASP and a “we will get cost down later” cost curve is modeling a world that already does not exist. The price umbrella they are implicitly underwriting has already been removed by the company that controls the cost-defining component. That is what makes the basket exit liquidity: it is priced for a margin structure that the Chinese cost leader has already demonstrated it can compress at will.

The one honest caveat on the Unitree cost story sits in the operating economics, not the sticker. Per the same SemiAnalysis work, the all-in hourly cost of running a G1 against a $30-per-hour labor benchmark lands somewhere between $24.60 and $34.60 per hour depending on utilization between 50 and 80 percent and mean-time-to-failure between 16 and 33 minutes. In other words, the robot beats human labor on cost only at high utilization and high reliability, and today’s reliability is measured in tens of minutes between failures. The viability is real but marginal, and it is gated by uptime, not by sticker price.

So the cost attack is genuine and the deployment economics are still on a knife’s edge. Both things are true. The investing conclusion is that the value is leaking toward whoever owns the actuator and the reducer, and away from whoever assembles the robot, which sends us to the one name the bulls point to as the Western-accessible chokepoint.

IV. China owns the upstream, not just the factory: roughly 90 percent of refined rare earths and the NdFeB magnets every actuator needs

The cost attack in the previous section is not a one-product fluke, and the reason it is durable sits upstream of the factory, in the raw materials. Every electric actuator in a humanoid robot depends on a permanent magnet, and the highest-performance permanent magnets are neodymium-iron-boron (NdFeB) magnets built from rare earth elements. Per multiple supply-chain analyses, China controls roughly 90 percent of global refined rare earth output and an even larger share of finished NdFeB magnet production. The mining is somewhat more distributed, but the refining and the magnet-making, the two steps that actually matter, are concentrated in China to a degree that has no near-term substitute.

This is the structural floor under the entire China cost advantage. A Western OEM can in principle design a better robot, but the motor inside its actuators is built from magnets that are refined and, in most cases, manufactured in China. When Beijing tightened rare earth and magnet export licensing through 2025, the binding constraint on Western humanoid production was not engineering talent or capital, it was access to the magnets, and the lead times stretched. The same dynamic that gave China drones through DJI, solar through a 90 percent cost decline, and batteries through CATL is now present one layer deeper in the robot than the actuator: in the magnet itself.

The investing read is uncomfortable but clear. The bull case for the Western and Japanese actuation incumbents implicitly assumes they can scale production to meet the humanoid ramp. That assumption runs straight into a materials chokepoint that China controls. It is also why the actuation layer, despite being the highest-value 40 to 66 percent of the bill of materials, is the layer where Western suppliers are least able to defend share on cost: you cannot out-engineer a magnet you cannot source. This is the most underpriced structural risk in the entire Western physical AI basket, and it is why the cost collapse documented in the previous section compounds rather than mean-reverts.

V. The chokepoint that is supposed to win is margin-compressing while priced at triple-digit revenue multiples: LeaderDrive’s gross margin fell 5.62 points as the share war started

LeaderDrive, ticker 688017 on the Shanghai STAR Market, is the name that sits at the top of Goldman’s component hierarchy. It is the dominant Chinese harmonic-reducer maker, the single most defensible position in the entire physical AI value chain on paper, and it is the cleanest test of the chokepoint thesis. The test does not pass at today’s price.

The growth is real. Per company filings, LeaderDrive’s fiscal 2025 revenue was approximately 570 million RMB, up 47 percent year-over-year, and net profit was approximately 125 million RMB, up 122 percent. Those are excellent top-line numbers. The problem is the margin and the multiple. Per the H1 2025 disclosure, LeaderDrive’s gross margin was 34.77 percent, down 5.62 percentage points year-over-year. The single most defensible component in the chain saw its gross margin compress by more than five points in the same period that humanoid demand was supposedly inflecting, which tells you the reducer market is already a share war, not a pricing-power monopoly. China’s domestic harmonic-reducer share is already 30 to 40 percent per JPMorgan estimates, and LeaderDrive’s named customers, Agibot and UBTech, are Chinese OEMs, the same ecosystem running the cost-down.

Now the valuation. Revenue of approximately 570 million RMB is roughly $78 million. Against a market capitalization of roughly $8 to $11 billion, that is a triple-digit price-to-sales multiple on a business whose gross margin is contracting. You are being asked to pay over 100 times revenue for the privilege of owning the chokepoint precisely as the chokepoint demonstrates it has less pricing power than the map implies. The chokepoint thesis is correct in structure and wrong at this price. That distinction, right structure and wrong price, is the difference between a thesis and a trade.

One fact I want to handle precisely, because the bull case leans on it: LeaderDrive is widely reported as a Tesla Optimus harmonic-reducer supplier. The naming-confusion theory I held earlier does not survive scrutiny: “LeaderDrive” and “Suzhou Green Harmonic” are two English renderings of one Suzhou-based company, whose Chinese name translates literally as “Green Harmonic,” not two different suppliers. The names were the confusion, not evidence of a second vendor. So that is not the issue. The real issue is the strength of the claim. Per trade-media supply-chain reporting, Tesla completed factory audits for its third-generation Optimus with Chinese suppliers taking roughly 70 percent of component share, and LeaderDrive is named among the harmonic-reducer suppliers in that chain. But unlike Sanhua, which has a confirmed roughly $685 million Optimus-related order, there is no disclosed contract value or official qualification specific to LeaderDrive. So the honest characterization is probable supplier, not confirmed exclusive design-win, and certainly not disclosed economics. It does not change the verdict. Even granting the Tesla link, LeaderDrive is margin-compressing at a triple-digit multiple, so the structure is right and the price is wrong. A confirmed, sized Tesla contract is the catalyst that would force a re-rate, and it is the single most important thing to watch on this ticker.

The Japanese incumbent, Nabtesco, ticker 6268, scores at the top of Goldman’s reducer ranking alongside LeaderDrive and is the established precision-reducer supplier to global industrial robotics. It is the cleaner Western-accessible way to own the reducer chokepoint, and it is under the same Chinese price attack from below. Nabtesco is a watch-on-weakness name, not a buy here, for the same reason: the structural position is real and the pricing environment is deteriorating as Chinese reducers move up the quality curve.

VI. The capability ceiling is lower than the demos imply: robotics has its foundation-model moment but not its internet, and robots have almost none of the proprioception humans use

Set the economics aside and ask the harder question: can these machines actually do general work yet? The honest answer from the research frontier is no, and the reason is structural, not incremental.

Per a June 2026 survey paper on arXiv from a group including Schwager, Hutter, and Peters, the field has reached its “foundation-model moment” in the sense that large vision-language-action models can now be trained for robotics, but it has not reached its “internet moment,” meaning there is no web-scale corpus of grounded physical interaction data to train on. Language models had the entire internet. Robotics has a few thousand teleoperated demonstrations per task and no equivalent of the open web. The grounding layer, the mapping from a model’s abstract plan to reliable physical action in an unstructured environment, is unsolved. This is why the impressive demos are almost always in constrained settings and why mean-time-to-failure is still measured in tens of minutes.

Pair that software gap with a hardware one that gets even less attention: proprioception. Humans sense the world through an enormous distributed network of touch, force, and position receptors, and roughly 70 percent of human sensing is not vision. Today’s humanoids have almost none of that. They are running on cameras and a handful of joint encoders, which is why dexterous manipulation, the thing that would make a humanoid economically general, remains the hardest unsolved problem and why Goldman ranks the dexterous hand module second in its entire component hierarchy. The sensing layer is both underbuilt and undervalued.

The investing translation: the timeline to general-purpose, unsupervised, deployed-at-scale humanoid labor is longer than the basket’s valuations imply, and the binding constraints are a data corpus that does not exist yet and a sensing stack that has barely been built. That does not kill the sector. It means the sector pays off on a longer clock than the spot prices assume, which again favors patience and chokepoints over the hype basket.

VII. The on-chain robotics basket is almost entirely subsidy-masked or simulated revenue: of eleven tokens audited on-chain, only one shows real, verified, converging revenue

The crypto expression of physical AI is where the gap between narrative and substance is widest, and it is the part of this report I can verify most precisely, because on-chain revenue either settles in a block or it does not. I ran eleven AI-and-robotics tokens through a DefiLlama fee-quality audit, sorting organic revenue from subsidy-masked revenue from pre-revenue narrative. The result is stark: one token has real, verified, converging revenue. The rest are optionality, subsidy, or simulation.

GEOD, the Geodnet decentralized RTK-positioning network, is the lone survivor of the audit. Per DefiLlama, its trailing 30-day annualized revenue is approximately $10.0 million, and critically that on-chain figure converges with the company’s own guidance rather than contradicting it, which is the single best sign that revenue is real. It trades at roughly 23.7 times fully-diluted price-to-sales, runs an 80 percent buy-and-burn on protocol revenue, and sells a real product: high-precision positioning infrastructure for autonomous vehicles and drones, which is genuinely a physical AI input. The honest risk is a July 30 halving that cuts node rewards and could trigger node churn if the unit economics for operators tighten. But it is the one name where the on-chain data and the business agree.

TAO, the Bittensor token that anchors most “decentralized AI” portfolios, fails the audit in an instructive way. The widely-cited revenue figure of roughly $172 million is not real protocol revenue. DefiLlama-verified revenue is approximately $5.6 million, and the largest subnet, Chutes, was running approximately $40.4 million per year in emissions subsidy, which is 2.7 to 13 times the network’s total external revenue depending on how you count. That is not a business, it is an income desert with a token-emission sprinkler. PEAQ, marketed as the machine-economy chain, is pre-revenue: its showcase “deployments” with LG CLOi, Unitree, and Tether are, per peaq’s own purple paper, simulations, not live revenue-generating integrations, against approximately $489,000 of actual revenue at a 214 times price-to-sales multiple.

The rest sort cleanly into “not physical AI” or “infrastructure optionality.” VVV (Venice) has genuinely organic AI-inference revenue but zero robotics exposure, which makes it an AI-infrastructure name, not a physical AI one. VIRTUAL and AKT are subsidy-masked or revenue-declining. ROBO (the decentralized-robotics infra token) is the best pre-revenue infrastructure story in the set but settles its activity in USDC rather than its own token, which breaks the value-accrual loop. DEUS is a pre-revenue private-equity wrapper. FET, POD, and RENDER are not physical AI on any honest definition. The inductive read across all eleven: the token market has priced a robotics-revenue narrative onto a set of assets where, with one exception, the robotics revenue does not yet exist on-chain. GEOD is the only place the narrative and the ledger agree.

VIII. The deployers are where physical AI is already profitable, and the market is not looking: Amazon runs more than one million robots for $4 to $10 billion a year in savings

Everything to this point has been about who builds the robot and who captures the component margin. The most direct way to express physical AI, though, is not to own the builders at all. It is to own the operators who deploy robots at scale and watch their margins expand. This layer is already profitable, already disclosed in earnings, and almost entirely ignored by the humanoid narrative, which is staring at the demo and missing the deployment.

The anchor data point is Amazon. Per Morgan Stanley estimates, Amazon now operates more than one million robots across roughly 300 fulfillment facilities, generating a reported $4 billion to $10 billion per year in operating savings. That is not a 2030 projection or a pilot. It is recurring margin showing up in the cost line of the largest logistics operation on earth, built on wheeled and articulated automation rather than humanoids, which is precisely the point: the money in physical AI today is being made by deployers running un-glamorous, single-purpose machines at industrial scale, not by anyone selling a bipedal robot.

The pattern generalizes to a screenable thesis: own the operators with a deployed fleet, a proprietary operational dataset, and a locked distribution channel, where each incremental robot expands margin rather than burns capital. Intuitive Surgical is the cleanest listed example, which is why it leads my conviction map, but the same logic points at the warehouse and logistics operators (Amazon and the third-party logistics names), the quick-service-restaurant operators automating the back of house, and the grocery and fulfillment deployers. The honest caveat is that for most of these the robotics line is not yet separable in the financials, so you are buying the deployer for the whole business and treating robotics margin as embedded optionality rather than a clean pure-play. But it is the layer where physical AI is already cash-generative, and it is structurally insulated from the China cost war, because the deployer captures value from operating the robot, not from manufacturing it. The cheaper the robot gets, the better the deployer’s economics become. China collapsing the hardware price is a tailwind for this layer, not a threat.

IX. The trade: own the data-moats and the one real on-chain cash flow, watch the chokepoints for a real pullback, avoid the basket that is exit liquidity

Pull the threads together and the portfolio writes itself, and it looks nothing like the basket. The shipment floor is tiny and concentrated in China and low-spec units. The value-capture layer is mechanical and is being commoditized by the Chinese cost leader at a 67 percent margin. The Western-accessible chokepoint is margin-compressing at a triple-digit multiple. The capability ceiling is gated by a data corpus and a sensing stack that do not exist yet. And the on-chain basket is, on verified data, one real business wearing ten costumes. The conclusion is not “avoid physical AI.” It is “own the narrow, defensible, cash-generative or moat-protected set, and let the hype basket find its real clearing price without you.”

What I would own

Intuitive Surgical, ticker ISRG, is the purest data-flywheel in robotics that you can actually buy. It has a dataset of more than 17 million procedures, roughly 85 percent recurring revenue, and approximately $8 billion in net cash, and it sits outside the humanoid hype entirely, which is exactly why it is investable: you are buying a deployed fleet, a proprietary data moat, and a locked channel, not a target. My stance is buy on weakness rather than chase, because the quality is not in dispute and the entry is everything. On the on-chain side, GEOD is the only token I would hold on fundamentals rather than narrative, sized as optionality, because it is the one name where the revenue is real, converging, and bought back.

What I would watch and own only on a real pullback

LeaderDrive (688017) is the structurally correct chokepoint at a structurally wrong price; I want it materially lower, or I want the Tesla qualification confirmed, before the triple-digit multiple is defensible. Nabtesco (6268) is the cleaner Western-accessible reducer incumbent, also under price attack, also a weakness buy rather than a chase. These are the names where being right about the structure still loses money if you pay today’s price.

What I would avoid as exit liquidity

The pre-revenue Western and Chinese humanoid-OEM basket, which is modeling a margin world the Chinese cost leader has already erased. Korean robotics at plus 40 to 53 percent year-to-date, where names like Doosan and LG Electronics have run on the theme without the contract economics to support the move. Broad robotics ETFs, where the structure works against you: BOTZ’s top holding, ABB, is in the process of divesting its robotics division, so the index is overweight a company exiting the very thesis the index sells. And the subsidy-masked or simulated tokens, TAO and PEAQ chief among them, where the on-chain ledger does not support the narrative the price embeds.

X. One thesis gap called outright

One gap in this thesis is genuinely unresolved, and a second is a limitation I want to name even though I have given the layer a full section above.

The unresolved one is thermal management. High-density actuation in a human-sized envelope generates heat that has to go somewhere, and thermal dissipation is plausibly a gating constraint on continuous-duty humanoid labor. I do not have a clean, investable, pure-play name for it, and I am not going to invent one to round out the framework. It is an open research question in this thesis, and if the binding constraint on deployment turns out to be heat rather than dexterity or data, the names that solve it are not in my conviction map yet.

The limitation is the financial legibility of the deployer layer in Section VIII. The thesis that the operators capture physical AI margin is sound, and the Amazon data proves the savings are real and recurring. But for most of these names the robotics contribution is not separable in the financials, so the cleanest pure-play expressions are scarce, ISRG being the rare exception, and everything else requires buying the whole business and treating robotics margin as embedded optionality. I have named the layer and made the structural case for it. I have not solved the problem of isolating its value cleanly, and that is the honest state of it.

The forward view

The physical AI narrative will be right eventually, and that is exactly the trap. A thesis that is correct on a ten-year horizon and mispriced on a two-year one is how money is lost being early to something true. The shipment data, the bill-of-materials map, the Unitree price collapse, the LeaderDrive margin squeeze, and the on-chain audit all point the same way: in 2026 the volume and the margin in physical AI accrue to China and to a handful of Western data-moats, not to the basket the market is loading. The next twelve months will not be decided by who has the best humanoid demo. They will be decided by three things I will be tracking specifically: whether Unitree’s price keeps falling while margins hold, whether LeaderDrive confirms a Tesla design-win or sees its margin keep compressing, and whether the deployer layer starts showing the margin expansion that would make the whole thesis pay off in boring, ownable equities rather than pre-revenue hope.

Own the chokepoints and the data-moats on weakness. Let the basket find its clearing price without you.

Alessandro has been posting real-time calls with timestamps in a paid Discord for over a year. I read all of it before this conversation. Lighter came in at $56 per point against his early estimate of $12. His market-making bot on 01.xyz got rekt. He said so publicly in the same channel where he had been calling the farm.

That record is what makes the conversation worth having. This is not a market outlook interview. It is a peer review of a practitioner’s process against his own receipts.

Here is what I took away.

---

Three things worth taking seriously

1. CT is measuring global liquidity wrong and it is costing them on BTC timing

CT’s current read on the BTC decline: Saylor dumped 32 BTC, that is the pressure. Wrong framing. BTC has been in a downward spiral since the October 10th market crash. Saylor’s position is noise superimposed on a structural trend that started months before anyone was counting his wallet.

The actual signal is in global liquidity. Not M2. M2 is a small component of the global liquidity ocean. The dominant pool is the shadow monetary base, driven by the eurodollar system: offshore dollars circulating outside the Fed’s direct reach, tracked across the ECB, Bank of Japan, PBOC, and the broader offshore dollar system simultaneously. Michael Howell at CrossBorder Capital has been mapping this since the 1980s. It does not appear on TradingView. Most CT cycle analysis is staring at the wrong dataset.

The reason BTC is the right instrument to watch this through is quantified. BTC’s beta to global liquidity is 4.5x. Gold’s is 1.8x. BTC is not just correlated to liquidity, it is the most reflexive expression of it in any liquid market. When liquidity expands, BTC amplifies it on the upside. When it contracts, BTC amplifies it on the downside.

Alessandro built a specific adaptation on top of Howell’s model. The insight is straightforward: don’t track the level of global liquidity. Track the rate of change. Global liquidity can still be rising in absolute terms while its growth rate is decelerating. That deceleration is the signal. BTC peaks when the rate of change peaks and rolls over, weeks before the absolute level starts declining. Alex built a dashboard monitoring this derivative. It called the October 2025 BTC peak before price confirmed. The same read worked in 2021 and in 2017.

Howell’s underlying cycle runs approximately 5.4 years. The peak was Q4 2025. That cadence puts the trough at mid-2027. The rate of change is continuing to slow. Central bank vectors are not aligned: the US is expanding, Japan and the ECB are contracting, China pulling back. For the model to flip bullish, multiple central banks need to pivot simultaneously. That is not the current setup.

Alex said the $60K October low is likely the macro low, or close to it. He is a buyer at current levels for a five to ten year hold. My read is more cautious. If the mid-2027 trough is real and the liquidity cycle plays out as the model suggests, $40K is within range. Not a prediction. A scenario the model does not rule out. The rate of change has to inflect upward meaningfully before I would revise that downward.

The model is not a trading signal. It is a structural positioning tool. The question it answers is not “should I buy today” but “what regime are we in.” Right now the regime is deceleration. That is worth more than 50 CT threads about Saylor’s wallet.

2. POD is permanently a Venice derivative until proven otherwise

Venice has PMF. That is the one thing this inference cycle has confirmed. Private, uncensored AI with a working dual-token model: stake $VVV, earn yield, receive DIEM, and each DIEM unlocks $1 of inference per day indefinitely. The mechanic is not novel — it is DeFi yield architecture applied to compute. But it works. $12-14M ARR, 50-80B tokens per day, Coinbase Day 1 and Robinhood listing. When something is working this clearly, the burden of proof is on everything that comes after it.

Dolphin AI ($POD) v1 is Venice with different branding. It uses Venice as its inference backend. It has no dual-token layer. It has no independently verified ARR. Alex ran a three-part DCF on POD and eliminated two of the three drivers: OpenRouter revenue was overstated, consumer GPU DePIN is too early. What remained was Venice. POD’s value accrual in v1 is a function of Venice’s network activity. That is not a thesis. That is exposure to someone else’s thesis.

v2 is the real question. The peer-to-pool model allows anyone with idle compute — a gaming rig, a workstation sitting unused overnight — to contribute to a shared inference pool and get paid for utilization. This is the supply-side innovation Venice cannot replicate on its current architecture. For the longest time, Venice’s centralization was the single most credible bear case against it.

That bear case has partially closed. Venice migrated to Near AI cloud, which provides provably private infrastructure via TEE attestation. Near’s servers are still centralized. But Venice can now claim cryptographic proof of privacy, not just a policy promise. The decentralization gap between Venice and Dolphin v2 is narrower than it was six months ago.

What remains is a pricing question. Peer-to-pool on consumer GPUs is structurally cheaper than centralized cloud at scale, if the network reaches sufficient density. If Dolphin v2 delivers meaningfully cheaper inference than Venice at comparable quality and latency, the differentiation holds. If the pricing delta is marginal, Venice’s brand, distribution, and DIEM mechanic win by default.

I am not rotating out of $VVV into $POD before v2 ships and generates real utilization data. The winner in this cycle is already identified. Switching to the earlier-stage derivative before it proves independent value accrual is how you give back gains chasing asymmetry that may not materialize. Watch v2 adoption. Watch the pricing differential. If Dolphin starts pulling users from Venice on price and the peer-to-pool density compounds, that is the rotation signal. Until then, POD is speculative sizing at best, and Venice is the position.

3. Canton: the question that didn’t get answered

Canton’s bull case is simple and the bear case is equally simple. The network has two layers: private synchronizers, where institutions like Broadridge run their own subnets for internal settlement, and the Global Synchronizer, which handles cross-subnet transactions. CC token demand comes exclusively from the Global Synchronizer. Private synchronizer activity, including Broadridge’s $350B+ in daily repo settlements, generates zero CC fees. The token only accrues value when institutions need to talk across subnets.

Alex understood this when I pushed on it. He did not dodge the question. He agreed: if private synchronizer activity stays siloed, the fee capture thesis does not work regardless of how much TVL sits on the network. Canton could have quadrillions of represented TVL and generate negligible CC demand if none of it crosses subnet boundaries.

The numbers have improved since earlier in the year. Global Synchronizer fees are running at approximately $2.2M per DeFiLlama. Emissions were halved earlier this year from 45M to 22.5M CC tokens. At current prices, that is roughly $3M in new supply hitting the market. The gap between fees and emissions has closed significantly. Canton is closer to break-even on its token economics than it has ever been.

That is not a bull case. It is a precondition. Break-even on emissions means the bleed has slowed. It does not mean demand is compounding.

The fulcrum is whether private synchronizers start routing cross-subnet transactions through the Global Synchronizer. That is the single data point that changes the thesis from “interesting architecture with contained fee capture” to “the institutional RWA settlement layer with compounding CC demand.” October DTCC routing is the named catalyst, but the question is structural, not event-driven. DTCC going live does not automatically route through the Global Synchronizer. Each institution’s architecture decision determines that.

Current position: watching. If private synchronizer activity starts crossing into the Global Synchronizer at measurable volume, that is the entry signal. Until then, Canton is a network with impressive represented TVL and an emission profile that is finally becoming defensible, not a CC buy thesis.

The one thing I disagreed with

RWA: the whitelist problem Alex didn’t have an answer to

Total tokenized RWA value has grown roughly 11x since 2024 and sits at approximately $33B today. That is the number CT quotes. That is the number Alex cited in his “$26B RWA Explosion” video. It is real growth and it is directionally correct.

What almost nobody quotes alongside it is the DeFi utilization rate: approximately 7.7%. That is the share of tokenized RWAs productively deployed in DeFi protocols. The other 92.3% sits in whitelist prison, earning T-bill yield for its issuers, generating zero activity for the DeFi ecosystem it is theoretically supposed to animate.

BUIDL, BENJI, JTRSY: every major tokenized security has a transfer restriction smart contract baked in at issuance. They can only be held by KYC-whitelisted wallets. Maple, Centrifuge, and Pendle are permissionless protocols. Their smart contracts are not on BlackRock’s, Franklin Templeton’s, or Janus Henderson’s approved counterparty list. Legally, BUIDL cannot be deposited into Maple today.

This is not a regulatory gap the CLARITY Act closes. It is a business decision by the issuers. Regulatory clarity will provide legal guardrails. It will not force BlackRock to whitelist a permissionless DeFi protocol. If they decide as policy never to do so, the $30B stays frozen regardless of what any legislation says. Alex retreated to the birds-eye view when I pushed on this mechanism. That retreat was telling: the whitelist question is over the pay grade of most RWA bulls because it requires reading the actual smart contracts, not the press releases.

The one experiment worth watching is Grove Basin. Centrifuge, Coinbase’s designated tokenization infrastructure partner with $1.43B in tokenized RWA TVL, is building a $1B on-chain exit-liquidity facility for JTRSY. The Centrifuge builder @0x4Graham framed the problem plainly: “The standard for DeFi is deep instant liquidity. RWAs haven’t had that. That’s been the blocker.” Grove Basin is the specific infrastructure fix: give institutions a credible exit path so they can deposit JTRSY into DeFi without the risk of being stuck in an illiquid position. ETA Q3 2026, unconfirmed, execution risk is real. Centrifuge has missed previous roadmap dates.

The global access argument is the underpriced angle. If you are a Western institution with full brokerage access, tokenized equities offer marginal utility. If you are managing capital in India, Southeast Asia, or Latin America, on-chain tokenized equities are the only clean path to Tesla or Apple without routing through a US broker. Alex called this “an amazing point” when I raised it. Most RWA coverage implicitly assumes a Western institutional audience. The emerging markets unlock is the part of the narrative that is not priced.

My position: cautiously bullish on the direction. Not allocating size until the inflection is visible in the utilization rate, not just the headline TVL number. Grove Basin shipping and generating measurable JTRSY flow into DeFi would be the first real signal. The CLARITY Act matters but it is not the bottleneck. The bottleneck is whether issuers choose to open the gates, and that is a business negotiation, not a legislative one.

TIBBIR: The gift that keeps giving

One paragraph. The evidence, laid out cold.

TIBBIR is RIBBIT spelled backwards. The wallet that deployed the TIBBIR contract is Mickey’s original Ethereum address. That wallet has $4M in fees sitting in it, untouched since TGE. Robinhood shares are listed under “Tibber LLC” in SEC filings. Ten Ribbit Capital members follow the frog account. The website mirrors Ribbit Capital’s design with the font reversed. Ribbit Capital is arguably the best fintech venture firm of all time. They backed Credit Karma, Robinhood, Nubank, and Coinbase. The market cap is approximately $100M. The falsification condition is specific: Ribbit publicly distancing themselves. They have had ample time and ample reputational incentive to do so. They have not.

Let readers decide.

*Watching closely.*

---

*Alessandro runs the 247 Research channel inside Crypto Banter’s paid Discord. Follow him at @Alessandrorisk on X.*

*ROCH Labs is an independent research and investment content platform. Substack: rochlabs.com | X: @degenrsc*

Why I’m writing this now

On May 23, 2026, QCOM moved +11.6% in a single session. Closed at $238.16. The 39-analyst consensus average target before that move was $177-$181. The stock blew clean through the entire analyst target band in one day.

Here’s the part that matters: none of those 39 desks have updated their models yet.

When Cristiano Amon provides any directional FY2027 framework at the June 24 Investor Day, every one of those analysts has to update simultaneously. That is not a catalyst. It is a mechanical consequence of where the price is relative to where the models are.

And then there’s the Ming-Chi Kuo report. Kuo (TF International Securities, 233K followers, the highest-credibility supply chain analyst in consumer electronics) published a survey in late April reporting that Qualcomm and MediaTek are co-development partners with OpenAI on a custom smartphone processor designed for an AI Agent-focused phone. 924K impressions. 179 quote-tweets. Mass production target 2028. Revenue per chip: Kuo estimates one AI chip project is worth 30-40 standard mobile processors in revenue. I’ll come back to what this means and what the limits of it are.

Three demand vectors are building simultaneously. The market is pricing one.

The three demand vectors

1. Automotive: the cleanest moat in the story

Automotive is a genuinely different business from mobile. ADAS inference cannot go to the cloud. Sub-10ms latency requirements for safety-critical workloads make cloud inference physically impossible. Not economically suboptimal. Physically impossible. The round-trip latency on any cloud connection is 40-80ms under ideal conditions. A collision avoidance model cannot wait 40ms. Every automotive ADAS chip sold is a permanent, structurally non-negotiable edge inference win.

The numbers, per Q2 FY2026 earnings and Q3 guidance:

• Automotive revenue: $1.33B in Q2 (+38% YoY, record quarter)

• Annualized run rate: crossed $5B for the first time

• Q3 FY2026 guide: ~50% YoY automotive growth

• FY2026 exit run rate target (management): >$6B annualized

• Design-win pipeline: $45B (from $3B in 2017)

• In production now: BMW iX3 Ride Pilot since October 2025

The $45B pipeline converts across FY2027-2030. This is not a “future promise” number. It is already in quarterly revenue, growing faster than any other segment, with 3-5 year platform refresh cycles baking in the next few years of revenue before the contracts even need renewing.

Snapdragon Ride Flex is the only shipping chip that unifies digital cockpit and ADAS on a single platform. NVIDIA Orin and Thor are high-performance AV, a different tier entirely. No direct competitor in the unified cockpit+ADAS space.

This is the demand vector the market is most under-pricing because it doesn’t look like “AI” in the way NVDA’s data center revenue looks like AI. It is. It just runs at 90mph on a highway in Munich instead of in a hyperscaler rack.

2. Data center: the binary on June 24

Amon confirmed on the Q2 FY2026 earnings call that Qualcomm will ship custom data center processors to a named hyperscaler before end of 2026. The customer has not been disclosed. The AI200 targets commercial shipments in 2026. The AI250 ships in 2027 and carries up to 768GB onboard memory, which matters because inference at scale is memory-bandwidth-bound, not compute-bound.

Here is the critical point: as of May 2026, there are zero FY2027 revenue estimates for AI200/AI250 on any bank desk. Zero. Not a single analyst has published a quantified FY2027 data center contribution. There is nothing to model yet because Amon has not given a number. When he gives even a directional range on June 24, every analyst is forced to build a model from scratch for a business line currently sitting at zero in their spreadsheet.

The stock was at $238 with every desk at $177. Whatever the June 24 number implies, the revision cascade follows mechanically regardless of whether the fundamental thesis is right.

The bear argument here deserves fair treatment: Google TPU-v6, Amazon Inferentia-3, and Meta Artemis all already exist. Hyperscalers have structural incentives to keep inference in-house and the capability to do it. The unnamed hyperscaler shipment could be a 5,000-unit evaluation run that never converts to commercial volume. One cancelled NRE agreement wipes the narrative. If Amon delivers no FY2027 framework on June 24, the data center thesis stays speculative and the multiple ceiling reverts to 20-22x on handset/auto fundamentals alone.

3. AI Agent phone: a 2028 story, not a 2026 trade

The Kuo report is worth understanding precisely because it is being misread in both directions.

What it says: Qualcomm and MediaTek are co-development partners with OpenAI on a custom smartphone processor for an AI Agent phone. The chip handles on-device context awareness and small-model inference continuously. Heavy compute offloads to cloud. Mass production target 2028. Specs and supplier selection expected finalized late 2026 or Q1 2027.

What it does not say: that QCOM is exclusive. MediaTek is named in the same sentence. Anyone running a thesis that relies on QCOM being the only partner here is building on a factually incorrect premise.

The revenue math is why this landed with 924K impressions: Kuo frames one AI chip design win as equivalent to 30-40 standard mobile processors in revenue potential. If that holds and QCOM secures meaningful volume for the 2028 ramp, the EPS curve changes materially. At current QCOM automotive ASP dynamics as a reference, that is not an unreasonable order-of-magnitude estimate.

This is a 2028 story. It has no bearing on June 24. The reason it matters now is signal quality: the best supply chain analyst in consumer electronics hardware is naming QCOM as a co-development partner on the most anticipated AI hardware product of the decade. That does not happen to a company the market should be pricing as a smartphone cyclical at 20x.

The CT indicator is also worth noting. Jukan05 (124K followers, tech equity account, was explicitly bearish on QCOM as recently as January 2026) quote-tweeted the Kuo report with: “Should I put together a bull thesis on Qualcomm? $QCOM.” 60 replies. 363 bookmarks on a single question post. He has not published the full thesis yet. When he does, it will circulate widely. Narrative formation at 124K follower accounts with 363 bookmarks per post is a leading indicator of broader CT uptake.

The valuation math

At $238, QCOM’s forward P/E is approximately 20x against FY2026 consensus EPS of ~$12.10. The semiconductor sector median forward P/E is 37x. That is a 46% discount.

For comparison:

• NVDA: ~47x forward P/E

• AMD: ~54x

• ARM: ~115x

• AVGO (most comparable on diversified AI infrastructure revenue mix): ~37x

The FCF yield case is the other side of this. At ~9% FCF yield, the market is pricing QCOM the way you price a business in structural decline. The sector median FCF yield is ~2%. A company returning $3.7B to shareholders in a single quarter (Q2 FY2026: $2.8B buybacks + $945M dividends) plus a freshly authorized $20B buyback program does not print 9% FCF yield from a position of weakness.

The historical context matters here. QCOM traded at ~30x P/E during the 2020-2021 smartphone cycle peak. No AI premium required. Just re-rating the automotive and IoT mix shift to something closer to prior-cycle highs would imply $260-280 on EPS alone. The stock is not expensive relative to its own history. It is trading near mid-cycle valuation while the revenue composition has shifted materially underneath it.

Re-rating to the sector median (37x) on FY2027 EPS of ~$14.00 implies ~$518. I am not underwriting that. It requires a fully validated data center business with named customers and recurring revenue, which does not exist yet.

The scenario I think is underwritten:

Partial re-rating to 28x (halfway between current 20x and AVGO’s 37x) on FY2027 EPS of ~$13.20 implies ~$370, approximately +55% from $238. This does not require QCOM to become NVDA. It requires the Street to stop pricing it as a phone chip company once data center revenue becomes visible.

The honest bear case

The arithmetic runs first.

QTL generated $1.38B in Q2 FY2026 at 72% EBT margin. That is approximately $1B per quarter in high-margin profit, representing ~30% of non-GAAP operating income. The Apple licence is terminable. If it expires unrenewed, nothing in automotive or IoT replaces that margin on a two-year timeline. This risk sits entirely outside the edge inference and data center thesis and does not get better if both theses deliver.

Against the edge inference case: AI Hub has 1,800 registered companies and 175+ pre-optimized models. It also has zero published DAU, MAU, or deployment volume figures anywhere. “1,800 companies” is a registration count, not an active usage figure. The platform is real. The adoption depth is unverifiable from public data. MediaTek’s Dimensity 9500 demonstrated a 20B-parameter LLM running on-device. The premium positioning QCOM relies on in Android is compressing faster than the bull case assumes. Thermal throttling is also real: sustained on-device inference degrades significantly from burst-mode TOPS claims under thermal limits. QCOM’s marketing figures are burst-mode. The sustained benchmark that matters more as usage patterns evolve is lower.

Against the data center bet: the specific architecture of the AI Agent phone (small model on-device, heavy compute offloads to cloud) means QCOM is not a play on AI data center scale. The OpenAI phone validates edge inference, not cloud inference. The AI200/AI250 is a separate product line from a different category. One validates the thesis that QCOM knows how to build inference silicon. The other has to stand on its own commercial merits, which are unproven.

The historical reversion pattern is worth naming explicitly. QCOM has run a diversification re-rating story four times: RF front-end (2019), IoT (2021), automotive (2023), and now AI/data center (2026). Each prior attempt saw the multiple expand and then contract when a handset guidance cycle disappointed. The automotive revenue evidence in the current cycle is stronger than in any of the prior three attempts. But the pattern exists and Q3 FY2026 handset guidance -- management guided ~$4.9B in handsets for Q3, down from $6B in Q2 -- means the near-term handset print could reassert the cyclical narrative if it misses.

The trade

I am not positioned yet. This is a pre-event setup note.

Entry: $199-207. The post-earnings support base from May 15-21 (five consecutive daily closes), the June-July 2024 structural zone, and approximately 20x forward P/E on FY2026 consensus all converge in that range.

Stop: $189 daily close. Below the May 20 swing low of $191.02. Risk at entry: 6-9%.

TP1: $247.9. Reclaim of May 12 intraday high. Pure mechanics, no thesis confirmation required.

TP2: $300. No overhead supply on weekly chart between $248 and $300.

TP3: $350-370. Full thesis, conditional on June 24 delivering a quantified FY2027 data center framework.

R/R to TP1 from mid-entry (~$203): approximately 2.5:1. Catalyst window: June 24 Investor Day.

Where I land

One thing the Kuo report changes is the narrative ceiling. Before it, the QCOM re-rating case was a valuation argument against a still-skeptical market. After it, the highest-credibility supply chain analyst in the world is naming QCOM as a co-development partner on an OpenAI AI Agent phone with 30-40x the revenue potential of a standard mobile processor.

MediaTek is in the room too. The exclusive framing is wrong and I want to be precise about that.

But here is the thing about the setup as a whole. Automotive ADAS cannot go to the cloud on physics grounds. OpenAI is designing a phone around on-device inference. The unnamed hyperscaler is receiving custom data center processors before year end. These three demand vectors are not coincidental. They are converging on the same underlying capability: Qualcomm’s edge inference silicon is good enough to be chosen for the most latency-sensitive workload in consumer electronics (automotive), the most anticipated AI product of the decade (OpenAI phone), and a hyperscaler’s production data center.

The market is pricing a smartphone chip company at 20x.

The upgrade cascade is not a question of whether. It is a question of when. June 24 is the most likely trigger.

Watching closely.

*Conviction: MEDIUM. Not positioned. Upgrades to HIGH on two conditions: Amon delivers a quantified FY2027 data center framework on June 24, and Q3 automotive holds the guided ~50% YoY growth. One without the other is not a full re-rating.*

*Not investment advice.*

Sources

1. [QCOM Q2 FY2026 Earnings Press Release — Qualcomm Investor Relations](https://investor.qualcomm.com/news-releases/news-release-details/qualcomm-announces-second-fiscal-quarter-2026-results) — Q2 FY2026 automotive revenue $1.33B, +38% YoY; annualized run rate; $45B design-win pipeline; $2.8B buybacks + $945M dividends; $20B buyback authorization.

2. [QCOM Q2 FY2026 Earnings Call Transcript — Seeking Alpha](https://seekingalpha.com/article/4786000-qualcomm-qcom-q2-2026-earnings-call-transcript) — Cristiano Amon confirms custom data center processor shipment to named hyperscaler before end of 2026; AI200 commercial shipment timeline; Q3 FY2026 guidance including ~50% YoY automotive growth and ~$4.9B handset segment.

3. [Qualcomm Investor Day 2026 — June 24 — Qualcomm Investor Relations](https://investor.qualcomm.com/events-presentations) — Scheduled June 24, 2026. Amon to provide strategic framework; data center business update expected.

4. [Ming-Chi Kuo X Post — OpenAI AI Agent Phone: Qualcomm and MediaTek as Co-Development Partners](

— TF International Securities supply chain survey. QCOM and MediaTek co-development partners for OpenAI custom smartphone processor. Mass production target 2028. Revenue per AI chip estimated at 30-40x standard mobile processor. 924,241 impressions.

5. [Jukan05 X Post — QCOM Bull Thesis Framing](

— Quote-tweet of Kuo report. 124K follower tech equity account previously bearish on QCOM as of Jan 2026 flags intent to build bull thesis. 363 bookmarks.

6. [Snapdragon Ride Flex — Qualcomm Product Page](https://www.qualcomm.com/products/automotive/snapdragon-ride) — Unified digital cockpit and ADAS on single platform. Only shipping chip in this category. BMW iX3 Ride Pilot launched October 2025.

7. [MarketBeat QCOM Analyst Price Targets — Consensus Data](https://www.marketbeat.com/stocks/NASDAQ/QCOM/price-target/) — 39-analyst consensus average price target $177-$181 pre-May 23 move. Baird $300 target raised May 1, 2026. 38 desks below current price $238.

8. [S&P Global Market Intelligence — Semiconductor Sector Forward P/E Consensus](https://www.spglobal.com/marketintelligence/en/) — Semiconductor sector median forward P/E approximately 37x; NVDA ~47x; AMD ~54x; ARM ~115x; AVGO ~37x as of May 2026.

9. [QCOM Form 10-Q Q2 FY2026 — SEC EDGAR](https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=QCOM&type=10-Q) — QTL segment Q2 FY2026 revenue $1.38B at 72% EBT margin. Full financial statements.

10. [Qualcomm AI Hub — Developer Platform](https://aihub.qualcomm.com/) — 1,800+ registered companies, 175+ pre-optimized models as of May 2026. On-device AI model deployment platform.

11. [QCOM Historical Price Data — May 23, 2026 Session](https://finance.yahoo.com/quote/QCOM/history/) — Closing price $238.16, single-session move +11.6%. May 20 swing low $191.02.

12. [MediaTek Dimensity 9500 — On-Device LLM Benchmark](https://www.mediatek.com/products/smartphones/dimensity-9500) — 20B-parameter LLM on-device capability. Direct competition for premium Android AI processing against Snapdragon Elite.

13. [Qualcomm AI200/AI250 Data Center Processor Announcement](https://www.qualcomm.com/news/releases/2025/10/qualcomm-announces-ai-inference-processors-for-data-centers) — AI200 commercial shipments targeted 2026; AI250 ships 2027, up to 768GB onboard memory.

- OpenRouter processed over 12 trillion tokens per week by early 2026, up 12x year on year (per OpenRouter / a16z State of AI report, Dec 2025). Falling inference costs expand the market via Jevons’ Paradox which is what makes the trade compelling.

- Decentralized inference providers have real ARR (~$12-14M Venice, ~$6M Chutes) and three structural moats Web2 cannot replicate: privacy, uncensored AI, and a 70-85% pricing advantage.

- Most revenue is still token-subsidized (Chutes ~90% subsidy ratio is worse than the Helium 78% DePIN benchmark). Organic economics at scale are not yet proven.

- Galaxy Digital’s formal institutional report is in production and unpublished. The window for early positioning is open.

- Core: $VVV, $AKT. Higher beta: $TAO, $POD. Farm: Ritual, Inference Labs.

Conviction Tier: MEDIUM CONVICTION

Upgrades to HIGH CONVICTION on enterprise-scale production deployment confirmation from at least one major protocol, OR organic revenue covering more than 50% of total protocol revenue without token subsidies.

PMF is confirmed (Venice ARR, Chutes OpenRouter #1 ranking, DIEM perpetual credit adoption). Tokenomics innovation is real. Pricing moat is structural. Risks are specific and named: subsidy dependency is the primary one, TAO halving pressure is real, Venice centralization debate is unresolved, enterprise scale remains unproven. Size these positions relative to those risks.

Introduction

OpenRouter grew from ~10 trillion tokens processed annually to over 100 trillion as of mid-2025. By early 2026, the platform was handling over 12 trillion tokens per week, a 12x increase YoY (per OpenRouter / a16z State of AI report, Dec 2025). The standard read is that inference is becoming a commodity, costs are collapsing, and that is structurally bad for any provider operating in the space. That read has it backwards, and completely misses the point.

When a resource gets 10x cheaper and usage grows 30x in response, you are not watching margin compression. You are watching Jevons’ Paradox operate at the scale of global infrastructure. The inference market is not contracting as costs fall. It is expanding faster than any model projected, and the protocols positioned in the correct structural slots are compounding into something that has not been formally covered by a single major research institution.

That institutional gap is where this piece sits. Galaxy Digital’s Research Associate Lucas Tcheyan publicly signalled a formal research pivot to decentralized inference in May 2026, soliciting project names for inclusion in a forthcoming report. That report is not yet published. What follows is a synthesis of where the category stands, who the leaders are, and what the real risks look like before that coverage arrives.

The Structural Shift

The history of AI access can be told in three phases.

1. The first was closed AI: expensive, proprietary, censored. Built by OpenAI, Anthropic, and Google on centralised infrastructure, accessible through APIs with content restrictions and data logging baked into the architecture. The pricing reflected the monopoly on both intelligence and distribution.

2. The second was open AI (not the company ironically): The release of Llama, Mistral, and DeepSeek created commoditised base intelligence. Open-weight models collapsed the cost of raw capability. The question that emerged from this phase was not who could build AI, but who would serve it at scale, to whom, and under what terms.

3. The third phase, which is where we are now, is decentralized AI: Token emissions fund research teams without dilutive venture rounds. Idle consumer GPUs yield inference revenue. Distributed compute networks source capacity at ~70-85% below AWS SageMaker pricing and pass that discount to developers routing inference requests at machine speed through agent harnesses running billions of API calls per session.

The transition from the second phase to the third is not hypothetical. Tools built on top of open-weight models were burning billions of inference tokens daily before major closed labs moved to restrict automated harness usage. That restriction, widely read as bearish for inference demand, is structurally bullish for the decentralized layer. When closed labs restrict access, developers migrate to open-weight models on decentralized rails that carry no content policy. The demand does not disappear. It relocates. This is the thesis, as well as the premise of this piece.

The Business Model

The unit economics of a decentralized inference provider are worth understanding precisely, because they are the structural source of the advantage.

Cutting away the jargon, the whole workflow can be written and understood in a few simple steps:

1. Source compute from a decentralized cloud marketplace at ~70-85% below AWS SageMaker pricing.

2. Host open-weight and private AI models at that cost basis.

3. Charge developers via API subscriptions or usage fees that are still materially cheaper than OpenAI or Anthropic.

4. Capture the spread. Then layer in token mechanics that create switching costs no centralised provider can replicate.

The two clearest executions of this model are Venice AI and Chutes.

Venice AI ($VVV)

Venice AI is running ~$12-14M in annual recurring revenue on 50-80B tokens per day, with a single-day peak of 80B tokens, per platform analytics at venicestats.com.

The tokenomics innovation that matters specifically for Venice is DIEM. Here’s how it works in practice; Stake $VVV, earn approximately 18% APY, and mint DIEM tokens. Each DIEM token generates one dollar per day in Venice inference credits, indefinitely.

This is not a governance token or a speculative instrument in the traditional sense. It is a perpetual inference credit: DeFi yield mechanics applied to AI compute. Capital staked into Venice cannot be easily withdrawn without unwinding a position generating daily yield. That lock-in is by design. The Pendle and Penpie analogy from DeFi explain this choice by Venice precisely: PT/YT leverage markets and governance arbitrage on inference credit bribe markets will follow as the ecosystem matures.

Chutes (Subnet 64, Bittensor Ecosystem Project)

Chutes, built on Bittensor Subnet 64, is running ~$6M ARR on comparable token volume, ranked number one on OpenRouter for decentralised inference as of May 2026.

The distinction from Venice is structural: Chutes is fully decentralized, with no centralised infrastructure critique applicable to it. Its subsidy ratio, however, sits at an estimated ~90% i.e. in simple words, nine in every ten dollars of revenue is token-subsidised, not organically generated. This exceeds even Helium’s 78% benchmark at a comparable stage of the DePIN cycle. That distinction matters significantly for the bear case, which I address directly below.

Per ETH Denver benchmarks from February 2026, the decentralized inference segment was already at ~$20-30M ARR across Bittensor subnets, against a subnet market cap of ~$212M. For reference, the broader DePIN sector was generating $72M in revenue against $10B in market cap at the same timeframe. The decentralized inference sub-sector is generating comparable revenue at a fraction of the market cap assigned to DePIN broadly.

That should tell you how early we are in the narrative cycle despite the ~8x pump recorded by VVV token in the past few weeks.

The Stack

Five distinct layers form the decentralized AI inference supply chain. Each carries different maturity, different tokenomics design, and different risk profiles.

The Compute layer

Akash Network ($AKT) is the primary decentralized GPU marketplace, the infrastructure backbone from which most inference providers source capacity. Burn-and-mint emissions tokenomics are live for $AKT. Render Network ($RNDR) and io.net ($IO) serve adjacent compute demand across the same structural thesis.

This is the pick-and-shovel layer: every inference provider that scales through decentralized compute builds on top of it.

The Coordination layer

This is where Bittensor ($TAO) sits on the whole map. Its 128 subnets run in continuous Darwinian competition for resources, talent, and inference share. Grayscale has taken stakes in TAO and is building ETF products around the asset.

The framing that has taken hold institutionally is “TAO is the BTC of AI,” a macro-levered coordination layer providing diversified exposure to the entire decentralized AI stack. At ~$20-30M in ecosystem ARR, it is the most levered expression of the category thesis.

The Inference layer

This is where primary value accrual is happening now. Venice and Chutes lead the current cycle. Lium on Bittensor Subnet 51 is generating ~$600K in monthly burn volume, the largest of any Bittensor subnet. Dolphin AI ($POD) is executing Venice’s tokenomics playbook on consumer GPU infrastructure, with its v2 peer-to-pool network imminent.

The Verifiable Inference layer (a sub-segment for now, but a full segment eventually) is the one the market is not pricing. I return to this in the moats section below.

The Application layer

This covers AI agents, DeFAI, and tooling infrastructure. This is where end-user value accrual eventually concentrates, but where most token fundamentals remain weak relative to the infrastructure layers above them.

The Four Moats

Four structural reasons explain why decentralized inference holds territory that centralised labs cannot enter regardless of capital or compute resources. Below I breakdown exactly what makes them special, and defensible against large centralized incumbents:

1. Privacy:

   1. Per Cisco’s 2024 Consumer Privacy Survey, 84% of GenAI users are concerned about data entered in tools going public. For enterprise customers operating under GDPR, CCPA, HIPAA, and financial data regulations, this is not a preference item. It is a liability constraint.

   2. OpenAI and Anthropic are structurally compelled to log user interactions for model improvement, abuse detection, and compliance auditing. They cannot offer genuine data separation without dismantling their core model improvement pipelines.

   3. Venice AI, Dolphin AI, and the TEE-stack protocols own this market by structural default. The demand is not niche: enterprise legal, healthcare, and financial services clients all face mandates that make inference-with-logging a material compliance exposure.

2. Uncensored AI:

   1. Centralised labs face advertiser sensitivity, regulatory exposure, and reputational risk from uncensored model outputs. Companion AI, penetration testing, red-teaming, political speech in jurisdictions with content restrictions, and enterprise internal tooling with sensitive subject matter are categories the closed labs are structurally blocked from serving at scale.

   2. Venice and Dolphin AI sit permanently on the open-weight side of this divide. As model liability frameworks mature and the market split between compliant-censored and open-weight uncensored AI sharpens, this moat deepens rather than narrows.

3. Pricing:

   1. AkashML inference costs ~$2-4 per million tokens. OpenAI’s API runs ~$15 per million tokens on GPT-class model output; 2026 flagship models range from $2.50 to $30 per million tokens depending on model and token direction.

   2. The 70-85% structural discount to AWS is not promotional: it derives from idle consumer GPU supply at near-zero marginal cost of capital, token emission subsidies covering infrastructure overhead, and no centralised data centre CAPEX on the balance sheet.

   3. The margin structure improves as the network scales. This is the directional opposite of a traditional cloud provider’s cost curve, and it is the structural basis for the lock-in mechanics described in the business model section above.

4. Verifiable Inference:

   1. This is the fourth moat and the least understood. TEE-backed inference with cryptographic attestations produces a proof that a specific model generated a specific output, without revealing the model’s weights or the user’s input data.

   2. For autonomous agents executing financial transactions on-chain, the inference output is the instruction. Without cryptographic proof, that instruction is trusted. With it, it is verified.

   3. Ritual, backed by Archetype with ~$25M raised, is building Infernet: smart contracts that natively call ML models with cryptographic proofs. Inference Labs shipped Sertn’s Proof Inspector in May 2026, generating the highest-engagement technical post in the category that month. Neither has a token.

The narrative has not produced a breakout yet, and that’s understable since we haven’t seen a breakout success, or proof it can work at scale, or has any specific enterprise deals tied to it yet. Despite that, verifiable inference is arguably the most defensible structural moat in the stack and is currently trading at the lowest awareness premium of the four.

The Bear Case

The honest version of this thesis requires stating four risks that could break the thesis around decentralized inference, and make this whole thesis stale. Below I break down each one of them:

1. Dependency Risk:

   1. Chutes is running an estimated ~90% subsidy ratio which means nine in every ten dollars of revenue is token-subsidised, not organically generated. This exceeds even Helium’s 78% benchmark from the DePIN cycle, which was itself considered alarming at the time.

   2. Most decentralized inference revenue is still token-subsidised rather than organically generated. If token prices fall, compute subsidies shrink, the pricing advantage narrows, and users with no structural switching costs have limited reasons to remain.

   3. No protocol in this stack has proven sustainable organic unit economics at scale. That is not a minor caveat. It is the foundational question the thesis must answer to convert from speculative to durable.

2. The TAO halving risk:

   1. This one is specifically for Bittensor-native projects. Daily emissions were cut from 7,200 to 3,600 TAO in December 2025. Subnet miners whose incentives fall below compute cost break-even will exit.

   2. The Pareto distribution of subnet quality means a significant portion face meaningful pressure. Inference subnets with real revenue are better insulated than meme subnets, but the halving risk is present across the ecosystem and the 60-day churn data post-halving is the primary risk variable to monitor.

3. Venice’s centralisation critique:

   1. The argument that Venice runs on centralised infrastructure with a decentralised token wrapper is not a fringe position.

   2. If regulatory pressure tightens around centralised AI infrastructure operating with decentralised tokenomics, Venice faces a structural exposure that Chutes, by architecture, does not.

4. Lopsided demand curve:

   1. Demand is still scarce relative to supply. Significant capital has been deployed into decentralized AI infrastructure. Institutions are running pilots, not production workloads.

   2. No enterprise-scale production deployment is confirmed for any protocol in this stack. The category’s revenue is real. The scale at which it needs to operate to justify current market caps requires enterprise adoption that has not arrived.

What to Watch

Three developments will determine whether this thesis upgrades from its current state to full institutional validation.

1. The Galaxy Digital decentralized inference report is the most important near-term catalyst. When it publishes, it will be the first institutional-grade research document formally scoped to this category. The historical pattern in crypto is consistent: when the first serious institutional report drops on a category with real fundamentals, narrative velocity accelerates regardless of price action at the time of publication. The pre-publication window is where asymmetric positioning has historically been available.

2. The Dolphin AI v2 launch is the nearest product catalyst: If the peer-to-pool consumer GPU inference network ships with an early ARR trajectory comparable to Venice’s first months, it validates the hypothesis that the Venice tokenomics model is replicable at scale on distributed consumer hardware, not just enterprise GPU pools sourced from Akash. That would expand the addressable inference supply significantly and harden the pricing moat thesis.

3. The verifiable inference narrative is the sleeper catalyst: Ritual and Inference Labs have no tokens and no major account has published a dedicated analysis. When the first significant thread or research note covers cryptographic proof of inference at scale, the protocols in this layer will attract pre-token positioning attention. The farming window for those positions exists now, before that awareness arrives.

4. The TAO halving subnet survival data is the ongoing risk monitor: If churn is manageable and inference subnets with real revenue hold their miner bases over the next 60 days, the halving becomes a supply shock narrative for TAO. If churn is severe, it partially invalidates the Bittensor coordination layer thesis at current prices. It will be interesting to watch how this plays out.

In Conclusion

The 12x expansion in OpenRouter token consumption in a single year is not a growth rate. It is evidence of a structural transition in how the world processes intelligence (per OpenRouter / a16z State of AI report, Dec 2025). The protocols serving that demand from the positions the large labs cannot occupy (private compute, uncensored inference, cutthroat pricing, cryptographic verification) are already generating real revenue, and the suits don’t even know as the institutional research coverage has not arrived yet!

That combination rarely persists. The window between confirmed product-market-fit and institutional narrative is historically short once the first formal report drops. The question is not whether decentralized inference is a real sector: the revenue data answers that. The question is whether the subsidy dependency resolves before the institutional wave fully prices the category.

That is the risk. And it is worth taking seriously before dismissing either the thesis or the bear case that sits underneath it.

Sources

Fact-checked as of 22-May-2026

- Ritual $25M raise — Archetype lead (https://cointelegraph.com/news/ai-infrastructure-startup-ritual-raises-25-m-gaps-crypto)

- Lucas Tcheyan, Research Associate, Galaxy Digital (https://theorg.com/org/galaxy-digital/org-chart/lucas-tcheyan)

- Cisco 2024 Consumer Privacy Survey (https://www.cisco.com/c/dam/en_us/about/doing_business/trust-center/docs/cisco-consumer-privacy-report-2024.pdf)

- OpenAI API Pricing 2026 (https://openai.com/api/pricing/)

- Akash Network GPU pricing (https://akash.network/pricing/gpus/)

- Bittensor halving December 12, 2025 (https://blog.mexc.com/news/bittensors-historic-first-halving-starts-december-12-will-tao-rally-to-1000-as-daily-emissions-drop-50/)

- Grayscale TAO ETF filing (https://phemex.com/news/article/grayscale-files-for-bittensor-etf-stabilizing-tao-price-51072)

- VVV Robinhood listing May 19, 2026 (https://www.cryptotimes.io/2026/05/20/venice-token-vvv-rockets-24-as-robinhood-listing-ignites-rally/)

- Venice AI: Programmatic Buy & Burns (https://venice.ai/blog/programmatic-vvv-buy-and-burn)

- Bittensor subnet ARR: Unsupervised Capital (https://www.unsupervised.capital/writing/bittensors-ai-compute-subnets-collectively-reach-20m-arr)

- OpenRouter / a16z State of AI report (Dec 2025): token consumption data (https://openrouter.ai/state-of-ai)

- OpenRouter weekly token data context - Trending Topics (https://www.trendingtopics.eu/chinese-ai-models-overtake-us-rivals-in-global-token-consumption/)

A chart with arrows. A ten-tweet thread. Numbers specific enough to sound credible. Then the market moves against it and the post disappears. No follow-up. No post-mortem.

This is not research. Its a prayer disguised as research.

The tells are always the same. No stated conviction level. No explicit kill conditions. No position disclosures (or worse an advertisement in the garb of research). No mechanism for closing the loop when the thesis fails. The author reserves the right to be right in hindsight and wrong in silence. The reader has no way to distinguish a high-conviction bet from a speculative guess because every post reads the same.

It is structurally dishonest. So I built a different system.

Conviction Is Not a Feeling but a label

Every research note I write opens with one of three words: HIGH, MEDIUM, or SPECULATIVE. That label is the first line. Not buried in paragraph four. Not implied by tone. Written before the thesis begins.

HIGH conviction means the thesis is tested. Multiple confirming signals exist. I am positioned accordingly. If I cannot name three specific scenarios that would invalidate the call, I do not have HIGH conviction. I have wishful thinking.

MEDIUM means I am building a position. One or two signals have confirmed. I am staged in and watching for the third. The risk/reward justifies owning it, not fully sizing it.

SPECULATIVE means the thesis is forming. I may have a starter position or nothing at all. The purpose of a SPECULATIVE note is to document the logic early and state exactly what would upgrade it. If I cannot say what moves it to MEDIUM, I have not thought clearly enough to publish.

The practical difference matters. A HIGH conviction note on NVDA would require five data-anchored thesis points, a specific catalyst with a date, and three named kill conditions. A SPECULATIVE note on ARM would state explicitly: it will not upgrade until royalty revenue beats by more than 10% and v9 architecture penetration guidance moves above 35%. Same sector, different epistemic states. Same format, different labels.

Most research platforms publish both types identically. The audience cannot tell which is which until the outcome reveals it. That is not analysis. That is a lottery where the ticket looks the same regardless of odds.

A Thesis Is Not a Prediction

A prediction says: I think this goes up.

A thesis says: here is the mechanism, here is what would break it, and here is what I own.

The kill section is what separates them.

Every HIGH conviction note I write includes it. The format is three specific scenarios that, if they materialize, mean the thesis is wrong and the position is closed. Not vague scenarios. “Hyperscaler CapEx guidance cut more than 15% in any Q2 earnings call” is a kill condition. “Macro deteriorates” is not.

This is not hedging. Hedging is writing “risks include macro uncertainty” and leaving the reader to interpret it. A kill condition is a commitment device. It states in advance what would change my mind. When that event occurs, I am not permitted to rationalize around it. The condition was pre-defined. The discipline is mechanical.

Losses Should Be Visible

When a thesis is killed, I publish a post-mortem in the thesis graveyard. Every one. No exceptions.

The post-mortem answers three questions: what did I call, what actually happened, and what was the root cause of the miss. The root cause is assigned to one of six categories: narrative risk, timing error, data error, regime change, execution failure, or unknowable at the time of entry.

Over time, the distribution of categories tells you something specific about your analytical process. If most kills are timing errors, your entry framework is too early. If most are narrative risk, you are overweighting fundamentals relative to market structure. The graveyard is a diagnostic tool, not a confession box.

The “unknowable” category is narrow. Most misses are explainable in retrospect. My ai16z position lost 95% before I exited. The thesis was right; agentic AI infrastructure matters. The bet was wrong. I sized into a team, not a thesis. The infighting and internal breakdown that killed the project were not in my kill section because I was too attached to the position to write honest kill conditions. That is execution failure compounded by attachment bias. The post-mortem said so. Attachment to a position is itself a kill condition. I know that now.

Most research platforms never close this loop. Kills are silent. The track record is constructed from hits. The audience ends up with a biased sample and no ability to assess actual edge.

The Framework in Practice

Every note I publish carries a conviction label. Every HIGH conviction note has a kill section. Every closed thesis gets a post-mortem. Every data point is a number. Every position is disclosed at entry, not after the outcome.

The live data infrastructure is at ai-tracker-sigma.vercel.app. It covers the AI supply chain across equities and tokens. The tracker is the data layer behind every note.

Over time this expands. More dashboards. More tracked theses. Full transparency on every position I hold and every one I exit. The track record builds in public, not in hindsight.

The research Discord built on this framework launches soon. It will house every thesis, call, post-mortem, and position update in one place. A living record, not a highlight reel.

If you’re curious to join, follow along ROCH Labs or subscribe to be the first to know.

Usually, if you want a model to know your specific writing style (like your twitter voice) or your specific niche (mine is financial data analysis), you have to upload that data to a cloud provider like Microsoft Azure, which powers OpenAI’s infrastructure.)

To receive persaonlized responses from an LLM provider like OpenAI, your data must be sent to and stored on their remote servers.

QVAC changes this as the framework allows data to stay on your device, and bypass the cloud entirely because the computation happens locally on your hardware.

While for most things, it probably doesn’t matter for the cloud to have access to all your data. But for sensitive stuff, like financial audits, or proprietary investment research, using a local framework like QVAC will allow you to retain 100% custody.

A pre-trained LLM like Llama, Qwen is like a super-smart but generic university professor who knows everything about the world in general. If you want this professor to become your personal doctor AI (that understands your specific health history, diet, symptoms, and speaks in your style) you need to teach them your private medical notes, blood tests, Whoop data etc.

teaching = fine-tuning = updating the model’s knowledge with your data.

In the old way, we would retrain the entire professor from head to toe, and change very single connection in their brain. For a 13B parameter model, that’s billions of numbers to update. This needs huge servers, costs a fortune in electricity/GPUs, takes days/weeks, and your private data has to leave your phone.

This is where LoRA (Low-Rank Adaptation) is genius. LoRA says don’t touch the professor’s core brain at all. Instead, give them a tiny set of clip-on cheat sheets or post-it notes that they can consult everytime they answer.

These post-its only contain a very small number of new instructions (often just 0.1% to 1% of the original model’s size - up to 99% fewer parameters to actually train.)

The original professor stays frozen (unchanged, safe, no risk of “forgetting” general knowledge.)

When the professor speaks, they combine: original brain (frozen) + tiny LoRA post-its (your personal tweaks).

The answer feels fully personalized to you, but almost no extra compute/memory is needed.

Mathematically its clever. The update to any big weight matrix is approximated as the product of two much smaller matrices (low rank = skinny rectangles instead of huge squares). So instead of changing 10,000 x 10,000 numbers, you only train something like 100 x 10,000 + 10,000 x 100 = ~2 million numbers. Huge savings.

BitNet already makes the base model tiny and fast on phones (weights are just -1/0/+1 instead of full floating point numbers which already saves ~70-90% of memory & compute).

But fine-tuning BitNet normally was still hard/impossible on phones because even “updates” were too heavy.

LoRA slashes the update size so dramatically that now the whole personalization process fits in a phone’s limited RAM and memory.

Think of your phone’s AI as a very compressed zip file of a genius librarian (BitNet makes the zip super small so it fits on phone.)

LoRA = keep the zipped library untouched, just add a tiny bookmark file with your personal notes/index. Your phone can handle adding/using the bookmark easily, and when you ask questions, the librarian reads the main zip + your bookmark instantly.

It turns AI from “rented cloud services that sees all your data” into “your own private brain extension that lives on your device and learns only from you.

No more paying $20/month to OpenAI, no data sent anywhere, no censorship, works offline.

Tether/QVAC solved making LoRA + BitNet work cross-platform (AMD/Intel/Nvidia/Apple/Mobile GPUs) for the first time.

LoRA is the unlock button that lets billion parameter personalization escape data centers and live in your pocket. That’s why Paolo and the team are calling it the start of “Stable intelligence”. If this clicks now, the rest of the announcement will feel much more exciting and logical.

Now that you understand LoRA, the post should no longer feel “cool tech jargon + big numbers” shill. Impressive but abstract!

Now that you grasp LoRA as the “tiny post’it notes” trick that freezes the huge core model and only trains a minisule add-on layer (up to 99% frwer paramters to update), the whole thing snaps into place and becomes genuinely revolutionary.

The “billion-parameter training on a phone” claim stops sounding impossible.

Fine-tuning a 13B model normally means updating billions of numbers which needs massive VRAM and power that no phone has.

But with LoRA, you’re only training maybe millions (or fewer) of tiny adapter parameters. Add BitNet’s extreme compression (weights as simple as -1/0/+1), and suddenly that tiny update process fits in a phone’s limited RAM/battery.

The iPhone demo (13B fine-tine), and Samsung/Pixel 3.8B ones aren’t hype, they’re the direct result of LoRA slashing the workload by orders of magnitude.

The “biggest unlock” line hits hard. Paolo calls heterogeneous GPU fine-tuning the biggest unlock because LoRA + BitNet now works everywhere (not just Nvidia CUDA). Before, even if BitNet existed, personalizing it required expensive Nvidia rigs or cloud. Now your AMD laptop, Intel PC, Apple Silicon Mac, or flagship phone can do it.

LoRA is the key that democratizes that persaonlization step azcross hardware - no more “sorry, only works on $10K GPU”.

Privacy and “serve the people” vision feels tangible, not fluffy.

Without LoRA, “local private AI” would mean running a generic frozen model (no real personalization) or shipping your data to the cloud for fine-tuning.

LoRA lets the model learn deeply from your emails/docs/health data entirely on-device, with almost no extra cost. Your AI becomes truly “yours” - customized to your life, offline, private forever.

That’s why Paolo frames it as the “first real-world signal of a local private AI that can truly serve the people.”

“Era of Stable Intelligence” lands as a real shift.

Tether AI is the stablecoin moment for decentralized artificial Intelligence

“Stable” here echoes stablecoins: reliable, decentralized, user-controlled, and no central gatekeepers. LoRA + BitNet + cross-platform Fabric = the technical foundation to escape cloud dependency. What used to be locked in data centers (personalized frontier AI) now “escapes” to your pocket.

It’s not just faster/cheaper but it’s a philosophical unlock toward AI sovereignty.

In short, LoRA isn’t just a technique, it’s the unlock button that turns theoretical edge AI into practical reality today.

The announcement isn’t about raw model size anymore. It is about who controls the intelligence (you, on your device) instead of renting it from Big Tech.

With this lens, the post reads like a declaration of independence for personal AI, and the demos prove it’s not vaporware.

Super exciting if you’re into decentralization, privacy, or just hating monthly API bills.

Today we follow that heat all the way up the stack; from a single chip to a full-scale data center running AI workloads around the clock.

The Wattage Waterfall

A single logic operation at the level of a chip generates heat that demands cooling. A cluster of ten thousand chips demand a power grid. A training run demands that the grid run without interruption for weeks, and once a model deploys, inference demand runs the grid forever.

The Chip: The micro-unit of compute

A single H100 draws 700W of power at peak. One H100 server (8 GPUs) draws 10.2kW of total system power. A single GB200 NVL72 rack - Nvidia’s current Blackwell configuration draws ~120kW. A standard office building draws roughly 50-100 kW which means one AI training rack consumes more power than an entire office building. (1), (2), (3)

The Cluster: Where scale meets physics

A frontier model training cluster runs 10k to 25k+ GPUs simultaneously. At 700W per H100, a 10k GPU cluster draws 7MW continuously. xAI’s colossus cluster in Memphis is ~100,000 H100s drawing ~150-200 MW continuously. (1), (4), (5)

The training run level: The wattage it takes to bring GPT-4 to life

GPT-4 is estimated to consume ~50 GWh of power for training. This is equivalent to powering ~4,800 average US homes for a full year. For xAI’s Grok 4, estimates show ~310 GWh of power consumed for training, a 5-6x increase in magnitude over GPT-4. As models become bigger, the training compute will continue to expand, and Epoch AI estimates training compute to scale ~4x per year and by extension the energy cost of training scales at roughly the same rate. (5), (6), (7), (8)

The inference level: Where energy demand becomes permanent

OpenAI CEO Sam Altman disclosed in a June 2025 blog post that a single ChatGPT query uses ~0.34 watt-hours. Data compiled by Epoch AI independently corroborated Altman’s own estimates and calculates ~0.3 Wh per query. Altman equated this to an oven in usage for a little over one second, or a high-efficiency lightbulb in use for a couple of minutes in his blog. (6), (9), (10)

At 2.5B daily queries (or prompts) reported by TechCrunch citing OpenAI in July 2025 allows us to infer that the daily energy demand from inference alone costs 0.34 x 2.5B watt hours of electricity. In other words, ~850 MWh per day, which works to an annual run rate of 850 MWh x 365, ~310 GWh per year. (11)

As noted above, GPT-4 model training consumed ~50 GWh of electricity. A simple division shows that inference would consume roughly the equivalent of the electricity consumed in the overall training process in ~59 days (50,000 MWh ÷ 850 MWh/day = ~59 days). MIT further states that Inference’s share of the total AI lifecycle energy is ~80-90%, and reasoning models (o1/o3-class models) only escalate this consumption as data from Epoch AI shows 2.5x more tokens consumed by reasoning models over regular models. (6), (10)

The Data Center Level: Where it all aggregates

IEA estimates global data center energy consumption to double from ~415 TWh (c.1.5% of global electricity) to 945 TWh as the base case between 2024 and 2030. For context, this is equivalent to the entire current annual electricity consumption of Japan. A Goldman Sachs report further adds that data centers will command 8% of the total US power consumption by 2030 against ~3% in 2022. This massive demand for power explains the approx. $720B grid spending estimates by 2030 by Goldman Sachs, and an estimated ~$736B capex announcements by the top 5 hyperscalers in 2025-26 alone as outlined above. (12), (13)

Conclusion

The wattage waterfall makes the constraints of physics (thermodynamics) structural requirements. This brings us to the three primary conclusions relevant for all investors trying to build a foundational understanding of the AI trade.

First, power must be generated. Second, that power must be effectively transmitted across the racks, and third, these AI workloads will generate significant heat which must be removed from the environment.

These three requirements not only mandate large upfront investments in the build-out for power, grid, and cooling infrastructure; but also force them as structural, not cyclical requirements irrespective of who wins the model race.

Now that we’ve explained the constraints of thermodynamics in Part 1, and the current energy & cooling requirements for SOTA chips powering massive AI workloads, the next question is who builds it, who powers it, and who profits from it.

In Part 3, I'll map the exact companies whose business models exist to solve the physical constraints outlined above. The investment case for each one is anchored in physical laws that don’t change regardless of who wins the model race. Stay tuned!

If you found this useful, subscribe. Part 3 drops next week.

Citations

1. NVIDIA Corporation, "NVIDIA H100 GPU — Product Specifications," accessed February 2026.

2. NVIDIA Corporation, "NVIDIA DGX H100 Datasheet," March 2022. Document number A4-2146027-R3.

3. NVIDIA Corporation, "DGX GB200 NVL72 Datasheet," NVIDIA Documentation, accessed March 2026.

4. Pilz, K., Rahman, R., Sanders, J. and Heim, L., "AI Training Cluster Sizes Increased by More Than 20x Since 2016," Epoch AI, October 23, 2024.

5. James Sanders, Luke Emberson and Yafah Edelman, "What did it take to train Grok 4?" Epoch AI, September 12, 2025.

6. James O'Donnell and Casey Crownhart, "We did the math on AI's energy footprint," MIT Technology Review, May 20, 2025.

7. U.S. Energy Information Administration, "Electricity Use in Homes," updated December 18, 2023. Derived estimate: 50 GWh ÷ 10,500 kWh/household/year = ~4,762 households. Rounded to ~4,800 in text.

8. Sevilla, J. and Roldán, E., "Training Compute of Frontier AI Models Grows by 4-5x Per Year," Epoch AI, May 28, 2024.

9. Sam Altman, “The Gentle Singularity,” blog.samaltman.com, June 11, 2025.

10. You, J., "How much energy does ChatGPT use?" Epoch AI, February 7, 2025.

11. Dastin, J., “ChatGPT users send 2.5 billion prompts a day,” TechCrunch, July 21, 2025.

12. International Energy Agency, “Energy and AI — Energy Demand from AI,” IEA, April 10, 2025. https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai

13. Goldman Sachs Research, "AI to drive 165% increase in data center power demand by 2030," Feb 4, 2025.

A Physics first lens to playing the AI trade

Physics is the baseline for the natural world, and also the absolute ceiling for any problem we solve (including artificial intelligence.) Everything above the ‘physics layer’ are human choices that can theoretically be changed. Confusing human choices for physics laws is what most get wrong.

The analysis that follows is grounded in the constraints and opportunities physics imposes. Hard science, not media narratives, will decide how to find the winning opportunities in the AI trade.

The physics that follows exists to serve the investment thesis, not academic completeness. The concepts most applicable are chosen to highlight the constraints, build the analytical foundation, and establish a new lens to evaluate the AI trade.

This framework also serves as a filter to fact-check every tall claim about AI disruption. physics is the reality check that prevents costly mistakes born of following the crowd rather than grounding analysis in reality.

The Physics behind the AI trade

At its core, the entire AI lifecycle from inception to end is governed by five primary physical fundamentals. Each manifests at various layers of the AI assembly line.

1. The law of Thermodynamics (Landauer’s Limit and Heat Dissipation)

2. The law of speed of light

3. The principles of Quantum Mechanics

4. The laws of information theory (Shannon’s theorem)

5. The law of Wave physics (Diffraction Limit)

Thermodynamics is already the dominant cost driver in AI infrastructure. The energy and cooling buildout it demands is leading capital allocation decisions across every stakeholder in the race to dominate AI. (1)

Data compiled by Goldman Sachs shows the five largest hyperscalers in the US will deploy a cumulative $736B in Capex for the AI buildout in 2025 and 2026 alone. Going further, McKinsey has projected a total investment of ~$5.2 trillion for AI data centres by 2030. (2)

Of that $5.2 trillion, McKinsey estimates $1.3 trillion flows directly into the energisers; the utilities, cooling system manufacturers, and electrical infrastructure providers whose entire business exists to solve the heat and power problem thermodynamics creates. This is the thermodynamics trade expressed in dollars.

The IEA projects the total demand for energy from data centres to double from ~415 TWh in 2024 to ~945 TWh by 2030, this is the equivalent to adding the entire electricity consumption of Japan in 2024 to the global grid in just six years. These figures establish the scale of what thermodynamics demands in capital terms, and the physics below explains why this demand is permanent. (3, 4)

Thermodynamics imposes physical energy constraints on chip compute capabilities

If you strip away AI to the precise point where physics shows up, it boils down to a single factor: transistors switching states. Billions of times per second, per chip. Those switching events are what execute the matrix multiplications underlying every model, and every switching event costs energy and generates heat.

Every compute operation is subject to the constraints imposed by the second law of thermodynamics. A constraint neither engineering nor software can solve. This is nature imposing its will on every transistor switch on every chip at every data centre ever built by humanity.

The physical law creates two distinct constraints on compute, one theoretical, and one practical. Understanding both builds the foundation for our thesis that the energy infrastructure trade isn’t cyclical capex but a permanent structural requirement.

Constraint 1: Landauer’s Limit - The Theoretical Floor of Compute

First introduced in 1961, the Landauer’s limit provides the baseline of the minimum quantity of heat dissipated in the environment to erase a single bit of information. At room temperature (~300K), the minimum heat released is 2.8 × 10⁻²¹ joules per bit operation. This is thermodynamics enforcing absolute limits no material, architecture, optimization or engineering can go beyond. This is the theoretical floor of all compute, including AI.

Peer reviewed literature on this topic argues that modern chips release roughly a million times more energy per logic operation which exceeds the Landauer’s limit by many orders of magnitude. (5)

While this sets the physics enforced ceiling on compute per watt, a better lens to understand this is backed by solid research published by Ho, Erdil & Besiroglu (2023) which ignores the Landauer floor and instead tackles the more important and immediate question, “how much more efficient can silicon transistors realistically get before hitting their own engineering limits?” (6)

The current state of the art CMOS architectures, the transistor-based chip designs running today’s AI GPUs are operating ~207x above the maximum efficiency Ho et al’s research outlines. In other words, there is capacity to improve chip efficiency to the order of 207x before we hit the practical limits of how much energy per logic operation these chips will consume.

While this may sound a lot, current AI compute demand is scaling 4-5x per year, and all the efficiency gains are consumed by demand growth before they can actually reduce energy infrastructure requirements. This explains the massive grid capex and hyperscaler expansion efforts in line with the estimates and data compiled by McKinsey and Goldman Sachs outlined above. (7)

Constraint 2: Heat Dissipation - The practical constraint of compute

Landauer’s principle is evidence of physics imposing its will on compute. Every switch event is generating heat as a consequence of executing logic operations within the constraints of physics.

Take the Nvidia H100 for instance, which draws ~700W per chip. The next-gen GB200 NVL72 rack draws nearly 120kW for 72 Blackwell GPUs, in comparison, a single H100 rack consumes 10-30kW. This is 4-12x increase in rack power density in a single generation of GPU offerings. This increase across generations isn’t a one-time thing either, mapping the energy consumption across four generations of chips starting with V100 (~300W in 2017), A100 (~400W in 2020), H100 (~700W in 2022), and the latest generation of GB200 (~1,000W in 2024) shows how each generation demands meaningfully more power and cooling than the last. (8)

Note: Citations 9-12 links to the original source material for the table data above.

At these rates of power consumption, liquid cooling isn’t just optional infrastructure, it is mandatory, and scales permanently with every watt deployed.

To sum up, Landauer’s limit establishes the physical cost of compute which forces generation and consumption of electricity, and heat dissipation mandates cooling infrastructure as heat scales permanently with compute. These aren’t cyclical capex driven by a temporary infrastructure gap. They are structural requirements imposed by physics.

Thermodynamics has already decided what the AI infrastructure stack must look like. The next question is who builds it, who powers it, and who profits from it. In Part 2, I'll map the exact companies whose business models exist to solve the physical constraints outlined above. The investment case for each one is anchored in physical laws that don’t change regardless of who wins the model race. Stay tuned!

If you found this useful, subscribe below. Part 2 drops next week.

Citations

1. Goldman Sachs Research, "How AI Is Transforming Data Centers and Ramping Up Power Demand," July 16, 2024.

2. Jesse Noffsinger et al., "The cost of compute: A $7 trillion race to scale data centers," McKinsey Quarterly, April 2025.

3. International Energy Agency, "Energy and AI — Energy Demand from AI," April 2025.

4. Enerdata via Statista, "Electricity consumption worldwide in 2024, by leading country," July 2025.

5. Chattopadhyay, P., Misra, A., Pandit, T., and Paul, G., "Landauer Principle and Thermodynamics of Computation,", June 2025.

6. Ho, A., Erdil, E., and Besiroglu, T., "Limits to the Energy Efficiency of CMOS Microprocessors," 2023 IEEE International Conference on Rebooting Computing, December 2023. . H100 today achieves ~1.4×10¹² FP16 FLOP/J. The estimated maximum CMOS efficiency ceiling is ~2.9×10¹⁴ FP16/J. That gap is approximately 207x.

7. Sevilla, J. and Roldán, E., "Training Compute of Frontier AI Models Grows by 4-5x Per Year," Epoch AI, May 28, 2024.

8. NVIDIA Corporation, "DGX GB200 User Guide — Hardware," NVIDIA Documentation, August 2025.

9. NVIDIA Corporation, “NVIDIA V100 Tensor Core GPU Datasheet,” January 2020.

10. NVIDIA Corporation, "NVIDIA A100 Tensor Core GPU Datasheet," May 2022.

11. NVIDIA Corporation, "NVIDIA H100 GPU — Product Specifications," accessed February 2026.

12. Lenovo, "ThinkSystem NVIDIA HGX B200 180GB 1000W GPU Product Guide," Lenovo Press, LP2226, January 13, 2026. https://lenovopress.lenovo.com/LP2226 — citing NVIDIA GPU specifications, Table 2.