# 0002 — The token is conditional, not assumed

**Status:** Accepted
**Relates to:** [0001](0001-anchor-substrate.md), business-model.md,
roadmap.md

## Decision

No component of the protocol may assume a token exists.

The whitepaper's token functions — metering publication, securing verification, collateralising
settlement, weighting governance — are **conditional on permissionless staking**, and permissionless
staking is itself conditional on the reversal conditions in [0001](0001-anchor-substrate.md). The
roadmap already treats *launching* a token as gated on legal structuring. This record extends that
to the design: the token is not deferred-but-planned, it is optional.

Nothing here is legal advice, and the securities question is not settled by this record. It is one
reason among several and not the load-bearing one.

## What prompted this

The question was asked directly: should there be a token for ownership?

A token representing ownership is a security under the plain reading in most jurisdictions, which
roadmap.md already flags. But that framing invites the wrong follow-up — how to
structure it — when the prior question has not been answered: what would the token be *for*?

## The reasoning

Every function the whitepaper assigns the token is a coordination mechanism for **many mutually
untrusting participants with no legal relationship to each other**. That is a real problem and the
token is a reasonable answer to it.

It is not the problem this project currently has. There are no publishers, no network, and no
participants to coordinate. Under those conditions a token adds regulatory surface ahead of a
product, and consumes attention that belongs on finding a first counterparty.

The anchoring measurement sharpens this. The infrastructure a token would meter access to costs
**$6,200 a year at the worst fee observed**, and under [0001](0001-anchor-substrate.md) the
default substrate is cheaper still. A token economy is not needed to fund six thousand dollars, and
a design that implied otherwise would be reasoning backwards from a chosen conclusion.

There is also a category error worth naming, because it is easy to make and hard to see afterwards.
A token is a **financing and incentive mechanism**. It can fund the build and align publishers. It
does not answer who pays for what — and a revenue line that resolves to token appreciation is not a
revenue line. business-model.md keeps these separate for the same reason.

## What was rejected

**Designing the protocol around a token now.** Rejected. Every function it would serve has an
adequate non-token form at the scale this project operates at: publication is metered by contract,
verification is secured by the log and its witnesses, settlement is collateralised by bond or
escrow, and there is nothing yet to govern.

**Ruling a token out permanently.** Also rejected, and this is not fence-sitting. The conditions
under which it becomes the right answer are real and identifiable, and a design that foreclosed it
would be as premature as one that assumed it.

## What would reverse this

Both must hold, not either:

1. **Permissionless staking is required** — publishers must bond value without a legal relationship
   to any operator. This is condition 2 of [0001](0001-anchor-substrate.md); the token question
   and the chain question resolve together, because the token is what makes permissionless staking
   work and the chain is what makes it enforceable.
2. **Legal structuring is resolved**, per the roadmap's existing gate.

A third condition is worth watching without being decisive: enough independent publishers that the
per-publisher anchoring cost identified in phase2-findings.md forces pooled
roots. Pooling needs an incentive to assemble the pool, and that is the first place a token would
earn its keep on engineering grounds rather than financial ones.

## Consequences for the work

- `stake_ref` on `Commitment` stays an opaque string. It resolves against whatever the anchoring
  substrate provides — a bond reference, an escrow identifier, or a chain address — and the record
  format does not know which.
- The Phase 2 staking and slashing work should be specified against **mechanically decidable
  conditions** rather than against a token contract. `challenge.py` already distinguishes six
  verdicts of which exactly one exposes stake; that taxonomy is what a bond, an escrow agent, or a
  contract each attach to, and it is substrate-independent.
- The whitepaper is not edited. It states an intent, this records a sequencing decision about it,
  and the two are compatible.