# TOLLIE

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

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

## Abstract

Tokens can generate meaningful trading-fee revenue, but the rule for what happens next is usually a multisig habit, a social promise, or no rule at all. Tollie turns that revenue policy into visible infrastructure.

A creator or community defines a **Tollie Route**: an onchain allocation policy that sends incoming fee revenue among approved destinations such as token buybacks, supported stock tokens, tokenized ETFs, liquidity, stable reserves, operations, and contributor wallets. Execution occurs only when transparent conditions are met. Every deposit, route, policy change, failure, and realized allocation is publicly inspectable.

Tollie is not a launchpad, fund, social-trading product, NFT protocol, or generic treasury dashboard. It is a narrow operating layer between **revenue arriving** and **capital being put to work**.

## 1. The problem

Creator-fee systems make recurring revenue possible. They do not answer five operational questions:

1. Who decides where the revenue goes?
2. Is the allocation rule public before execution?
3. Can anyone verify that realized allocations match the stated policy?
4. How are policy changes delayed, announced, and audited?
5. Can small communities automate treasury behavior without custom infrastructure?

Today the default is discretionary treasury management. The community reads an announcement, trusts an operator, and reconstructs activity from unrelated transactions. Even honest teams create uncertainty because intention, execution, and reporting live in different places.

## 2. The primitive: a Tollie Route

A **Tollie Route** is a versioned routing policy attached to a revenue source. It contains:

- the accepted input asset;
- up to four destination actions in the first release;
- allocation weights totaling 100%;
- a minimum execution threshold;
- a maximum slippage bound per market action;
- an execution cadence or keeper condition;
- a timelock for policy changes;
- emergency pause authority that cannot redirect funds;
- a public policy version and activation timestamp.

Example:

| Destination | Policy weight | Action |
|---|---:|---|
| Buyback | 35% | Acquire the community token |
| Stock tokens | 25% | Acquire supported tokenized stocks or ETFs |
| Stable reserve | 20% | Transfer to an approved reserve vault |
| Liquidity | 10% | Add to an approved pool |
| Contributors | 10% | Pay an approved wallet splitter |

The policy is legible before the next dollar arrives. The ledger shows what happened after it executes.

## 3. Product experience

### Create

1. Connect a supported fee receiver or revenue source.
2. Choose destination actions from an approved registry.
3. Assign percentages, limits, and an execution threshold.
4. Select governance, timelock, and emergency controls.
5. Deploy the Tollie Route and publish its permanent facts page.

### Observe

Every public route page should answer, without wallet forensics:

- How much revenue has entered?
- What is the current policy?
- When did this policy become active?
- How much has been allocated to each destination?
- What is waiting to be routed?
- Which actions failed, and why?
- When can the policy change next?

Example public receipt:

> **$TOKEN has routed $184,291 with Tollie**  
> $72,000 → supported stock tokens  
> $48,000 → buyback and burn  
> $31,000 → liquidity  
> $33,291 → contributors and operations

### Share

Each execution produces a compact, verifiable content event:

> `$TOKEN just routed another $2,400: $840 buyback · $600 stock tokens · $360 reserve · $600 builders.`

The message is distribution. The transaction is proof.

## 4. Reference architecture

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

### Contracts

**TollieFactory** deploys deterministic vault instances from an audited implementation.

**TollieVault** receives revenue, pins the active route hash, exposes pending balances, and releases funds only through approved adapters.

**RouteRegistry** stores active and pending policies, timelock timestamps, adapter allowlists, and safety bounds.

**ExecutionRouter** calculates route amounts, invokes adapters, and emits normalized execution receipts.

**Adapters** isolate integrations. A buyback, stock-token purchase, liquidity, reserve, or splitter action can be reviewed and limited independently.

**Keeper network** calls execution when public conditions are satisfied. The MVP may begin with a permissioned keeper plus permissionless fallback, then move toward bonded keepers.

**Indexer** converts events into public facts pages. The interface is a convenience layer; contracts remain the source of truth.

## 5. Execution lifecycle

1. Revenue arrives in the vault.
2. The vault records the deposit and pending balance.
3. A valid keeper observes that the configured threshold or cadence is met.
4. The router snapshots the active policy version.
5. Each route amount is calculated from the eligible balance.
6. Adapters execute with per-action minimum output and slippage limits.
7. The router emits a receipt for every successful, failed, or skipped action.
8. Residual dust remains pending for the next execution.

Atomic execution is preferred when all routes can safely succeed together. Partial execution may be supported only when the policy explicitly defines failure behavior. A failed market route must never silently redirect funds to another destination.

## 6. Stock-token routes and presets

Stock tokens are a first-class destination in Tollie. A route may allocate a fixed percentage of incoming fees into supported tokenized stocks or ETFs on Robinhood Chain, subject to the active instrument registry.

Before a stock-token route can activate, the interface and registry should expose:

- issuer and legal wrapper;
- referenced stock or ETF;
- supported jurisdictions and transfer restrictions;
- price source and freshness limits;
- minimum liquidity and maximum price-impact bounds;
- market-hours or venue-specific execution behavior;
- custody, redemption, and investor-right disclosures.

Illustrative examples include tokenized NVDA, SPY, and TSLA where supported. These symbols describe reference exposure only and do not imply availability, direct share ownership, or endorsement.

Presets are visible starting templates, never hidden management strategies.

| Preset | Allocation |
|---|---|
| **Compute Toll** | 60% tokenized NVDA* · 30% buyback · 10% stable reserve |
| **Index Toll** | 50% tokenized SPY* · 25% buyback · 25% stable reserve |
| **Meme-to-Bluechip** | 40% tokenized TSLA* · 40% buyback · 20% builders |
| **Diamond Hands** | 80% buyback/burn · 20% liquidity |
| **Safe Treasury** | 40% broad-market exposure · 30% tokenized gold · 30% stable reserve |
| **Builder Mode** | 50% contributors · 30% treasury · 20% buyback |
| **Community Mode** | Configurable splitter for contributors and community programs |

Templates should be forkable, versioned, and attributable. `*` Symbols are illustrative and require registry support. Templates do not constitute investment advice.

## 7. Safety model

Tollie moves treasury value and should be designed as conservative infrastructure.

- **Timelocked changes.** Allocation, adapters, and destinations cannot change instantly.
- **Explicit limits.** Per-action size, slippage, cadence, and supported assets are bounded.
- **Adapter isolation.** A new integration cannot inherit blanket vault authority.
- **Emergency pause.** A guardian can stop new executions but cannot redirect funds.
- **No arbitrary calls.** Vaults expose no generic external-call functionality.
- **Keeper neutrality.** A keeper chooses when to call a valid execution, not where funds go.
- **Public simulation.** Every pending policy can be simulated before activation.
- **Receipts over screenshots.** UI statements link to transactions and policy version.
- **Staged caps.** Early deployments use conservative deposit and route limits.
- **Independent audit.** Production launch follows contract review, testing, and a published audit process.

The protocol cannot remove market, oracle, smart-contract, liquidity, custody, or legal risk. It can make policy and execution constraints easier to inspect.

## 8. Business model

The protocol may charge **0.25%–0.50% of successfully routed funds**, configured transparently and collected only after execution. It does not charge a percentage of all token trading volume.

Possible additional revenue:

- premium analytics for teams;
- sponsored or curated route templates;
- enterprise deployment and monitoring;
- keeper coordination fees where economically necessary.

Any fee change should be timelocked and visible at both protocol and route level.

## 9. Token posture

Tollie must work without a protocol token. Routing should not depend on speculative demand.

If a `$TOLLIE` token is introduced later, possible utilities include routing-fee discounts, keeper bonding, route-template attribution, supported-asset governance, and transparent protocol-revenue buybacks. Those utilities require separate economic, legal, and governance design. This paper does not promise a token, distribution, price, or return.

## 10. MVP

The first useful release should be intentionally 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;
- live treasury route page;
- complete deposit, execution, failure, and realized-allocation history.

Success is not TVL alone. Success is whether a community can understand its treasury rule in one minute and verify that the last execution obeyed it.

## 11. Rollout

### Phase 0 · Simulation

Route builder, historical-fee simulator, public design partners, and no custody.

### Phase 1 · Guarded mainnet

Audited core contracts, conservative caps, limited adapters, permissioned keeper with permissionless fallback, and public monitoring.

### Phase 2 · Open execution

Bonded keepers, broader adapter registry, route templates, and community-owned policy controls.

### Phase 3 · Treasury network

Cross-community benchmarks, reusable splits, delegated policy modules, and integrations for additional revenue sources.

## 12. Open questions

- Should route execution be atomic by default, or can policies opt into partial completion?
- Which price and liquidity checks are adequate for tokenized-asset routes?
- Who can pause, and how quickly can governance unpause?
- How should keeper rewards avoid uneconomic micro-executions?
- Can a community prove control of a fee receiver without transferring it?
- Which policy facts should be immutable versus timelocked?
- What disclosures are required when a route includes regulated or jurisdiction-limited assets?

## 13. Legal and product notice

This document is an early product and protocol specification. Tollie is not deployed, audited, or offered as a financial product. Examples are illustrative and do not promise performance.

Tokenized stocks or ETFs may be structured as tokenized debt instruments rather than direct equity ownership and may be unavailable in the United States or other jurisdictions. Availability, transferability, redemption, market hours, custody, disclosures, and investor rights depend on the relevant issuer, venue, and law. A production interface must enforce supported-asset rules and display instrument-specific disclosures.

Routing revenue into an asset does not automatically give token holders ownership of the treasury or a claim on its value. Any such rights would require separate legal and protocol design.

## References

- [Pons documentation](https://docs.ponsfamily.com/v2)
- [Robinhood Chain documentation](https://docs.robinhood.com/chain/)
- [Robinhood Stock Tokens disclosure](https://robinhood.com/rhj/stocktokens/)

---

**Status:** Concept / discussion draft  
**Version:** 0.2  
**Working line:** *Every fee knows the way.*