Tokens learned how to generate revenue. They still have no shared operating system for deciding what that revenue becomes.
Tollie turns a treasury promise into an onchain routing policy. A creator or community defines destinations, including supported stock tokens, then sets percentages, limits, and a change delay. Revenue arrives; the policy executes; a public receipt shows the result.
It is not a launchpad, fund, NFT product, or generic portfolio manager. It is the narrow layer between fees arriving and capital being put to work.
Policy before capital.
Proof after execution.
Revenue is onchain.
The decision is not.
Intent
The allocation rule is often a social promise, not an enforceable policy.
Execution
Operators act manually across wallets, venues, and changing market conditions.
Proof
Communities reconstruct treasury behavior from fragmented transactions.
Tollie joins all three into one public lifecycle.
One fee in.
Four outcomes out.
RECEIVER
100%Weights must close.
≤ 4MVP destinations.
T+ΔTimelocked edits.
1:1Receipt per route.
Small core.
Explicit edges.
- 01Revenue lands in the vault.
- 02A keeper observes a valid trigger.
- 03The router snapshots policy version.
- 04Adapters execute bounded actions.
- 05Receipts become the public facts page.
Route a hypothetical
$10,000 fee.
TOLLIE RECEIPT / #0001
*Symbols are illustrative. A production stock route requires instrument-registry support, jurisdiction checks, price freshness, minimum liquidity, slippage bounds, adapter limits, and a timelock.
A router should be
boring under pressure.
Timelocked changes
Destinations, weights, and adapters cannot change instantly.
Bounded execution
Slippage, route size, cadence, and supported assets are explicit.
Adapter isolation
New integrations do not inherit generic authority over the vault.
Pause, not redirect
A guardian can stop execution but cannot send funds elsewhere.
Keeper neutrality
Keepers may trigger valid policy; they do not choose policy.
Receipts over claims
Every interface statement resolves to a policy version and transaction.
Tollie works without
a protocol token.
The vault, the policy, the timelock, and the receipt all function with no token in the system. That is a standing design constraint, not a phase to grow out of. A treasury rule that needs a token in order to execute carries a dependency the community never asked for.
A $TOLLIE token may be introduced later. If it is, the utilities below are the ones under consideration. Each requires separate economic, legal, and governance design before it can exist, and none of them is committed here.
Fee discounts
A reduced protocol fee on successfully routed funds.
Keeper bonding
Collateral that makes a keeper accountable for triggering valid executions.
Template attribution
Credit for authored route templates that other communities fork.
Asset governance
A say in which adapters and instruments enter the approved registry.
Revenue buybacks
Protocol revenue routed transparently through Tollie itself.
Not a promise
None of the above is offered, scheduled, or guaranteed by this document.
Ship the proof,
then widen the route.
SIMULATION
Route builder, historical-fee model, design partners. No custody.
GUARDED MAINNET
Four routes, conservative caps, one fee source, public monitoring.
OPEN EXECUTION
Bonded keepers, broader adapters, reusable route templates.
MVP CONTRACT
- One creator-fee receiver integration
- Buyback · supported stock tokens · stable reserve · wallet splitter
- Maximum four destinations
- Threshold execution + timelocked policy edits
- Live route page + complete receipt history
Tokenized instruments may be debt securities rather than direct equity, may be jurisdiction-restricted, and require instrument-specific disclosures. Routing revenue does not grant token holders ownership of treasury assets. This is a concept paper, not financial advice or an offer.
Every fee knows the way.