11 / 19PROPOSEDA design; nothing here is deployed
Economic proposal
ProposedPROPOSED. This chapter describes a design. Nothing in it is deployed, approved or running. Charging is off, TAON is not deployed, no TAO reserve exists and no audit has been done.
Product first, token later. Option 1: a paid capability router with a receipt per request, and no token. Option 3: a contributor programme, only after Option 1 shows real surplus.
The 2026-11-05 protocol pass (owner brief 20466) adds the proposed mechanism in plain language: chapter 19, Mechanism and sources, and the pages Token, Demand and Reserve. All of it is PROPOSED; this chapter’s facts stand unchanged.
0 sections on this page fold on a phone. Each opens on its own; this opens them all.
The recommended path
PROPOSEDThree mechanisms were designed and scored against fifteen criteria. The scores are one analyst’s judgements with cited evidence, out of 150. They favour doing less, and the weak point of the winner is stated below.
| Mechanism (PROPOSED) | Score | Role |
|---|---|---|
| O1 Ledger-first routing | 102 of 150 | Now |
| O3 Contributor credits | 80 of 150 | Later, after surplus |
| O2 Reserve-aligned TAON | 47 of 150 | Gated |
- The routing product is real and works without a token.
- No token model was found that improves the routing job for the person paying.
- Modelled break-even is roughly $400 of pack sales a month at the proposed capability prices to cover running costs, and roughly $7,200 to also pay one developer $6,000 a month (PROPOSED prices, modelled, not measured). Below it eligible surplus is $0.
- Charging is off, revenue is $0 and none of the eight token gates (G1 to G8) has passed.
Option 2: a reserve-aligned TAON token and TAON/TAO pool, documented and gated behind conditions nothing today meets. The weak point of Option 1 is that willingness to pay a router markup is unmeasured.
The proposed loop
PROPOSEDProposed · Not operating
- 01 User requests work operating
- 02 Route selected operating
- 03 User pays a price proposed
- 04 Provider cost paid operating
- 05 Costs deducted proposed
- 06 Eligible surplus proposed
- 07 Product share proposed
- 08 TAO share proposed
- 09 Funded TAO proposed
- 10 Better coverage proposed
This is a separate, simpler picture from the Route Decision on the homepage. The Route Decision shows how one request is routed today. This loop shows how paid usage could be settled into a proposed TAO reserve, and none of it runs. It stops there.
PROPOSED
- 01Paid usage
- 02Provider and operating costs settled
- 03Eligible surplus calculated
- 04Proposed TAO reserve
| Step (PROPOSED) | What would happen |
|---|---|
| Paid usage | A customer pays for a request that succeeded. Failed requests earn nothing. |
| Provider and operating costs settled | Refunds, processor fees, provider costs, operating costs and a tax reserve come off first. |
| Eligible surplus calculated | What is left, never below zero. |
| Proposed TAO reserve | A reserve earmark is proposed. Customers hold no claim on it. |
Future reserve use is undecided. Potential uses require a published policy, custody design and measurable connection to product operation. Nothing here says that holding TAO improves routing, creates demand, rewards holders or earns yield.
A token market is not a step in this loop, because trading a token creates no productive revenue. Customers hold refundable credit and their receipts, not a claim on the reserve.
eligible surplus = max(0, revenue − refunds − processor fees − provider costs − operating costs − tax reserve − earlier deficit)
- revenue
- from successful requests only; a failed request earns nothing
- floor
- never below zero, and a deficit carries forward
No split of eligible surplus is published. Shares are not decided and none will be shown until the owner approves them with supporting evidence. At today’s volume every share would be $0, so the team is funded outside the mechanism for the foreseeable future.
What the numbers say
PROPOSEDThe earlier universal price of $0.003 per answer is withdrawn. Prices are set per capability (see Pricing and accounts), and the figures below are modelled from them, not measured.
| Development budget | Pack sales a month | Packs of $20 |
|---|---|---|
| None | $403 | 20 packs |
| $1,000 a month | $1,540 | 77 packs |
| $3,000 a month | $3,812 | 191 packs |
| $6,000 a month | $7,221 | 361 packs |
Modelled, not measured. Sales today are $0 because charging is off. Break-even here means monthly credit-pack sales at which running costs and the stated development budget are covered. Below it, nothing is left over.
| Pack sales a month | Eligible surplus | TAO the reserve would buy |
|---|---|---|
| $50 | $0 | 0 |
| $500 | $0 | 0 |
| $2,000 | $291.76 | 0.651 |
| $5,000 | $2,192.64 | 4.892 |
| $20,000 | $11,697.08 | 26.096 |
Break-even in short: roughly $400 of pack sales a month at the proposed capability prices to cover running costs, and roughly $7,200 to also pay one developer $6,000 a month (PROPOSED prices, modelled, not measured). The measured provider cost of a text answer, $0.000126, is calculated from 20 answered requests, none of them reported by the provider. Below break-even the product acquires no TAO, so the loop is mostly symbolic at small volume. The calculator that produces these figures is tested so that revenue cannot come from request volume alone, failed requests earn nothing, refunds reduce revenue, provider costs come off first and TAO bought can never exceed the funded surplus.
The constitution (docs/TAONIC-CONSTITUTION.md, locked on 2026-09-25) proposes a different design in six places. The differences are listed, not applied: only the project owner can change the constitution.
ARCHIVED PROPOSAL · NOT ADOPTED · TOKEN NOT YET JUSTIFIED
| Item | Constitution (PROPOSED) | Concept (PROPOSED) | Decision |
|---|---|---|---|
| Market fee | 1.25% on eligible swaps | None under Option 1. If Option 2 reopens: 1.0% | D-R05 |
| Fee ceiling | 2% immutable | None under Option 1. If Option 2 reopens: 1.5% | D-R05 |
| Reserve asset | Bridged TAO on Robinhood Chain | Native TAO in a 3-of-5 multisig | D-R04 |
| Surplus split | 50 / 15 / 15 / 10 / 10 | 50 reserve / 35 product development / 15 security | D-R07 |
| Team funding | 15% of genesis TAON plus 15% of surplus | 35% of surplus, capped at 40%, no team token | D-R06 |
| Token | TAON, fixed supply of 1,000,000,000 | No token now | D-R01 |
What must come first
PROPOSEDEach stage needs its exit evidence before the next begins. None has a date.
| Stage | What | Gate |
|---|---|---|
| S0 Now | Routing live, charging off, documentation only | Owner review |
| S0a Fix | Close the product-side accounting and abuse defects | Tests and reconciliation |
| S1 Private paid beta | Charging on for a fixed set of customers; measure willingness to pay | Owner written go-ahead |
| S2 First surplus | One reconciled month with positive eligible surplus | Signers and custody drill |
| S3 First TAO purchase | A purchase at the published threshold, with a record | Owner yes for the first purchase |
| S5 Contributor pilot | Invited providers and integrators under written agreements | Written agreements |
| S6 Token question | Reopened only if the published conditions hold | Owner, counsel, independent audit |
- A right that improves routing for its user, not only a fee stream
- Three months of reconciled paid accounting, reviewed externally
- Counsel has reviewed it in writing
- The counter-asset identity and redemption are confirmed
- Measured TAO depth on Robinhood Chain
- An independent audit with a published report
- The owner’s written approval for that specific deployment
The details are in 13 TAON token proposal. No legal or tax conclusion is drawn anywhere in this proposal; the questions for qualified counsel are listed in the concept book.
Every state on this page matches Status. Where they ever differ, Status is right and this page is a defect.