What's Next
Routing Decision Market
Research on letting $ROUTOR holders predict the best model per task, why the first version fails, and a version that might work.
Documentation Index
Fetch the complete documentation index at: /llms.txt
Use this file to discover all available pages before exploring further.
Research on letting $ROUTOR holders predict the best model per task, why the first version fails, and a version that might work.
| Category | Reward share | Majority pick | Who gets paid |
|---|---|---|---|
| Marketing copy | 10% | Model A | Everyone who picked Model A |
| Code review | 15% | Model B | Everyone who picked Model B |
| Legal drafting | 5% | Model C | Everyone who picked Model C |
| Problem | Why it matters |
|---|---|
| The unit is wrong | ”Best model for marketing” is too coarse. The best model depends on the prompt, cost, latency, and context length, and changes every few weeks. A router needs prompt-level signal. |
| Voters have no information | Most voters won’t run the models first. The token pays for opinions. |
| Sybil and collusion attacks | Majority payouts attract bots and vote rings. Stopping them needs slashing, and slashing needs a ground truth to slash against. There isn’t one. |
| Circular token economy | Rewards depend on token value, which depends on data sales, which depend on data quality, which depends on the token. Nothing funds the first round. |
| Regulation | Paying out on prediction outcomes invites gambling and securities scrutiny. In India, crypto gains are taxed at 30% with 1% TDS. |
| No clear buyer | Companies already use public benchmarks, LMArena, and their own evals. Published data can’t be kept exclusive. |
| ”Trains itself forever” | Sparse, lagging crowd votes are a weak training signal compared with real usage. |
| Original | Revised | |
|---|---|---|
| What you predict | ”Best model for marketing" | "Which model will have the highest accepted-answer rate on Routor for this prompt type next period” |
| How it resolves | Majority vote | Routor’s measured outcomes: accepted, retried, rated down |
| Unit | Broad category | Prompt type, with cost included |
| What wins | Guessing the crowd | Being right about real performance |
| Funding | Token value | The existing reward pool, funded by Routor profit |
| Risk | Status |
|---|---|
| Regulation: paying out on predictions | Unsolved. Needs legal review before any build. |
| Does it beat outcomes alone? | Unknown. If Routor already measures outcomes, the predictions must add something the outcomes don’t. |
| Gaming the outcomes | A predictor could send fake traffic to inflate a model’s accept rate. Needs paid-usage-only scoring. |
| Privacy | Outcome data comes from user requests. Only aggregates could ever be exposed. |
| Approach | Ground truth | Brand bias | Token needed | Verdict |
|---|---|---|---|---|
| Majority-vote market | None | High | Yes | Dropped |
| Outcome-resolved market | Routor’s measured outcomes | Low | Yes, via the existing pool | Research, untested |
| Blind pairwise comparisons | Human judgment on real outputs | Low | No | Only for a niche LMArena doesn’t cover |
| Learn directly from outcomes | What users actually did | None | No | Planned. See the Roadmap |