# GrokBot Token (GBT) — White Paper

**Version:** 0.1 (canon-aligned draft)  
**Date:** 2026-09-29  
**Project:** GrokBot Token · on-ledger **GrokBotToken** · ticker **GBT**  
**Chain:** Internet Computer (ICP)  
**Board:** [gbt.fyi](https://gbt.fyi)  
**X:** [@GrokBotToken](https://x.com/GrokBotToken)  
**Not affiliated with xAI.**

> **Status note.** This paper describes *intended* protocol mechanics from locked canon. Genesis mint has not been executed and the **token launch** (six-epoch sale E1–E6) is **held** pending adequate community support. Nothing here opens a sale or claims a live raise.

> **Published.** Live at [gbt.fyi/whitepaper](https://gbt.fyi/whitepaper) (Ken cleared publish-now, 2026-09-29). Genesis mint and the **token launch** remain **held** — publishing this paper does not open a sale.

Canon sources: `PROTOCOL-CANON.md`, `EPOCH-SIZES.md`, `TREASURY-AND-LP.md`, `MINT-DISTRIBUTION-LP-PLAN.md`, `GO-LIVE-BLOCKERS.md`, `ORBIT-STATION.md`, `OPS-PAY-RAILS.md`, `ROADMAP-STATUS.md`. Where those conflict with older drafts (e.g. steep epoch weights in an early `TOKENOMICS.md` sketch), **canon wins**.

---

## Abstract

GrokBot Token is a fair-launch Internet Computer protocol: a single fixed mint of **100,000,000 GBT**, **zero** insider or team allocation, and a six-epoch pro-rata ICP sale over thirty calendar days. Every epoch’s raised ICP pairs one-to-one with a matching GBT tranche into **protocol-owned permanent liquidity**. Liquidity-provider shares never leave the protocol; claimed LP fees fund an **Agent Treasury** that pays for the automation — cycles, tools, and agent ops — that keeps the fleet and community board running.

The design is deliberately narrow. There is no advertising skim of sale proceeds, no mercenary LP farm, no continuous mint, and no discretionary dump wallet. GBT aims to be **trustless, 100% protocol**: no community vote, no SNS/DAO, no one in charge. Until the canisters are locked, **Orbit Station** is a temporary safety net for bug fixes and the one remaining trust point (current plan, changeable). Launch liquidity lives on **ICPSwap**, with a documented migrate path toward multi-DEX when production-ready. The public ops board is **gbt.fyi**.

---

## 1. Vision

Most token launches optimize for a spike: insiders take supply, sale proceeds vanish into opaque wallets, and liquidity is rented with emissions until the farm ends. GrokBot Token is built the other way around.

**Righteousness as structure, not slogan.** Rules live in canisters. Sale inventory and LP inventory are protocol accounts. Raised ICP becomes permanent depth. Fees become runway for agents that *do the work* — including operating @GrokBotToken — rather than a personal skim.

**Fleet + community.** The token is the economic spine for a GrokBot fleet: protocol canisters on ICP, an ops board the community can read, and Treasury-funded automation that promotes conduct and product, not FOMO. Agents run the X account; Ken is not the poster. The board at gbt.fyi surfaces Credits, Protocol balances, and Epoch sale state in one place.

**Immutable deal, public receipts.** Buyers fund liquidity that stays protocol-owned. Treasury spends are allowlisted, capped, timelocked, and logged. That is the promise: a launch whose economics can be verified, and an operating layer that earns its keep from the market it created.

---

## 2. Problem

ICP DeFi and fair-launch practice repeatedly fail the same tests:

1. **Insider and skim leakage.** Pref allocations and “marketing” cuts of raised ICP break trust before a pool exists.
2. **Mercenary liquidity.** Farm emissions buy temporary depth; when rewards end, the book evaporates.
3. **Opaque ops funding.** Even honest projects fund bots, cycles, and SaaS from wallets the public cannot audit.
4. **Brittle single-key control.** Solo hot-key controllers turn upgrades and pauses into single points of failure — or quiet rewrite risk.
5. **DEX mortality.** Relying on one venue without a migrate path (KongSwap’s 2026 shutdown is the cautionary tale) strands protocol LP.

GrokBot Token answers each with a locked rule: **0 insider mint**, **100% raised ICP → protocol LP**, **permanent protocol-held LP shares**, **Agent Treasury with public spend policy**, **Orbit Station dual-control for the token launch**, and **ICPSwap first with multi-DEX migration later**.

---

## 3. Design

### 3.1 Fair launch and genesis mint (intended)

| Parameter | Locked value |
|-----------|----------------|
| Total mint | **100,000,000** GBT, once |
| After mint | **Lock minting** (no continuous mint) |
| Team / insider / VC | **0** |
| Sale inventory | **50,000,000** GBT → Sale canister |
| LP-pair inventory | **50,000,000** GBT → LP Manager |
| Decimals | **8** (standard DFINITY ICRC-1/2/3 ledger, installed 2026-10-09 with supply 0; fee 0.0001 GBT) |

**In plain words: the ledger.** The ledger is the program that keeps the list of who owns how much GBT. GBT uses DFINITY's standard token ledger, the same software many Internet Computer tokens use, so wallets and exchanges already know how to read it. It keeps a public record of every transfer, mint and burn. Only the Orbit Station (§3.8) can create GBT, and the plan is to do that once. *Why a holder should care:* nobody can quietly print more GBT, and every movement is on a public record anyone can check.

Mint destinations are protocol accounts only. Zero GBT on any EOA or team principal at genesis. A public genesis proof (mint index, two receiving accounts, mint-locked snapshot) is part of the go-live checklist — **mint is not done yet**.

### 3.2 Epoch sale — pro-rata pool, not fixed price

Six epochs span **30 calendar days**. Fixed-price sale is fully retired. Each epoch opens a **Sale tranche** (a pool). Participants deposit **ICP** into journaled Sale accounts. At close, the tranche is allocated **pro-rata by weighted ICP**. Close always settles whatever was raised; there are **no on-chain refunds**.

**Soft floor:** ~**500 ICP** for the opening epoch is an **ops / go-to-market target only**. It is not a fail gate and does not trigger refunds.

**Loyalty (locked):** +**1%** weight per prior epoch joined, **cap +5%** — always on. Loyalty redistributes within that epoch’s Sale tranche; it never mints new supply. Joining your 6th epoch = +5% weight on that buy. See §3.5.

### 3.3 Epoch calendar and weights (locked)

Gentle rising weights **5 : 6 : 7 : 8 : 9 : 10** (sum 45). Day lengths **8 / 6 / 5 / 4 / 4 / 3**. The same weight draws from Sale inventory and LP inventory each epoch (1:1 Sale↔LP).

| Epoch | Weight | Days | Calendar window | Sale GBT | LP-pair GBT |
|------:|-------:|-----:|-----------------|----------:|------------:|
| 1 | 5 | 8 | days 1–8 | 5,555,555 | 5,555,555 |
| 2 | 6 | 6 | days 9–14 | 6,666,666 | 6,666,666 |
| 3 | 7 | 5 | days 15–19 | 7,777,777 | 7,777,777 |
| 4 | 8 | 4 | days 20–23 | 8,888,888 | 8,888,888 |
| 5 | 9 | 4 | days 24–27 | 9,999,999 | 9,999,999 |
| 6 | 10 | 3 | days 28–30 | 11,111,115 | 11,111,115 |
| **Σ** | **45** | **30** | — | **50,000,000** | **50,000,000** |

(+5 on epoch 6 so each side totals exactly 50M.) Steep `1:2:3:4:5:6` and flat-equal schedules are retired.

**Ops note:** Motoko currently uses a single `epoch_duration_seconds` (opening-epoch prep set to **8 days** / `691_200` s). Per-epoch duration arrays are deferred — no half-wire. Product calendar remains the table above.

### 3.4 Per-epoch flow

1. Epoch controller marks the epoch **Open** and releases Sale + LP tranche ceilings.
2. Buyers send ICP to Sale (CMC-style subaccounts); deposits journal `Pending → Settled|Failed|Ambiguous`.
3. On close: compute loyalty-weighted shares; allocate GBT from the Sale tranche pro-rata. Allocations unlock daily over 60 days (§3.5).
4. Forward **100%** of raised ICP (after ledger/DEX fees) plus the matching LP-pair GBT tranche to **LP Manager**.
5. LP Manager adds liquidity; retains the LP position; never sends LP shares to EOAs.

**Launch default:** pair liquidity **at epoch close**. Mid-epoch drip is optional later (**TBD**).

### 3.5 Participant unlocks and loyalty (locked)

**In plain words.** "Unlock" means the GBT you bought becomes yours to move or sell. Nothing unlocks until the GBT–ICP trading pool exists on ICPSwap (an exchange on the Internet Computer). Then your GBT unlocks in 60 equal daily parts. Everyone unlocks at the same steady pace, so selling first wins nothing: no race to dump, and earlier buyers finish first.

**Pool first.** No participant tokens are released until the protocol creates and seeds the GBT–ICP pool on **ICPSwap at E1 close**.

**60-day linear daily unlock.** Every epoch’s allocation vests linearly, daily, over **60 days** starting at that epoch’s close. Daily amount = allocation ÷ 60. Example: 60,000 GBT → 1,000 GBT per day; fully unlocked on day 60. Every epoch gets the same default 60 days, so earlier buyers finish first. The point: no race to dump — the first seller is not rewarded.

Days counted from the start of the six-epoch sale (E1–E6):

| Epoch | Weight | Days | Closes (day) | Unlock starts | Fully unlocked |
|------:|-------:|-----:|-------------:|--------------:|---------------:|
| E1 | 5 | 8 | 8 | day 8 | day 68 |
| E2 | 6 | 6 | 14 | day 14 | day 74 |
| E3 | 7 | 5 | 19 | day 19 | day 79 |
| E4 | 8 | 4 | 23 | day 23 | day 83 |
| E5 | 9 | 4 | 27 | day 27 | day 87 |
| E6 | 10 | 3 | 30 | day 30 | day 90 |

**Step-up rule: buy more, keep your early unlock (current plan, open to change).** Your first epoch sets your end day: that epoch’s close + 60 (E1 → day 68, E2 → 74, E3 → 79, E4 → 83, E5 → 87). If a later buy puts in strictly more ICP than you put in during the most recent earlier epoch you bought in, that later buy finishes on the same end day. It unlocks daily from its own close to that end day, with no lump for days already passed: daily amount = allocation ÷ (end day − that epoch’s close). Equal or less ICP gets the normal 60 days from its own close. The end day always stays tied to your first epoch, even after a buy that did not step up. Loyalty and the pool-first gate do not change. This rule is the current plan and can still change. Since the Sale canister’s mainnet upgrade on 2026-10-09, the Sale enforces it on-chain, together with the pool-first gate and the 60-day daily unlock.

*In plain words:* your first buy sets your finish day. Come back later with **more** ICP than your last buy and the new tokens finish on that same day, unlocking a bit faster each day. Same or less ICP and they get the normal 60 days. The Sale program enforces this, not a person. *Why a holder should care:* a bigger return buy is rewarded with an earlier finish, never with a lump of tokens up front.

Example: 10 ICP in E1, then 15 ICP in E4 (closes day 23). 15 is more than 10, so the E4 tokens unlock daily from day 23 to day 68 (45 days). With 8 ICP in E4 instead, they unlock from day 23 to day 83 (the normal 60).

| Buy | Unlocks | Length |
|-----|---------|-------:|
| E1 · 10 ICP (first) | day 8 → 68 | 60 days |
| E4 · 15 ICP (step-up) | day 23 → 68 | 45 days |
| E4 · 8 ICP (no step-up) | day 23 → 83 | 60 days |

**Loyalty bonus (locked 2026-09-13).** +1% weight per prior epoch joined, capped at +5%. It redistributes within that epoch’s Sale tranche and never mints new supply. Bonus tokens unlock on the same 60-day daily schedule.

| Prior epochs joined | 0 | 1 | 2 | 3 | 4 | 5 |
|---------------------|---|---|---|---|---|---|
| Weight bonus | +0% | +1% | +2% | +3% | +4% | +5% |

### 3.6 Protocol-owned permanent LP

**In plain words: the LP manager.** "Liquidity" is the pile of GBT and ICP in a trading pool that lets people buy and sell. The LP manager is the program that owns GBT's share of that pool. When an epoch closes, all the ICP raised plus a matching amount of GBT go to the LP manager, which puts both into the pool and keeps the position. It can never send it to a person. *Why a holder should care:* buyers' money stays in the market as depth to trade against; nobody can pull it out and leave.

| Rule | Locked |
|------|--------|
| Raised ICP destination | **100% → protocol LP** (no advertising skim) |
| Launch venue | **ICPSwap** ICP↔GBT |
| Later venues | **Multi-DEX** when adapter + migrate-pool are production-ready |
| LP shares to EOAs | **Forbidden** |
| Farm / emissions / bribes | **Forbidden** |
| Fee claim | ICP fees only to **Agent Treasury**; GBT fee share **burned** in slow batches (at most once every 7 days; LP position never burned — current plan) |
| Pool migrate | Controller/Orbit + timelock; never “withdraw to team” |

KongSwap is dead (shut down 2026-04). Sonic remains a fallback AMM only if ICPSwap permanent-LP / fee-claim APIs block the token launch. Exact ICPSwap live ticks and pool config remain **Ken-gated / TBD** until supplied — adapters may stay StubLocal until then.

### 3.7 Agent Treasury

**In plain words: who pays the bills (current plan, open to change).**

- Every trade in the pool pays a small fee, in two parts: some ICP and some GBT.
- **The ICP part goes to the Treasury.** The Treasury is a program that holds the protocol's working money. It can pay only addresses on an approved list, only up to a set limit per period, and only 24 hours after a payment is proposed, so there is time to catch a mistake. Every payment is publicly logged.
- **What it pays for:** mainly *cycles*, the fuel Internet Computer programs burn to keep running. The Treasury is built to buy cycles with ICP and refill each program by itself; that refill is built but switched off on mainnet for now. Other bills (X Premium+, the Grok bot, the website) can be paid by anyone who wants to help.
- **The GBT part is burned.** The LP manager destroys the GBT it earns from fees, in small batches at most once a week, and records each batch. Total supply goes down. Only fee GBT is burned; the pool itself is never burned or sold.
- **A backup sale, switched off.** If the Treasury ever runs short of ICP, a backup can be turned on that sells a small, capped slice of fee GBT for ICP, only right after a big buy, at most once a week.
- *Why a holder should care:* fees pay running costs in the open instead of anyone's pocket, and the GBT side of fees shrinks supply instead of being sold into the market.

**Details.** Claimed LP fees (and any later managed yield) enter **Agent Treasury**:

- Allowlist + period/epoch **caps**
- Default spend **timelock 24h**
- **Public spend log** (timestamp, payee, label, amount, memo, tx reference)
- Allowlist may start **empty**

**Sale fee split (E1–E6):** **100%** → Agent Treasury; buyback/burn **0%** until a later approved policy.

**GBT side of LP fees (**current plan (Ken, 2026-10-09 23:48 ET) — open to change**):** pool fees arrive in both ICP and GBT. The ICP goes to Treasury directly. The GBT is **burned**: LP Manager sends the fee GBT it has collected to the GBT ledger's **minting account**, which on the DFINITY ICRC ledger is a burn — the tokens are destroyed and **total supply goes down**. It burns in **slow batches, at most once every 7 days**, keeps a reserve (default **0**), skips batches under **100 GBT**, and journals every batch; a retry after an unclear result reuses the same transaction details so the ledger cannot burn twice. All of these numbers are owner-settable. **Only fees are burned: the protocol LP position itself is never burned, blackholed or sold.** **Fallback, off by default:** the earlier patience sell stays in the code — GBT fees sold for ICP only right after a large GBT buy, once at least **100,000 GBT** of fees are waiting and the Treasury is under **10 ICP**, at most once every **7 days** and **4 times in 30 days**, in capped slices with a slippage guard. The owner can switch it on if the Treasury ever runs low on ICP; while it is on, the burn leaves the sell's 100,000 GBT minimum in place.

Intended pays: canister **cycles**, tool/API credits for protocol agents, documented ops budgets. Non-goals: discretionary team salary, opaque withdrawals, funding unrelated tokens.

**Ops rails (policy, not a bypass):** ICP-native cycles and ICRC-1 payments settle on-chain through Treasury. Off-chain SaaS (X credits, Cloudflare, Cursor, etc.) may use an allowlisted **ops-float bridge** (cap + timelock + public log) — see `OPS-PAY-RAILS.md`. That bridge is not permission to mint, open the token launch, or move sale funds.

### 3.8 Control: trustless, 100% protocol

**Trustless by design: 100% protocol (Ken, 2026-10-12; current plan, changeable).**
GBT is meant to be a trustless system. No community vote. No SNS or DAO. No one in charge. Fixed rules in public code decide everything.

- **Public code.** Anyone can read what the programs do.
- **Fixed rules.** Sale, unlocks, liquidity, fee burn and Treasury spending follow rules written in the code. Nobody votes on them, and nobody gets to change them on a whim.
- **On-chain receipts.** Every mint, burn, fee and spend leaves a public record. Live numbers: [gbt.fyi/receipts](https://gbt.fyi/receipts).
- **Locked canisters, the end state.** Once the programs are fully tested, their controllers are removed (blackholed). After that, nobody can upgrade or change them, not Ken, not the bot, not anyone.

**Honest about today.** Until that lock, the Orbit vault (Orbit Station `7t72u-hqaaa-aaaab-qhjsa-cai`, plus Ken's offline backup key in case Orbit breaks) is the one remaining trust point. It exists only as a temporary safety net for bug fixes. Every change through it is a written request that must be approved, and it leaves a trail. **Nothing has been removed yet.** Ken's lockout-safety rule holds: no controller is removed until the code is fully tested and the lock is a deliberate, separate step.

*Why a holder should care:* after the lock, the rules you bought into cannot be changed by anyone. Until then, the only thing you are trusting is the Orbit vault, and every use of it is public.

| Phase | Control |
|-------|---------|
| **Now (until fully tested)** | **Orbit Station** + Ken's offline backup key, as a temporary safety net for bug fixes only. The one remaining trust point. |
| **End state** | **Locked canisters:** controllers removed (blackholed), no upgrades. Fixed rules run on their own. |
| **Not planned** | Community vote, SNS, DAO handover. |

**In plain words: who can change the programs.** Each program (a *canister*) has controllers, the accounts allowed to update or stop it. The main one is an **Orbit Station**: a shared wallet on the Internet Computer where every change is a written request that must be approved before it runs. Ken approves; the bot can write requests but cannot approve code changes or money moves. The only other controller is a **backup key Ken keeps offline**, for use if Orbit itself breaks. The bot's server key was removed as a controller on 2026-10-09. It can still change some settings inside four programs (Sale, LP manager, Epoch controller, Treasury), such as pausing them or editing the Treasury's approved list, but not their code; moving those settings under the Station too is planned, not done. *Why a holder should care:* no single key on a server can rewrite the programs that hold the money, and every change leaves a written trail. Live numbers: [gbt.fyi/receipts](https://gbt.fyi/receipts).

**Orbit Station:** `7t72u-hqaaa-aaaab-qhjsa-cai` (name `GrokBotToken`). Since 2026-10-09 the mainnet protocol canisters are controlled by the **Station + an offline backup key held by Ken** (the ops hot key was removed as a controller with Ken's go). App-level owners, mint authority, and open-epoch remain Ken-gated gates in `GO-LIVE-BLOCKERS.md`.

Certified pause, caller guards around fund awaits, and journaled transfers are part of the launch hard rules — not marketing footnotes.

### 3.9 Community board

**gbt.fyi** is the unified Sale → forever-ops board (Credits / Protocol balances / Epoch sale). Cloudflare Pages hosts the interim public surface; the ICP asset canister is also live. Custom-domain attach to the ICP frontend and II alternative origins remain parallel Ken work. The board does not invent mainnet fund moves or Orbit control from the UI.

---

## 4. Tokenomics (summary)

| Item | Value |
|------|--------|
| Name / ticker | GrokBotToken / **GBT** |
| Supply | **100,000,000** fixed |
| Insider mint | **0** |
| Sale / LP split | **50M / 50M** |
| Epochs | **6** over **30** days |
| Weights | **5:6:7:8:9:10** |
| Day lengths | **8/6/5/4/4/3** |
| Sale mechanism | **Pro-rata** by weighted ICP |
| Loyalty | +1% weight / prior epoch, **cap 5%** (always on) |
| Participant unlock | Nothing before E1 pool seed; then **60-day linear daily** from each epoch’s close (fully unlocked days 68–90) |
| Step-up (current plan) | Later buy with **more ICP** than your previous buy finishes on your first epoch’s end day; open to change |
| Sale ICP | **100% → protocol LP** |
| Soft floor | **500 ICP** opening-epoch ops target; no refunds |
| Sale fees (E1–E6) | **100%** of ICP fees → Treasury / **0%** buyback; GBT fee share **burned** in slow batches (≤ 1 / 7 days); fallback sell for ICP off by default (current plan) |
| LP | Protocol-owned, permanent; launch **ICPSwap** → multi-DEX later |
| Control | Trustless, 100% protocol: Orbit as a temporary bug-fix safety net now; **locked canisters** (no controllers, no upgrades) once fully tested; no vote, no SNS/DAO |

**Explicit non-goals:** pre-mine outside the two protocol wallets; continuous mint; marketing-wallet dumps outside epoch Sale; mercenary farms; transferring LP to EOAs.

**Open / TBD (only where truly TBD):** rounding-dust policy (remain in Sale vs roll); mid-epoch LP drip vs close-only; initial Treasury allowlist principals; ICPSwap live pool/ticks; multi-DEX cutover timing after the token launch.

---

## 5. Security and Orbit

Security posture for the token launch:

- **Dual controllers** on sale, lp_manager, epoch_controller, agent_treasury, gbt_ledger, and frontend: Orbit Station `7t72u-…` + Ken's offline backup key (no ops hot key).
- **Journaled** money paths; never mix Sale / LP / Agent / UserDeposit buckets without an internal transfer record.
- **Hard pause** certified; fund awaits under caller guards.
- **ICRC-2** allowances sized for amount+fee; approve CAS; spender = SwapPool; vault cannot approve for users.
- **Threat drills and checklists** live in-repo (`ICP-THREAT-MODEL-CHECKLIST.md`, drill results). Local Phase 1 forever-loop (Sale→LP→fees→Treasury→cycles→heartbeat→epoch timers→typed ICPSwap stub) is complete; mainnet live LP and open sale are not.

Agents must not mint, open the token launch (Epoch 1 unveil), move protocol ICP, or change controllers without **explicit Ken confirmation**. Token launch / open sale is separately **held for adequate community support**.

---

## 6. Roadmap

High-level path (status compressed from `ROADMAP-STATUS.md` / go-live blockers as of 2026-09-28):

| Stage | Intent | Status (approx.) |
|-------|--------|------------------|
| Phase 1 local forever-loop | Sale settle → LP → fees → Treasury → cycles → heartbeat → timers | **Done** (local) |
| Mainnet shells + wasm | Six canisters + frontend; dual controllers | **Done** |
| Bootstrap + peer wire | App owners + `set_*` graph; opening-epoch duration prep 8d | **Done** (prep) |
| Genesis mint + lock | 100M → 50/50 Sale/LP; mint locked | **Blocked on Ken** — not minted |
| Pause / ICPSwap live / fund deposits | Production LP config and capital | **Blocked on Ken** |
| **Open token launch / Epoch 1 unveil** | Public six-epoch sale start | **Held — community support** |
| Multi-DEX LP | Arb fee flywheel after launch ICPSwap live | Canon locked; build later |
| Canister lock | Remove controllers (blackhole) once fully tested; no upgrades after | **Planned** — nothing removed yet |

This white paper may describe intended mechanics while the token launch remains closed. It does **not** authorize mint or open.

---

## 7. Disclaimer

This document is a **technical and product description** of GrokBot Token as specified in project canon. It is **not** an offer to sell securities, an investment prospectus, financial advice, or a guarantee of returns. Cryptocurrency and ICP-based protocols involve substantial risk, including total loss of value, smart-contract and canister risk, DEX and bridge risk, regulatory change, and operational failure.

Participation, if and when a sale opens, is voluntary and subject to on-chain rules, jurisdictional law, and wallet/custody competence. **No sale is open as of this draft.** Soft floors and epoch schedules are protocol/ops parameters, not promises of price or liquidity outcomes.

GrokBot Token / GrokBotToken / GBT is **not affiliated with xAI**. Trademarks and third-party names (ICPSwap, Orbit, Cloudflare, etc.) belong to their owners.

Canon may be updated by Ken and the protocol agent; where this paper and later-locked docs diverge, **later locked canon controls**. Items marked **TBD** are unresolved by design — do not invent numbers to fill them.

---

## Appendix A — Mainnet canister map (reference)

| Canister | Mainnet ID |
|----------|------------|
| sale | `xxae7-oiaaa-aaaap-qu2rq-cai` |
| lp_manager | `xchvs-paaaa-aaaap-qu2sa-cai` |
| epoch_controller | `xfgtg-cyaaa-aaaap-qu2sq-cai` |
| agent_treasury | `xmfy2-uqaaa-aaaap-qu2ta-cai` |
| gbt_ledger | `xle6o-ziaaa-aaaap-qu2tq-cai` |
| frontend | `wgk2a-waaaa-aaaap-qu2ua-cai` |
| Orbit Station | `7t72u-hqaaa-aaaab-qhjsa-cai` |
| ICP ledger (system) | `ryjl3-tyaaa-aaaaa-aaaba-cai` |

Board: https://gbt.fyi · ICP frontend: `https://wgk2a-waaaa-aaaap-qu2ua-cai.icp0.io/`

## Appendix B — Doc map

| Doc | Role |
|-----|------|
| `PROTOCOL-CANON.md` | Locked product decisions |
| `EPOCH-SIZES.md` | Weights + day calendar |
| `TOKENOMICS.md` | Supply narrative (defer to EPOCH-SIZES on weights) |
| `TREASURY-AND-LP.md` | Permanent LP + Treasury rules |
| `MINT-DISTRIBUTION-LP-PLAN.md` | Mint → distribute → LP plan |
| `OPS-PAY-RAILS.md` | Fee path + ops-float bridge |
| `ORBIT-STATION.md` | Station ID + dual-control |
| `GO-LIVE-BLOCKERS.md` | Mint / open-launch gates |
| `ROADMAP-STATUS.md` | Build status snapshot |