> ## Documentation Index > Fetch the complete documentation index at: https://docs.routor.io/llms.txt > Use this file to discover all available pages before exploring further. # 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. **Status: research.** The original design is **dropped**: it rewards guessing the crowd, not finding the best model. A revised design is described under [A version that might work](#a-version-that-might-work). It is untested and not on the roadmap. *** ## The Original Idea Build a public graph of every category people use AI for. For each category, \$ROUTOR holders bid on which model is best. At the end of a round, rewards go to holders whose pick matched the majority. The resulting data is then sold, or used to train Routor. ### 1. The category graph Every task category is a node. Each node is a market where holders pick a model. ```mermaid theme={null} flowchart LR ROOT(["All AI tasks"]):::positive ROOT --> W["Writing"]:::step ROOT --> C["Coding"]:::step ROOT --> A["Analysis"]:::step ROOT --> B["Business"]:::step W --> W1["Marketing copy"]:::step W --> W2["Email summaries"]:::step C --> C1["Code review"]:::step C --> C2["Debugging"]:::step A --> A1["Data analysis"]:::step A --> A2["Research"]:::step B --> B1["Customer support"]:::step B --> B2["Legal drafting"]:::step classDef step fill:#0d0d0d,stroke:#9ca3af,color:#d1d5db classDef positive fill:#0d0d0d,stroke:#f3f4f6,color:#ffffff,stroke-width:2px ``` ### 2. A round, from open to payout ```mermaid theme={null} flowchart LR O(["Open\nround starts"]):::step --> V["Voting\nholders stake $ROUTOR\non a model"]:::step V --> C["Closed\nwindow ends"]:::step C --> R["Resolved\nmajority model wins"]:::warning R --> P(["Paid\nmajority pickers\nshare the reward"]):::step classDef step fill:#0d0d0d,stroke:#9ca3af,color:#d1d5db classDef warning fill:#0d0d0d,stroke:#6b7280,color:#9ca3af,stroke-dasharray:3 3 ``` ### 3. How rewards would be split Each category gets a share of the round's reward pool. Inside a category, holders who picked the winning model split that share. | 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 | ### 4. What the data would power ```mermaid theme={null} flowchart LR V["Votes per category"]:::step --> D[("Crowd decision data")]:::positive D --> S["Sell to companies"]:::step D --> T["Train a data-driven router"]:::step D --> E["Decision engine connected to Routor\nretrains every round"]:::step classDef step fill:#0d0d0d,stroke:#9ca3af,color:#d1d5db classDef positive fill:#0d0d0d,stroke:#f3f4f6,color:#ffffff,stroke-width:2px ``` *** ## Why the Original Version Fails ### Majority rewards pay for guessing the crowd This is the fatal flaw. If you are paid for matching the majority, your best move is to pick the model you think everyone else will pick, usually the biggest brand, without testing anything. The data measures popularity and brand bias. That signal is already free. ```mermaid theme={null} flowchart LR Q["Which model is best\nfor marketing copy?"]:::step --> I{"How do I\nget paid?"}:::step I -->|"match the majority"| B["Pick the most famous brand\nno testing needed"]:::negative B --> P["Payout"]:::step B --> X[("Data = popularity\nnot quality")]:::negative classDef step fill:#0d0d0d,stroke:#9ca3af,color:#d1d5db classDef negative fill:#0d0d0d,stroke:#374151,color:#6b7280,stroke-dasharray:3 3 ``` ### The other problems | 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. | ```mermaid theme={null} flowchart LR TV["Token value"]:::negative --> RW["Voter rewards"]:::negative RW --> DQ["Data quality"]:::negative DQ --> DS["Data sales"]:::negative DS --> TV classDef negative fill:#0d0d0d,stroke:#374151,color:#6b7280,stroke-dasharray:3 3 ``` *** ## A Version That Might Work The fatal flaw is resolution by majority. Routor has something a standalone market does not: **real outcomes for every routed request.** If predictions are resolved against those outcomes instead of against other voters, the market rewards being right, not being popular. ### What changes | | 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 | ```mermaid theme={null} flowchart LR P["Holders predict the best model\nper prompt type"]:::step --> W["Prediction window closes"]:::step W --> R["Routor routes real traffic\nas usual"]:::step R --> O[("Measured outcomes\naccepted · retried · rated down")]:::positive O --> S["Score each prediction\nagainst outcomes"]:::positive S --> PAY["Rewards for accurate predictions\nfrom the reward pool"]:::positive S --> RT["Accurate predictors' picks\nbecome a routing prior"]:::step classDef step fill:#0d0d0d,stroke:#9ca3af,color:#d1d5db classDef positive fill:#0d0d0d,stroke:#f3f4f6,color:#ffffff,stroke-width:2px ``` ### What it still doesn't solve | 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. | ### How to test it cheaply Before any token mechanics: show holders a weekly prediction board with no rewards, score their picks against real outcomes, and compare against the router's own choices. If unrewarded predictions don't beat the router, rewarded ones won't either. *** ## Verdict | 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](/roadmap) | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.