> For the complete documentation index, see [llms.txt](https://t420.gitbook.io/t420/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://t420.gitbook.io/t420/t420_protocol.md).

# T420\_PROTOCOL.md

**Canonical protocol specification. Referenced by all five T420 repos' PROJECT.md files.**

**Canonical location:** `ZBO19/FleetOS/docs/T420_PROTOCOL.md` **Last revised:** 2026-04-22

When this file changes, the revision propagates automatically to every PROJECT.md that references it. No PROJECT.md duplicates this content — they point here.

***

## 1. What T420 is

T420 is a community-owned robotaxi fleet protocol on Solana. Five products share one Supabase PostgreSQL database:

* **FleetOS** (fleetos.us) — WhatsApp-native fleet service coordination; freemium; supply-side acquisition
* **Robo-Hub** (products.t420.io/robo-hub) — B2B marketplace + Shepherd Academy
* **Robo-Dapp** (products.t420.io) — Shepherd operations cockpit with tokenised ownership
* **OpenClaw** — Autonomous commercial agent stack (AWS EC2)
* **Mission Control** — Coaching surface for the OpenClaw agent team

**Korrex Inc.** (Delaware C-Corp, Miami, #10551658) is the commercial operating entity. The build squad ships product. OpenClaw runs autonomous commercial acquisition.

***

## 2. Ownership economics

| Asset        | Stake                           | Notes                   |
| ------------ | ------------------------------- | ----------------------- |
| Fleet NFT    | 25,000 T420                     | One per tokenised fleet |
| Robotaxi NFT | 500 T420                        | Per vehicle             |
| Rider NFT    | 50 T420 (10% of Robotaxi yield) | V5, not yet implemented |

**Revenue split (Phase 1):** 42% Shepherds / 42% fleet growth / 16% BTC reserve

**Slashing:** 0.5%/day for KPI underperformance against four measured dimensions (utilisation, cost-per-mile, fleet health, customer rating)

**Token trajectory:** $0.005 presale → $0.05 launch → $5.00 by 2030

**Token allocation (current, pending Martin approval):** Team = Korrex = DevCo at 15% (1.5B). Pre-sale at 10% (1B). Seed/Series A investors receive Korrex equity, not direct tokens.

***

## 3. Protocol principles — must not be violated

Any change that puts one of these at risk requires an ADR before it proceeds.

1. **Ownership is the product.** Features must make co-ownership more accessible, transparent, or real.
2. **Org-first, not user-first.** All queries scoped to `company_id`. Work belongs to organisations.
3. **Progressive upgrade, not re-onboarding.** A FleetOS supplier → Robo-Hub contract → Robo-Dapp Shepherd keeps the same relationship record.
4. **Transparent slashing, transparent distribution.** Code paths that reduce Shepherd earnings must be auditable on-chain and readable in their dashboard.
5. **Shepherds are co-owners, not employees.** Never describe Shepherds as workers, contractors, or employees in user-facing text.
6. **The pivot is coded, not voted.** Phase 3 activation uses hardcoded oracle-fed triggers, not DAO votes.
7. **BTC reserve is long-horizon.** Not a trading treasury. Not touched for operational needs.
8. **Dignity Pool accumulates silently.** 2% skim starts Day 1, doesn't disburse until trigger conditions fire.

***

## 4. Shared database boundaries

All T420 products share one Supabase PostgreSQL instance.

**Table ownership:**

* Shared tables (`users`, `companies`, `contacts`, `relationships`, `event_log`) — owned by FleetOS repo, `database/core/`
* Product-specific prefixes: `fleetos_*`, `robo_hub_*`, `robo_dapp_*`, `mc_*`, `blade_*`

**Schema rules:**

* Changes to shared tables are made **only from the FleetOS repo**, never from elsewhere
* Product-specific tables are owned by the respective product's repo
* Migrations are sequential and immutable once merged — write corrections as new migrations, never edit old ones
* The `event_log` table is append-only, 24-month retention, serves as the protocol's audit trail

**Progressive upgrade rule:** A relationship row that starts in FleetOS (supplier responds to magic link) can upgrade to a Robo-Hub contract, which activates in Robo-Dapp. **Same record, progressive state.** Never create a new row when an existing one should upgrade. If an upgrade path isn't obvious, stop and ask.

***

## 5. T420-specific hard rules

These are in addition to the universal engineering rules in CLAUDE.md.

* **Never spend money.** Any action requiring a credit card, paid API key, or financial commitment — stop and ask. The autonomous OpenClaw stack must never hold payment credentials in a way that enables unsupervised spending.
* **Never modify token economics without an ADR.** 42/42/16, stake amounts, slashing rates, trigger conditions are the protocol, not implementation details. Changes require written deliberation before code.
* **Never cross repo boundaries silently.** If work in one repo requires changes in another, stop and flag it. Do not assume the other repo will catch up.
* **Never treat Shepherds as employees in text or code.** No "worker", "contractor", "staff" in any user-facing string, API response, or database field.
* **Never disburse from BTC reserve or Dignity Pool in V1.** These accumulate silently; distribution triggers are V2+ and require explicit protocol-level authorisation.

***

## 6. Commercial team — canonical naming

The four autonomous agents in OpenClaw's commercial stack, coached via Mission Control:

| Name      | Role                        | Function                                         |
| --------- | --------------------------- | ------------------------------------------------ |
| **Atlas** | SDR — Prospecting           | Sources, enriches, qualifies prospects           |
| **Halo**  | AE — Account Executive      | Handles qualified inbound, closes to activation  |
| **Orbit** | CS — Customer Success       | Post-activation shepherding, referral extraction |
| **Pulse** | RevOps — Revenue Operations | Grading, briefs, kill/scale recommendations      |

Earlier persona names (Blade, Caine, Brando, Jack, Brad, Rouke) are retired. Role-based naming is canonical across all repos, documentation, and user-facing surfaces.

***

## 7. AI trust modes — shared across Robo-Dapp and Mission Control

One consistent philosophy for AI/human handoff across the entire protocol:

* **Shadow** — AI observes and logs. No action without human approval per-item.
* **Early Hybrid** — AI acts within scope. Human reviews samples, batch-approves categories.
* **Late Hybrid** — AI acts broadly. Human reviews by exception.
* **Autonomous** — AI acts independently within rate limits. Human reviews weekly or by escalation.

Trust mode progression is per-agent, earned through demonstrated competence, measurable through graduation criteria. Regression to an earlier mode is always available to the human coach.

***

## 8. Revision notes

* **2026-04-22** — Initial canonical version. Supersedes content previously duplicated across five CLAUDE.md files.
* Future revisions logged here with date and summary. Token economics changes require Martin sign-off. Protocol principles changes require ADR.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://t420.gitbook.io/t420/t420_protocol.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.