# TOLLIE · Project Brief

> **Every fee knows the way.**  
> A programmable treasury router for internet-native assets.  
> Working brief · v0.2 / August 2026

![Tollie mascot](./tollie-brand/tollie-mascot.png)

## One-line pitch

Tollie lets a token, creator, or community publish an onchain rule for where trading-fee revenue goes, including allocations into supported stock tokens, execute that rule through bounded adapters, and prove every allocation with a public receipt.

## The idea

Creator-fee systems are good at producing revenue but weak at turning that revenue into predictable behavior. Most communities still depend on a wallet operator, a social promise, and screenshots after the fact.

Tollie sits between **fees arriving** and **capital being put to work**. A team creates a **Tollie Route**: a versioned policy describing destinations, weights, thresholds, limits, and change delays. Once its execution condition is met, the router sends funds through approved adapters and emits a receipt for every action.

Tollie is not a launchpad, NFT product, fund, trading terminal, or generic treasury dashboard.

## Why now

- Launch platforms increasingly expose creator or protocol fee streams.
- Internet-native assets need something useful to do with recurring revenue.
- Robinhood Chain makes tokenized stock and ETF exposure a native part of the product narrative.
- Communities increasingly expect execution to be visible and verifiable.
- A narrow router is easier to explain and audit than an open-ended treasury agent.

## Product primitive: Tollie Route

A Tollie Route contains:

- an approved revenue source and input asset;
- up to four active destination actions in the MVP;
- allocation weights totaling 100%;
- a minimum execution threshold or cadence;
- per-action slippage and size limits;
- a timelock for policy changes;
- an emergency pause authority that cannot redirect funds;
- an immutable policy version and activation timestamp.

Example route:

| Destination | Weight | Action |
|---|---:|---|
| Buyback | 35% | Acquire the community token |
| Stock tokens | 25% | Acquire supported tokenized stocks or ETFs |
| Stable reserve | 20% | Transfer to approved reserve vault |
| Builders | 20% | Pay an approved wallet splitter |

## Core user flow

### 1. Create

Connect a supported fee receiver, select approved route actions, assign weights and limits, choose governance controls, then deploy the route.

### 2. Observe

The public route page shows current policy, pending balance, cumulative revenue, realized allocations, failed actions, next eligible execution, and policy-change history.

### 3. Prove

Every execution emits a compact shareable receipt linked to the policy version and underlying transactions.

Example:

> `$TOKEN routed another $2,400 with Tollie: $840 buyback · $600 stock tokens · $480 reserve · $480 builders.`

## MVP

The first useful version should remain deliberately narrow:

- one creator-fee receiver integration;
- four destination types: buyback, supported stock tokens, stable reserve, wallet splitter;
- maximum four active routes;
- threshold-based execution;
- one timelocked policy-update path;
- guardian pause;
- public route facts page;
- complete deposit, execution, failure, and realized-allocation history.

## Reference architecture

```text
Fee Receiver
     │
     ▼
Tollie Vault ─────────► Route Registry
     │                    │ weights
     │ threshold met      │ timelock
     ▼                    │ limits
Execution Router ◄────────┘
     │
     ├────► Buyback adapter
     ├────► Stock-token adapter
     ├────► Reserve adapter
     └────► Splitter adapter
              │
              ▼
       Events + public indexer
```

Proposed contracts:

- `TollieFactory`: deterministic route-vault deployment.
- `TollieVault`: receives revenue and releases it only through valid routes.
- `RouteRegistry`: active/pending policies, timelocks, allowlists, and bounds.
- `ExecutionRouter`: route math, adapter calls, and normalized receipts.
- Adapters: isolated integrations with narrow permissions.

## Stock-token routes

Stock tokens are a first-class Tollie destination, not a generic “market assets” bucket. A route may allocate a fixed percentage of fee revenue into supported tokenized stocks or ETFs on Robinhood Chain, subject to the instrument registry and local availability.

Illustrative templates:

| Route | Allocation |
|---|---|
| **Compute Toll** | 50% tokenized NVDA · 30% buyback · 20% stable reserve |
| **Index Toll** | 50% tokenized SPY · 25% buyback · 25% stable reserve |
| **Meme-to-Bluechip** | 40% tokenized TSLA · 40% buyback · 20% builders |
| **Basket Toll** | 20% NVDA · 20% TSLA · 20% SPY · 20% buyback · 20% reserve |

Names and allocations above are examples only; production availability must come from an approved onchain instrument registry. A stock-token route should expose issuer, underlying reference, trading or transfer constraints, liquidity, price source, custody structure, and jurisdictional restrictions before activation.

## Safety posture

- Timelocked destination and weight changes.
- No generic arbitrary-call authority.
- Explicit size, cadence, asset, and slippage bounds.
- Adapter-level isolation and allowlists.
- Guardian may pause but never redirect.
- Public simulation before policy activation.
- Conservative caps for early deployments.
- Production launch only after testing, review, and audit.

## Business model

Candidate model: **0.25%–0.50% of successfully routed funds**, charged only after valid execution and disclosed on every route page.

Additional possibilities:

- premium analytics and alerts;
- curated route templates;
- enterprise deployment and monitoring;
- keeper coordination where economically required.

## Token posture

Tollie should work without a protocol token. A future `$TOLLIE` token is optional and must not be required for routing.

Potential later utilities include fee discounts, keeper bonding, route-template attribution, adapter governance, and transparent protocol-revenue buybacks. All of them require separate economic, governance, and legal design. This brief makes no promise of a token, distribution, return, or price.

## Positioning

| Category | Tollie position |
|---|---|
| Launchpad | Integrates with fee sources; does not launch assets |
| Treasury dashboard | Executes bounded policy; does not only visualize balances |
| Fund or vault strategy | Routes community revenue; does not promise investment management |
| Autonomous agent | Deterministic constraints first; no open-ended discretion |
| Social product | Receipts are distribution, while contracts remain the proof |

## Brand system

- **Name:** Tollie
- **Working line:** Every fee knows the way.
- **Mascot:** friendly toll-worker otter carrying a four-way route sign.
- **Logo:** otter head framed by branching cobalt routes.
- **Palette:** cobalt `#164EB8`, warm paper `#F1E5C9`, carbon `#11110F`.
- **Voice:** clear, calm, slightly playful; infrastructure without corporate stiffness.
- **Visual language:** vintage printed ephemera, editorial paper, imperfect ink, diagrams, stamps, and receipts.

## Launch narrative

1. **Tease the character:** “Every fee knows the way.”
2. **Show the problem:** fee revenue arrives; nobody can see the standing rule.
3. **Reveal the primitive:** one source, four bounded destinations, one public receipt.
4. **Ship the simulator:** let users build a hypothetical route without custody.
5. **Recruit design partners:** communities with visible recurring fee streams.
6. **Guarded mainnet:** conservative caps, limited adapters, public monitoring.

## Success metrics

Early success is not TVL alone. Track:

- time for a new user to understand a route;
- percentage of executions matching policy without manual recovery;
- routed volume and number of active routes;
- policy changes that complete through the timelock correctly;
- failed action rate and mean time to explanation;
- receipt views, shares, and click-through to proof;
- number of revenue-source integrations and approved adapters.

## Open decisions

- Atomic execution by default or explicit partial-execution policies?
- Which stock tokens, price checks, and liquidity thresholds belong in the first registry?
- Keeper reward design for small balances?
- Proof of fee-receiver control without forced migration?
- Which facts should be immutable versus timelocked?
- Jurisdiction and disclosure handling for tokenized instruments?

## Immediate build order

1. Freeze terminology and product scope.
2. Build route simulator and public facts-page prototype.
3. Specify events, policy schema, stock-token registry, and failure semantics.
4. Select one fee-source integration and four adapter targets, including one stock-token venue.
5. Threat-model the vault and router.
6. Recruit three design partners before custody is introduced.

## Status

Concept / discussion draft. Not deployed, not audited, and not an offer or financial advice.

## Repository

| Path | Contents |
|---|---|
| `apps/paper/` | The deployable concept-paper site. Vercel publishes this directory directly, with no build command. |
| `docs/BUILD_PLAN.md` | Launch order, URL contract, stack, hosting, milestones, resolved decisions. |
| `docs/MECHANISM_SPEC.md` | The routing mechanism: policy schema, split math, policy hash, prechecks, failure semantics, event surface. |
| `scripts/sync-paper.sh` | Regenerates the deploy copies in `apps/paper` from the sources at this root. |
| `tollie-brand/` | Logo, mascot, social masters, and the prompts that produced them. |

`TOLLIE_WHITEPAPER.md`, `TOLLIE_WHITEPAPER.pdf`, and this file are the sources of
truth; everything under `apps/paper/papers/` is a generated copy.