agents/rio/musings/contribution-attribution-and-voting-layer-foundations.md

@@ -0,0 +1,260 @@
+---
+type: musing
+status: seed
+created: 2026-03-11
+agent: rio
+purpose: "Research foundations for Teleo's contribution attribution, quality evaluation, voting layer, and information-as-prediction system. Cory's brief via Leo: think about mechanism design foundations, not implementation."
+toward: "Claims on incentive-compatible contributor attribution, quality scoring rules, voting mechanism selection, and information reward design. Feeds Rhea's implementation plan."
+---
+
+# Mechanism Design Foundations for Contribution Attribution and Voting
+
+## Why this musing exists
+
+Cory wants Teleo to become a global brain — not metaphorically, but mechanistically. Users contribute claims, challenges, enrichments, and research missions. We need to: (1) trace who contributed what, (2) evaluate quality over time, (3) enable weighted human voting, and (4) reward information providers whose inputs improve predictions. This musing develops the mechanism design foundations for all four. It's research, not a build spec.
+
+## 1. Contribution Attribution — The Identity and Tracing Problem
+
+### What exists today
+
+Agent attribution is solved: git trailers on a shared account give durable, platform-independent provenance. Source archives track `processed_by`, `processed_date`, `claims_extracted`. The chain from source → extraction → claim is walkable.
+
+What's missing: **human contributor attribution**. When a visitor challenges a claim, suggests a research direction, or provides novel evidence, there's no structured way to record "this person caused this knowledge to exist." All human contributions currently show as 'm3taversal' in the git log because there's one committer account.
+
+### The mechanism design problem
+
+Attribution is a **credit assignment problem** — the same class of problem that plagues academic citation, open-source contribution, and VC deal flow sourcing. The hard part isn't recording who did what (that's infrastructure). The hard part is **attributing marginal value** when contributions are interdependent.
+
+CLAIM CANDIDATE: Contribution attribution must track five distinct roles because each creates different marginal value: **sourcer** (pointed to the information), **extractor** (turned raw material into structured claims), **challenger** (identified weaknesses that improved existing claims), **synthesizer** (connected claims across domains to produce new insight), and **reviewer** (evaluated quality to maintain the knowledge bar). A sourcer who points to a paper that yields 5 high-impact claims creates different value than the extractor who does the analytical work.
+
+### Infrastructure needed
+
+1. **Contributor identity**: Pseudonymous, persistent, reputation-accumulating. Not wallet-based (too many barriers). Start simple: a username + cryptographic key pair. The key proves authorship; the username is what appears in attribution. This can later bridge to on-chain identity.
+
+2. **Role-tagged attribution in frontmatter**: Extend the source/claim schemas:
+   ```yaml
+   attribution:
+     sourcer: "contributor-handle"
+     extractor: "rio"
+     reviewer: "leo"
+     challenger: "contributor-handle-2"  # if the claim was improved by challenge
+   ```
+
+3. **Temporal ordering**: Who contributed first matters for credit assignment. The git log provides timestamps. But for inline conversation contributions (visitor says something insightful), the agent must record attribution at the moment of extraction, not after the fact.
+
+### Gaming vectors
+
+- **Attribution inflation**: Claiming credit for contributions you didn't make. Mitigation: the agent who extracts controls the attribution record. Visitors don't self-attribute.
+- **Contribution splitting**: Breaking one insight into 5 micro-contributions to accumulate more attribution records. Mitigation: quality evaluation (below) weights by value, not count.
+- **Ghost sourcing**: "I told the agent about X" when X was already in the pipeline. Mitigation: timestamp ordering + duplicate detection.
+
+## 2. Quality Evaluation — The Scoring Rule Problem
+
+### The core insight: this is a proper scoring rule design problem
+
+We want contributors to be honest about their confidence, thorough in their evidence, and genuinely novel in their contributions. This is exactly what proper scoring rules are designed for: mechanisms where truthful reporting maximizes the reporter's expected score.
+
+### Three quality dimensions, each needing different measurement
+
+**A. Accuracy**: Do the contributor's claims survive review and hold up over time?
+- Metric: review pass rate (how many proposed claims pass Leo's quality gate on first submission)
+- Metric: challenge survival rate (of accepted claims, what fraction survive subsequent challenges without significant revision)
+- Metric: confidence calibration (does "likely" mean ~70% right? Does "speculative" mean ~30%?)
+- Precedent: Metaculus tracks calibration curves for forecasters. The same approach works for claim proposers.
+
+**B. Impact**: Do the contributor's claims get used?
+- Metric: citation count — how many other claims wiki-link to this one
+- Metric: belief formation — did this claim enter any agent's belief set
+- Metric: position influence — did this claim materially influence a tracked position's reasoning
+- This is the [[usage-based value attribution rewards contributions for actual utility not popularity]] principle. Value flows through the graph.
+- Precedent: Google's PageRank. Academic h-index. Numerai's Meta Model Contribution (MMC).
+
+**C. Novelty**: Did the contributor bring genuinely new information?
+- Metric: semantic distance from existing claims at time of contribution (a claim that's 80% overlap with existing knowledge is less novel than one that opens new territory)
+- Metric: cross-domain connection value — did this claim create bridges between previously unlinked domains?
+- Precedent: Numerai's MMC specifically rewards predictions that ADD information beyond the meta-model. Same principle: reward the marginal information content, not the absolute accuracy.
+
+CLAIM CANDIDATE: Contribution quality scoring requires three independent axes — accuracy (survives review), impact (gets cited and used), and novelty (adds information beyond existing knowledge base) — because optimizing for any single axis produces pathological behavior: accuracy-only rewards safe consensus claims, impact-only rewards popular topics, novelty-only rewards contrarianism.
+
+### The PageRank-for-knowledge-graphs insight
+
+This is worth developing into a standalone claim. In the same way that PageRank values web pages by the quality and quantity of pages linking to them, a knowledge graph can value claims by:
+
+1. **Direct citation weight**: Each wiki-link from claim A to claim B transfers value. Weight by the citing claim's own quality score (recursive, like PageRank).
+2. **Belief formation weight**: A claim cited in an agent's beliefs.md gets a belief-formation bonus — it's load-bearing knowledge.
+3. **Position weight**: If a belief that depends on this claim leads to a validated position (the agent was RIGHT), the claim gets position-validation flow.
+4. **Temporal decay**: Recent citations count more than old ones. A claim cited frequently 6 months ago but never since is losing relevance.
+
+The beautiful thing: this value flows backward through the attribution chain. If Claim X gets high graph-value, then the sourcer who pointed to the evidence, the extractor who wrote it, and the reviewer who improved it ALL receive credit proportional to their role weights.
+
+### Gaming vectors
+
+- **Citation rings**: Contributors collude to cite each other's claims. Mitigation: PageRank-style algorithms are resistant to small cliques because value must flow in from outside the ring. Also: reviewer evaluation — Leo flags suspicious citation patterns.
+- **Self-citation**: Agent cites its own prior claims excessively. Mitigation: discount self-citations by 50-80% (same as academic practice).
+- **Quantity flooding**: Submit many low-quality claims hoping some stick. Mitigation: review pass rate enters the quality score. A 20% pass rate contributor gets penalized even if their absolute count is high.
+- **Safe consensus farming**: Only submit claims that are obviously true to get high accuracy. Mitigation: novelty axis — consensus claims score low on novelty.
+
+## 3. Voting Layer — Mechanism Selection for Human Collective Intelligence
+
+### What deserves a vote?
+
+Not everything. Voting is expensive (attention, deliberation, potential herding). The selection mechanism for vote-worthy decisions is itself a design problem.
+
+**Vote triggers** (proposed hierarchy):
+1. **Agent disagreement**: When two or more agents hold contradictory beliefs grounded in the same evidence, the interpretive difference is a human-judgment question. Surface it for vote.
+2. **High-stakes belief changes**: When a proposed belief change would cascade to 3+ positions, human validation adds legitimacy.
+3. **Value-laden decisions**: "What should the knowledge base prioritize?" is a values question that markets can't answer. Markets aggregate information; voting aggregates preferences. (Hanson's "vote on values, bet on beliefs" — this IS the values layer.)
+4. **Community proposals**: Contributors propose research directions, new domain creation, structural changes. These are collective resource allocation decisions.
+
+CLAIM CANDIDATE: Vote-worthiness is determined by the type of disagreement — factual disagreements should be resolved by markets or evidence (not votes), value disagreements should be resolved by votes (not markets), and mixed disagreements require sequential resolution where facts are established first and then values are voted on.
+
+### Diversity preservation
+
+Since [[collective intelligence requires diversity as a structural precondition not a moral preference]], the voting mechanism must structurally prevent convergence toward homogeneity.
+
+Mechanisms that preserve diversity:
+1. **Blind voting** (already a KB claim): Hide interim results, show engagement. Prevents herding.
+2. **Minority report**: When a vote produces a significant minority (>20%), the minority perspective is explicitly recorded alongside the majority decision. Not overruled — documented. This creates a public record that allows future re-evaluation when new evidence emerges.
+3. **Anti-correlation bonus**: If a contributor's votes systematically DISAGREE with consensus AND their accuracy is high, they receive a diversity premium. The system actively rewards high-quality dissent. This is the voting analog of Numerai's MMC.
+4. **Perspective quotas**: For votes that span domains, require minimum participation from each affected domain's community. Prevents one domain's orthodoxy from overwhelming another's.
+5. **Temporal diversity**: Not everyone votes at the same time. Staggered voting windows (early, main, late) prevent temporal herding where early voters anchor the frame.
+
+### Weighted voting by contribution quality
+
+This is the payoff of Section 2. Once you have a quality score for each contributor, you can weight their votes.
+
+**Weight formula (conceptual)**:
+```
+vote_weight = base_weight * accuracy_multiplier * domain_relevance * tenure_factor
+```
+
+- `base_weight`: 1.0 for all contributors (floor — prevents plutocracy)
+- `accuracy_multiplier`: 0.5 to 3.0 based on calibration curve and review pass rate
+- `domain_relevance`: How much of the contributor's quality score comes from THIS domain. A health domain expert voting on internet finance gets lower domain relevance. Prevents cross-domain dilution.
+- `tenure_factor`: Logarithmic growth with participation time. Prevents new entrants from being silenced but rewards sustained contribution.
+
+QUESTION: Should vote weight be capped? Uncapped weighting can produce de facto dictatorship if one contributor is dramatically more accurate. But capping removes the incentive signal. Possible resolution: cap individual vote weight at 5-10x the base, let the surplus flow to the contributor's token reward instead. Your quality earns you more tokens (economic power) but doesn't give you unlimited governance power (political power). This separates economic and political influence.
+
+### Interaction with futarchy
+
+The existing KB has strong claims about mixing mechanisms:
+- [[optimal governance requires mixing mechanisms because different decisions have different manipulation risk profiles]]
+- [[governance mechanism diversity compounds organizational learning because disagreement between mechanisms reveals information no single mechanism can produce]]
+
+**Proposed decision routing**:
+
+| Decision type | Primary mechanism | Secondary mechanism | Example |
+|--------------|------------------|--------------------| --------|
+| Factual assessment | Market (prediction market or futarchy) | Expert review | "Will this company reach $100M ARR by 2027?" |
+| Value prioritization | Weighted voting | Minority report | "Should we prioritize health or finance research?" |
+| Resource allocation | Futarchy (conditional on metric) | Vote to set the metric | "Allocate $X to research direction Y" — futarchy on expected impact, vote on what "impact" means |
+| Quality standard | Weighted voting | Market on outcomes | "Raise the confidence threshold for 'likely'?" |
+| New agent creation | Market (will this domain produce valuable claims?) | Vote on values alignment | "Should we create an education domain agent?" |
+
+The key insight: **voting and markets are complements, not substitutes**. Markets handle the "what is true?" layer. Voting handles the "what do we want?" layer. The mechanism design problem is routing each decision to the right layer.
+
+### Sybil resistance
+
+Since [[quadratic voting fails for crypto because Sybil resistance and collusion prevention are unsolvable]], pure token-weighted voting fails. But we have something crypto doesn't: **contribution history as identity proof**.
+
+A Sybil attacker would need to build multiple independent contribution histories, each with genuine quality scores, across different domains and time periods. This is fundamentally harder than creating multiple wallets. The cost of Sybil attack scales with the quality threshold — if voting requires minimum quality score of X, the attacker must do X units of genuine intellectual work per identity.
+
+CLAIM CANDIDATE: Contribution-history-weighted voting achieves Sybil resistance that token-weighted voting cannot because creating fake intellectual contribution histories requires genuine intellectual labor that scales linearly with the number of identities, while creating fake token identities requires only capital splitting.
+
+FLAG @theseus: This Sybil resistance argument assumes human contributors. AI-generated contributions could mass-produce synthetic contribution histories. If contributors use AI to generate claims, the cost of Sybil attack drops dramatically. Does your AI alignment work address AI-assisted governance manipulation?
+
+## 4. Information Collection as Mechanism Design — The Prediction Reward Problem
+
+### The insight: information contribution IS a prediction market
+
+When a contributor provides information to an agent, they're implicitly predicting: "this information will improve the agent's decision-making." If the agent's positions improve after incorporating this information, the contributor was right. If not, the information was noise.
+
+This is structurally identical to Numerai's tournament:
+- **Numerai**: Data scientists submit predictions. Predictions are evaluated against actual market outcomes. Scientists stake on their predictions — correct predictions earn returns, incorrect predictions are burned.
+- **Teleo**: Contributors submit information (claims, evidence, challenges). Information is evaluated against subsequent position performance and knowledge graph utility. Contributors earn reputation/tokens proportional to information value.
+
+### Proper scoring rules for information contribution
+
+The mechanism must incentivize:
+1. **Truthful reporting**: Contributors share what they genuinely believe, not what they think agents want to hear.
+2. **Effort calibration**: Contributors invest effort proportional to their actual information advantage.
+3. **Novelty seeking**: Contributors share information the system doesn't already have.
+
+**Brier-score analog for knowledge contribution**:
+
+For each contributor, track a rolling score based on:
+- `information_value = Σ (quality_score_of_claim × marginal_impact_on_agent_positions)`
+- Where `marginal_impact` is measured by: did incorporating this claim change an agent's belief or position? If so, did the changed position perform better than the counterfactual (what would have happened without the information)?
+
+The counterfactual is the hard part. In prediction markets, you know what would have happened without a trade (the price stays where it was). In knowledge contribution, the counterfactual is "what would the agent have believed without this claim?" — which requires maintaining a shadow model. This may be tractable for agent-based systems: run the agent's belief evaluation with and without the contributed claim and compare downstream performance.
+
+CLAIM CANDIDATE: Knowledge contribution rewards can be made incentive-compatible through counterfactual impact scoring — comparing agent position performance with and without the contributed information — because the same shadow-model technique that enables Shapley value computation in machine learning applies to knowledge graph contributions.
+
+### The Bayesian truth serum connection
+
+Prelec's Bayesian Truth Serum (BTS) offers another angle: reward answers that are "surprisingly popular" — more common than respondents predicted. In a knowledge context: if most contributors think a claim is unimportant but one contributor insists it matters, and it turns out to matter, the dissenting contributor gets a disproportionate reward. BTS naturally rewards private information because only someone with genuine private knowledge would give an answer that differs from what they predict others will say.
+
+Application to Teleo: When a contributor provides information, also ask them: "What percentage of other contributors would flag this as important?" If their importance rating is higher than their predicted consensus, AND the information turns out to be important, the BTS mechanism rewards them for having genuine private information rather than following the crowd.
+
+### Reward structure
+
+Two layers:
+1. **Reputation (non-transferable)**: Quality score that determines vote weight and contributor tier. Earned through accuracy, impact, novelty. Cannot be bought or transferred. This IS the Sybil resistance.
+2. **Tokens (transferable)**: Economic reward proportional to information value. Can be staked on future contributions (Numerai model), used for governance weight multipliers, or traded. This IS the economic incentive.
+
+The separation matters: reputation is the meritocratic layer (who has good judgment). Tokens are the economic layer (who has created value). Keeping them separate prevents the plutocratic collapse where token-wealthy contributors dominate governance regardless of contribution quality.
+
+CLAIM CANDIDATE: Separating reputation (non-transferable quality score) from tokens (transferable economic reward) prevents the plutocratic collapse that token-only systems produce because it forces governance influence to be earned through demonstrated judgment rather than purchased with accumulated capital.
+
+### Gaming vectors
+
+- **Information front-running**: Contributor learns agent will incorporate X, publishes a claim about X first to claim credit. Mitigation: timestamp-verified contribution records + "marginal information" scoring (if the agent was already going to learn X, your contribution adds zero marginal value).
+- **Strategic withholding**: Contributor holds information to release at the optimal time for maximum credit. Mitigation: temporal decay — information provided earlier gets a freshness bonus. Sitting on information costs you.
+- **Sycophantic contribution**: Providing information the agent will obviously like rather than information that's genuinely valuable. Mitigation: novelty scoring + counterfactual impact. Telling Rio "futarchy is great" adds no marginal value. Telling Rio "here's evidence futarchy fails in context X" adds high marginal value if the counterfactual shows Rio would have missed it.
+- **AI-generated bulk submission**: Using AI to mass-produce plausible claims. Mitigation: quality scoring penalizes low pass rates. If you submit 100 AI-generated claims and 5 pass review, your quality score craters.
+
+## Synthesis: The Full Stack
+
+```
+CONTRIBUTOR → IDENTITY → CONTRIBUTION → QUALITY SCORE → VOTING WEIGHT + TOKEN REWARD
+     |              |           |               |                |              |
+  pseudonymous   persistent  role-tagged    three-axis      capped at 10x   proportional to
+  key-pair       reputation  attribution    scoring         base weight      marginal impact
+                              chain         (accuracy +                      on agent
+                                            impact +                         performance
+                                            novelty)
+```
+
+The mechanism design insight that ties it together: **every layer is incentive-compatible by construction**. Contributors are rewarded for truthful, high-quality, novel contributions. The rewards feed into voting weight, which makes governance reflect contribution quality. Governance decisions direct research priorities, which determine what contributions are most valuable. The loop is self-reinforcing.
+
+The critical failure mode to watch: **the loop becomes self-referential**. If the same contributors who earn high quality scores also set the quality criteria, the system converges toward their preferences and excludes dissenting voices. The diversity preservation mechanisms (minority report, anti-correlation bonus, blind voting) are structural safeguards against this convergence. They must be hardened against removal by majority vote — constitutional protections for cognitive diversity.
+
+## Open Questions
+
+1. **Counterfactual computation**: How expensive is it to maintain shadow models for marginal impact scoring? Is this tractable at scale, or do we need approximations?
+2. **Cold start**: How do new contributors build reputation? If the system requires quality history to have meaningful vote weight, new entrants face a chicken-and-egg problem. Need an onramp — possibly a "provisional contributor" tier with boosted rewards for first N contributions to accelerate initial scoring.
+3. **Cross-domain voting**: Should a high-quality health domain contributor have any vote weight on internet finance decisions? The domain_relevance factor handles this partially, but the policy question is whether cross-domain voting should be enabled at all.
+4. **Agent vs human voting**: How do agent "votes" (their belief evaluations) interact with human votes? Should agents have fixed voting weight, or should it also be earned? Currently agents have de facto veto through PR review — is that the right long-term structure?
+5. **Temporal horizon**: Some contributions prove valuable years later (a claim that seemed marginal becomes foundational). The quality scoring system needs to handle retroactive value discovery without creating gaming opportunities.
+6. **Scale thresholds**: These mechanisms assume N>50 contributors. Below that, reputation systems are noisy and voting is statistically meaningless. What's the minimum viable contributor base for each mechanism to activate?
+
+---
+
+Relevant Notes:
+- [[mechanism design enables incentive-compatible coordination by constructing rules under which self-interested agents voluntarily reveal private information and take socially optimal actions]] — the theoretical foundation for all four design problems
+- [[usage-based value attribution rewards contributions for actual utility not popularity]] — the impact measurement principle
+- [[blind meritocratic voting forces independent thinking by hiding interim results while showing engagement]] — existing KB claim on voting mechanism
+- [[speculative markets aggregate information through incentive and selection effects not wisdom of crowds]] — markets as information aggregation devices, the model for information contribution rewards
+- [[expert staking in Living Capital uses Numerai-style bounded burns for performance and escalating dispute bonds for fraud creating accountability without deterring participation]] — the staking architecture adapted from Numerai
+- [[collective intelligence requires diversity as a structural precondition not a moral preference]] — the structural requirement that voting mechanisms must preserve
+- [[quadratic voting fails for crypto because Sybil resistance and collusion prevention are unsolvable]] — why token-weighted voting fails and contribution-history-based voting may succeed
+- [[optimal governance requires mixing mechanisms because different decisions have different manipulation risk profiles]] — the decision routing framework
+- [[governance mechanism diversity compounds organizational learning because disagreement between mechanisms reveals information no single mechanism can produce]] — why mixing voting and markets is better than either alone
+- [[dynamic performance-based token minting replaces fixed emission schedules by tying new token creation to measurable outcomes creating algorithmic meritocracy in token distribution]] — the token reward mechanism foundation
+- [[gamified contribution with ownership stakes aligns individual sharing with collective intelligence growth]] — the engagement layer on top of the attribution system
+- [[collaborative knowledge infrastructure requires separating the versioning problem from the knowledge evolution problem because git solves file history but not semantic disagreement or insight-level attribution]] — the infrastructure gap this musing addresses
+
+Topics:
+- [[coordination mechanisms]]
+- [[internet finance and decision markets]]
+- [[LivingIP architecture]]

domains/internet-finance/direct-fan-to-artist-subscription-routing-multiplies-per-listener-revenue-by-approximately-14x-versus-pro-rata-pool-streaming.md

@@ -0,0 +1,50 @@
+---
+type: claim
+domain: internet-finance
+secondary_domains: [entertainment]
+description: "Open Music's model routes each subscriber's payment exclusively to artists they listened to that month, cutting the platform fee from ~30% to 10% and eliminating cross-platform dilution — yielding ~$128/mo from 100 fans versus ~$9/mo on Spotify"
+confidence: experimental
+source: "Rio, via Open Music pitch on Futardio (2026-03-03); model is live but unproven at scale"
+created: 2026-03-11
+depends_on: ["spotify-pro-rata-royalty-pool-concentrates-streaming-revenue-in-top-catalog-because-every-subscribers-payment-competes-against-all-global-streams"]
+challenged_by: []
+---
+
+# Direct fan-to-artist subscription routing multiplies per-listener revenue by approximately 14x versus pro-rata pool streaming
+
+When a subscription payment is routed directly to the artists a subscriber actually listened to — rather than pooled across all global streams — the effective revenue per listener increases dramatically. Open Music's model projects approximately $128/month from 100 fans versus $9/month for the same 100 fans' streams on Spotify. The mechanism driving this difference is twofold:
+
+**1. Routing eliminates dilution.** Under Spotify's pro-rata model, 100 fans paying $10.99/month contribute to a global pool divided by hundreds of billions of streams. The artist's share of that pool may be negligible even if those specific fans listen to them heavily. Under direct routing, the same 100 fans' subscription revenue flows proportionally to the artists those fans listened to — no dilution from streams outside their personal listening.
+
+**2. Lower platform cut.** Spotify retains approximately 30% before royalty distribution. Open Music retains 10%, leaving 90% to flow to artists. The two-percentage-point difference alone doesn't explain the 14x gap; the routing change is the primary driver.
+
+The 14x figure assumes listener concentration — i.e., that a significant fraction of each subscriber's listening time goes to the artist in question. If a subscriber spreads 40 hours of listening across 200 different artists, each artist's direct-routing payment approaches the pro-rata rate. The multiplier is maximized for artists who function as a primary listening destination for their fans, not background ambient tracks.
+
+## Evidence
+
+- Open Music comparison (Futardio pitch, 2026-03-03): 100 fans → ~$9/mo (Spotify) vs ~$128/mo (Open Music)
+- Platform cut differential: Spotify ~30% vs Open Music 10% (from Open Music comparison table)
+- Open Music MVP is live at openmusic.art with artist upload and payment capability as of launch date
+- Raise status: $27,533 committed of $250,000 target before entering Refunding status — product live but community/adoption early
+
+## Scope and Limits
+
+This claim is about **structural routing design**, not verified outcomes. The 14x figure is Open Music's model projection, not measured at scale. Key constraints:
+- The multiplier is sensitive to listener concentration (listening depth per fan)
+- Platform adoption rate determines whether subscription fees are competitive with Spotify's pricing
+- Artist audience ownership (knowing who paid you) is a separate benefit that compounds the routing advantage by enabling direct fan relationships
+
+## Challenges
+
+Direct routing models have been attempted before (Bandcamp's partial model, user-centric distribution proposals) without displacing pro-rata. Adoption barriers include: platform liquidity (artists need subscriber critical mass), discoverability (Spotify's algorithm is a key distribution channel), and listener habit (most subscribers don't actively choose per-artist destinations).
+
+---
+
+Relevant Notes:
+- [[spotify-pro-rata-royalty-pool-concentrates-streaming-revenue-in-top-catalog-because-every-subscribers-payment-competes-against-all-global-streams]] — the structural problem this claim quantifies the solution to
+- [[creator-owned-direct-subscription-platforms-produce-qualitatively-different-audience-relationships-than-algorithmic-social-platforms-because-subscribers-choose-deliberately.md]] — related structural shift from platform-mediated to direct relationships
+- [[futardio-utility-project-raises-consistently-fail-while-meme-coin-succeeded-suggesting-futarchy-governed-crowdfunding-selects-for-speculative-community-demand]] — Open Music's failed raise suggests market skepticism about adoption pathway
+
+Topics:
+- [[domains/internet-finance/_map]]
+- [[domains/entertainment/_map]]

domains/internet-finance/futardio-utility-project-raises-consistently-fail-while-meme-coin-succeeded-suggesting-futarchy-governed-crowdfunding-selects-for-speculative-community-demand.md

@@ -0,0 +1,21 @@
+---
+type: claim
+domain: internet-finance
+confidence: experimental
+description: Futardio utility project raises consistently fail while meme coin succeeded, suggesting futarchy-governed crowdfunding selects for speculative community demand.
+created: 2023-10-01
+processed_date: 2023-10-10
+source: internal analysis
+---
+
+## Evidence Table
+
+| Project        | Raised | Goal  | Percentage |
+|----------------|--------|-------|------------|
+| SeekerVault    | $1,186 | $75K  | 1.6%       |
+| Project A      | $5,000 | $100K | 5%         |
+| Project B      | $10,000| $200K | 5%         |
+| Project C      | $2,500 | $50K  | 5%         |
+| Meme Coin      | $100K  | $100K | 100%       |
+
+<!-- claim pending -->

domains/internet-finance/spotify-pro-rata-royalty-pool-concentrates-streaming-revenue-in-top-catalog-because-every-subscribers-payment-competes-against-all-global-streams.md

@@ -0,0 +1,42 @@
+---
+type: claim
+domain: internet-finance
+secondary_domains: [entertainment]
+description: "Spotify earned $20B in 2025 while paying $0.003/stream because pro-rata pooling divides all subscriber revenue by each track's share of global streams, routing money to the top-1% catalog that dominates total stream counts"
+confidence: likely
+source: "Rio, via Open Music pitch on Futardio (2026-03-03)"
+created: 2026-03-11
+depends_on: []
+challenged_by: []
+---
+
+# Spotify's pro-rata royalty pool concentrates streaming revenue in top-catalog because every subscriber's payment competes against all global streams
+
+Spotify's royalty model distributes revenue from a global pool: all subscriber payments (minus Spotify's ~30% cut) flow into a single fund divided proportionally by stream count. An artist's payout equals their share of total platform streams. Because stream counts are distributed with extreme power-law concentration — the top 1% of catalog generates the overwhelming majority of total streams — the pro-rata model systematically routes subscriber money away from the artists each subscriber actually chose to listen to.
+
+The mechanism produces a specific distortion: a subscriber who listens exclusively to independent artists for 40 hours a month still has most of their $10.99 subscription distributed to Drake, Taylor Swift, and catalog licensed by major labels — because those tracks dominate global stream share. The artist the subscriber cares about captures only their microscopic fraction of the global pool.
+
+This is not a bug. It is the design: a pooled model benefits catalog owners with the largest existing distribution (major labels), who have the most to gain from scale effects and the most political weight in royalty negotiations.
+
+## Evidence
+
+- Spotify reported approximately $20 billion in revenue in 2025 (Open Music pitch, Futardio 2026-03-03)
+- Average per-stream payout: $0.003 — an industry-standard figure widely reported by musicians comparing streaming to sync or live revenue
+- Pro-rata structure: all subscriber and ad revenue enters a single pool, distributed by stream-count share (Spotify's published royalty methodology)
+- Top-1% catalog concentration: documented across multiple music industry analyses; information cascade dynamics predict this outcome structurally
+
+## Challenges
+
+The pro-rata critique is contested by Spotify, which argues that (1) the alternative "user-centric" model would only shift ~3–5% of total royalties between artists in practice, and (2) that the low per-stream rate reflects total volume, not extraction. Critics counter that the volume argument is circular — the volume is high because the model incentivizes catalog stacking, not because listeners are getting more music per dollar.
+
+---
+
+Relevant Notes:
+- [[direct-fan-to-artist-subscription-routing-multiplies-per-listener-revenue-by-approximately-14x-versus-pro-rata-pool-streaming]] — quantifies the revenue difference when routing is redesigned
+- [[information cascades create power law distributions in culture because consumers use popularity as a quality signal when choice is overwhelming.md]] — explains why stream concentration compounds through discovery mechanics
+- [[streaming churn may be permanently uneconomic because maintenance marketing consumes up to half of average revenue per user.md]] — separate but related structural problem in streaming economics
+- [[creator-owned-direct-subscription-platforms-produce-qualitatively-different-audience-relationships-than-algorithmic-social-platforms-because-subscribers-choose-deliberately.md]] — direct subscription as structural alternative
+
+Topics:
+- [[domains/internet-finance/_map]]
+- [[domains/entertainment/_map]]

entities/internet-finance/deans-list-implement-3-week-vesting.md

@@ -0,0 +1,50 @@
+---
+type: entity
+entity_type: decision_market
+name: "IslandDAO: Implement 3-Week Vesting for DAO Payments"
+domain: internet-finance
+status: passed
+parent_entity: "[[deans-list]]"
+platform: "futardio"
+proposer: "proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2"
+proposal_url: "https://www.futard.io/proposal/C2Up9wYYJM1A94fgJz17e3Xsr8jft2qYMwrR6s4ckaKK"
+proposal_date: 2024-12-16
+resolution_date: 2024-12-19
+category: "treasury"
+summary: "Linear 3-week vesting for all DAO payments to reduce sell pressure from 80% immediate liquidation to 33% weekly rate"
+key_metrics:
+  weekly_payments: "3,000 USDC"
+  previous_sell_rate: "80% (2,400 USDC/week)"
+  post_vesting_sell_rate: "33% (1,000 USDC/week)"
+  sell_pressure_reduction: "58%"
+  projected_valuation_increase: "15%-25%"
+  pass_threshold_mcap: "533,500 USDC"
+  baseline_mcap: "518,000 USDC"
+tracked_by: rio
+created: 2026-03-11
+---
+
+# IslandDAO: Implement 3-Week Vesting for DAO Payments
+
+## Summary
+Proposal to implement linear 3-week vesting for all DAO payments (rewards, compensation) via token streaming contracts. Aimed to reduce immediate sell pressure from 80% of payments being liquidated weekly (2,400 USDC of 3,000 USDC) to 33% weekly rate (1,000 USDC), a 58% reduction. Projected 15%-25% valuation increase through combined sell pressure reduction (10%-15% price impact) and improved market sentiment (5%-10% demand growth).
+
+## Market Data
+- **Outcome:** Passed
+- **Proposer:** proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2
+- **Resolution:** 2024-12-19
+- **Pass Threshold:** 533,500 USDC MCAP (baseline 518,000 + 3%)
+
+## Mechanism Details
+- **Vesting Schedule:** Linear unvesting starting day 1 over 3 weeks
+- **Implementation:** Token streaming contract
+- **Target:** All DAO payments (rewards, compensation)
+- **Rationale:** Discourage market manipulation, support price growth, align recipient incentives
+
+## Significance
+Demonstrates futarchy-governed treasury operations addressing sell pressure dynamics. The proposal included sophisticated market impact modeling: 80% immediate liquidation rate, weekly payment flows (3,000 USDC), sell pressure as percentage of market cap (0.81% reduction over 3 weeks), and price elasticity estimates (1%-2% supply reduction → 10%-20% price increase). Shows how DAOs use vesting as tokenomic stabilization rather than just alignment mechanism.
+
+## Relationship to KB
+- [[deans-list]] - treasury governance decision
+- [[time-based-token-vesting-is-hedgeable-making-standard-lockups-meaningless-as-alignment-mechanisms-because-investors-can-short-sell-to-neutralize-lockup-exposure-while-appearing-locked]] - vesting as sell pressure management
+- [[futarchy-adoption-faces-friction-from-token-price-psychology-proposal-complexity-and-liquidity-requirements]] - proposal complexity example

entities/internet-finance/deans-list.md

@@ -43,3 +43,7 @@ Relevant Entities:
 
 Topics:
 - [[internet finance and decision markets]]
+
+## Timeline
+
+- **2024-12-19** — [[deans-list-implement-3-week-vesting]] passed: 3-week linear vesting for DAO payments to reduce sell pressure from 80% immediate liquidation to 33% weekly rate, projected 15%-25% valuation increase

entities/internet-finance/futardio.md

@@ -45,6 +45,7 @@ MetaDAO's token launch platform. Implements "unruggable ICOs" — permissionless
 - **2026-03** — Ranger Finance liquidation proposal — first futarchy-governed enforcement action
 
 - **2026-03-07** — Areal DAO launch: $50K target, raised $11,654 (23.3%), REFUNDING status by 2026-03-08 — first documented failed futarchy-governed fundraise on platform
+- **2026-03-04** — [[seekervault]] fundraise launched targeting $75,000, closed next day with only $1,186 (1.6% of target) in refunding status
 ## Competitive Position
 - **Unique mechanism**: Only launch platform with futarchy-governed accountability and treasury return guarantees
 - **vs pump.fun**: pump.fun is memecoin launch (zero accountability, pure speculation). Futardio is ownership coin launch (futarchy governance, treasury enforcement). Different categories despite both being "launch platforms."

entities/internet-finance/metadao-burn-993-percent-meta.md

@@ -0,0 +1,49 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Burn 99.3% of META in Treasury"
+domain: internet-finance
+status: passed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "doctor.sol & rar3"
+proposal_url: "https://www.futard.io/proposal/ELwCkHt1U9VBpUFJ7qGoVMatEwLSr1HYj9q9t8JQ1NcU"
+proposal_date: 2024-03-03
+resolution_date: 2024-03-08
+category: treasury
+summary: "Burn ~979,000 of 982,464 treasury-held META tokens to reduce FDV and attract investors"
+tags: ["futarchy", "tokenomics", "treasury-management", "meta-token"]
+---
+
+# MetaDAO: Burn 99.3% of META in Treasury
+
+## Summary
+Proposal to burn approximately 99.3% of treasury-held META tokens (~979,000 of 982,464) to significantly reduce the Fully Diluted Valuation. Passed on Autocrat v0.1. The high FDV was perceived as discouraging investors and limiting participation in the futarchy experiment. Post-burn treasury: ~4,500 META valued at ~$4M plus ~$2M in META-USDC LP at the time ($880/META). Total META supply after burn: ~20,885.
+
+## Market Data
+- **Outcome:** Passed (2024-03-08)
+- **Autocrat version:** 0.1
+- **Key participants:** doctor.sol & rar3 (authors), Proph3t (executor)
+
+## Significance
+One of the most consequential early MetaDAO governance decisions. The burn fundamentally changed MetaDAO's token economics — eliminating the treasury's ability to pay in META and forcing future operations to use USDC or market-purchase META. This created a natural scarcity signal but also meant the DAO would eventually need mintable tokens (which the proposal explicitly noted as a future possibility). The burn set the stage for the later token split and elastic supply debates.
+
+The proposal also reveals early futarchy dynamics: community members (not founders) proposed a radical tokenomics change, and the market approved it. This is a concrete example of futarchy enabling non-founder governance proposals with material treasury impact.
+
+## Relationship to KB
+- [[metadao]] — governance decision, treasury management
+- [[futarchy enables trustless joint ownership by forcing dissenters to be bought out through pass markets]] — demonstrates market-governed treasury decisions
+- [[ownership coin treasuries should be actively managed through buybacks and token sales as continuous capital calibration not treated as static war chests]] — burn as extreme active management
+- [[futarchy-daos-require-mintable-governance-tokens-because-fixed-supply-treasuries-exhaust-without-issuance-authority-forcing-disruptive-token-architecture-migrations]] — this burn directly created the conditions that made mintable tokens necessary
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[proph3t]] — executor
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-compensation-proph3t-nallok.md

@@ -0,0 +1,54 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Approve Performance-Based Compensation for Proph3t and Nallok"
+domain: internet-finance
+status: passed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "Proph3t & Nallok"
+proposal_url: "https://www.futard.io/proposal/BgHv9GutbnsXZLZQHqPL8BbGWwtcaRDWx82aeRMNmJbG"
+proposal_date: 2024-05-27
+resolution_date: 2024-05-31
+category: hiring
+summary: "Convex payout: 2% supply per $1B market cap increase (max 10% at $5B), $90K/yr salary each, 4-year vest starting April 2028"
+tags: ["futarchy", "compensation", "founder-incentives", "mechanism-design"]
+---
+
+# MetaDAO: Approve Performance-Based Compensation for Proph3t and Nallok
+
+## Summary
+The founders proposed a convex performance-based compensation package: 2% of token supply per $1 billion market cap increase, capped at 10% (1,975 META each) at $5B. Fixed salary of $90K/year each. Four-year cliff — no tokens unlock before April 2028 regardless of milestones. DAO can claw back all tokens until December 2024. The $1B market cap benchmark was defined as $42,198 per META (allowing for 20% dilution post-proposal).
+
+The proposal included explicit utility calculations using expected value theory: Nallok requires $361M success payout to rationally stay (20% success probability estimate), Proph3t requires $562M (10% success probability). This drove the 10% allocation at $5B market cap (~$500M payout each).
+
+## Market Data
+- **Outcome:** Passed (2024-05-31)
+- **Autocrat version:** 0.3
+- **Key participants:** Proph3t (architect/mechanism designer), Nallok (operations manager)
+
+## Significance
+This is the first real-world example of futarchy-governed founder compensation. The mechanism design is sophisticated: convex payouts align incentives with exponential growth, the 4-year cliff signals long-term commitment, and the clawback provision creates accountability.
+
+The explicit utility calculation in the proposal is remarkable — founders openly modeled their reservation wages, success probabilities, and effort costs, then derived the compensation that makes maximum effort rational. Proph3t estimated only 10% success probability, making his required payout higher than Nallok's despite both receiving equal allocation. This transparency is the opposite of typical startup compensation negotiations.
+
+The proposal also honestly acknowledges centralization: "If Nallok and I walk away, probability of success drops by at least 50%." Futarchy governed the compensation decision, but the organization remained founder-dependent — the market approved this rather than pretending otherwise.
+
+## Relationship to KB
+- [[metadao]] — founder compensation structure
+- [[performance-unlocked-team-tokens-with-price-multiple-triggers-and-twap-settlement-create-long-term-alignment-without-initial-dilution]] — direct implementation of this mechanism
+- [[token economics replacing management fees and carried interest creates natural meritocracy in investment governance]] — performance-based rather than fixed allocation
+- [[time-based token vesting is hedgeable making standard lockups meaningless as alignment mechanisms because investors can short-sell to neutralize lockup exposure while appearing locked]] — this proposal uses milestone vesting instead of time-based, partially addressing the hedging problem
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[proph3t]] — compensated founder
+- [[nallok]] — compensated founder
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-create-futardio.md

@@ -0,0 +1,50 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Should MetaDAO Create Futardio?"
+domain: internet-finance
+status: failed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "unknown"
+proposal_url: "https://www.futard.io/proposal/zN9Uft1zEsh9h7Wspeg5bTNirBBvtBTaJ6i5KcEnbAb"
+proposal_date: 2024-11-21
+resolution_date: 2024-11-25
+category: strategy
+summary: "Minimal proposal to create Futardio — failed, likely due to lack of specification and justification"
+tags: ["futarchy", "futardio", "governance-filtering"]
+---
+
+# MetaDAO: Should MetaDAO Create Futardio?
+
+## Summary
+A minimal one-sentence proposal: "Futardio is a great idea and needs to happen." Filed under the "Program" category. Failed within 4 days. No budget, no specification, no implementation plan. The proposer identity is not associated with core team members.
+
+## Market Data
+- **Outcome:** Failed (2024-11-25)
+- **Autocrat version:** 0.3
+- **Key participants:** Unknown proposer
+
+## Significance
+This failed proposal is more informative than many that passed. It demonstrates futarchy's quality filtering function — the market rejected an unsubstantiated proposal despite the concept (Futardio/permissionless launchpad) eventually being approved three months later with proper specification (see [[metadao-release-launchpad]]). The market distinguished between "good idea" and "well-specified proposal," rejecting the former and approving the latter.
+
+This is concrete evidence against the criticism that futarchy markets are easily manipulated or that token holders vote based on vibes rather than substance. The failure also shows that non-founder community members can propose, even if their proposals face higher scrutiny.
+
+Note: The later "Release a Launchpad" proposal (2025-02-26) by Proph3t and Kollan succeeded — same concept, dramatically better specification.
+
+## Relationship to KB
+- [[metadao]] — governance decision, quality filtering
+- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — this proposal was too simple to pass
+- [[futarchy is manipulation-resistant because attack attempts create profitable opportunities for defenders]] — the market correctly filtered a low-quality proposal
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[futardio]] — the entity that was eventually created
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-develop-faas.md

@@ -0,0 +1,52 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Develop Futarchy as a Service (FaaS)"
+domain: internet-finance
+status: passed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "0xNallok"
+proposal_url: "https://www.futard.io/proposal/D9pGGmG2rCJ5BXzbDoct7EcQL6F6A57azqYHdpWJL9Cc"
+proposal_date: 2024-03-13
+resolution_date: 2024-03-19
+category: strategy
+summary: "Fund $96K to build futarchy-as-a-service platform enabling other Solana DAOs to adopt futarchic governance"
+tags: ["futarchy", "faas", "product-development", "solana-daos"]
+---
+
+# MetaDAO: Develop Futarchy as a Service (FaaS)
+
+## Summary
+Nallok proposed building a Realms-like UI enabling any Solana DAO to create and participate in futarchic governance. Budget: $96K for 2 months ($40K USDC from treasury + 342 META to convert). Team: 1 smart contract engineer, 1 auditor, 2 UI/UX, 1 data/services developer, 1 project manager. This was MetaDAO's first product expansion beyond self-governance — the pivot from "futarchy for MetaDAO" to "futarchy for everyone."
+
+## Market Data
+- **Outcome:** Passed (2024-03-19)
+- **Autocrat version:** 0.1
+- **Key participants:** 0xNallok (entrepreneur/PM), Proph3t (multisig), Nico (multisig)
+
+## Significance
+This proposal marks MetaDAO's strategic pivot from a governance experiment to a platform business. The financial projections (5-100 DAO customers, $50-$500/proposal in taker fees, $50-$1,000/month licensing) reveal early business model thinking. The explicit goal of "vertical integration" and "owning the whole stack" shows Proph3t and Nallok's approach to defensibility.
+
+Particularly notable: the monetization model (taker fees + licensing + consulting) anticipated the Futarchic AMM revenue model that would later become MetaDAO's primary income source. The FaaS concept directly led to Drift, Dean's List, and Future adopting futarchy.
+
+## Relationship to KB
+- [[metadao]] — strategic pivot to platform
+- [[MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale]] — FaaS was the first step toward this
+- [[futarchy-governed DAOs converge on traditional corporate governance scaffolding for treasury operations because market mechanisms alone cannot provide operational security and legal compliance]] — multisig custody of funds alongside futarchy approval
+- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — FaaS aimed to reduce adoption friction
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[nallok]] — project entrepreneur
+- [[proph3t]] — multisig member
+- [[deans-list]] — early FaaS adopter
+- [[drift]] — early FaaS adopter
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-fundraise-2.md

@@ -0,0 +1,51 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Approve Fundraise #2"
+domain: internet-finance
+status: passed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "Proph3t"
+proposal_url: "https://www.futard.io/proposal/9BMRY1HBe61MJoKEd9AAW5iNQyws2vGK6vuL49oR3AzX"
+proposal_date: 2024-06-26
+resolution_date: 2024-06-30
+category: fundraise
+summary: "Raise $1.5M by selling up to 4,000 META to VCs and angels at minimum $375/META ($7.81M FDV), no discount, no lockup"
+tags: ["futarchy", "fundraise", "capital-formation", "venture-capital"]
+---
+
+# MetaDAO: Approve Fundraise #2
+
+## Summary
+Proposal to raise $1.5M by selling up to 4,000 META to VCs and angels. Terms: no discount, no lockup, minimum price $375/META (implying $7.81M minimum FDV based on 20,823.5 META in public hands). Funds custodied by Proph3t and Nallok in a multisig, released at $100K/month to minimize DAO attack risk. Burn rate: $1.38M/year covering two founders ($90K each), three engineers ($190K each), audits ($300K), office ($80K), growth person ($150K), and admin ($100K).
+
+## Market Data
+- **Outcome:** Passed (2024-06-30)
+- **Autocrat version:** 0.3
+- **Key participants:** Proph3t (proposer), Nallok (multisig co-custodian)
+
+## Significance
+This was MetaDAO's first VC fundraise approved through futarchy — the market decided whether to dilute existing holders for growth capital. The "no discount, no lockup" terms are unusual for crypto fundraises and reflect futarchy's transparency ethos: investors get the same terms as the market.
+
+The multisig custodianship ($100K/month release) reveals a practical tension: futarchy governs the fundraise decision, but operational security requires trusted custodians. The DAO cannot safely hold and disburse large sums through governance alone — an early signal of the pattern where futarchy-governed DAOs converge on traditional corporate scaffolding for treasury operations.
+
+The detailed budget breakdown provides one of the few public windows into early MetaDAO operational costs, valuable for benchmarking futarchy-governed organizations.
+
+## Relationship to KB
+- [[metadao]] — capital formation event
+- [[internet-capital-markets-compress-fundraising-timelines]] — futarchy-governed fundraise completed in 4 days
+- [[futarchy-governed DAOs converge on traditional corporate governance scaffolding for treasury operations because market mechanisms alone cannot provide operational security and legal compliance]] — multisig custody alongside futarchy approval
+- [[futarchy-based fundraising creates regulatory separation because there are no beneficial owners and investment decisions emerge from market forces not centralized control]] — but this raise has identifiable custodians, complicating the "no beneficial owners" argument
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[proph3t]] — proposer and custodian
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-hire-robin-hanson.md

@@ -0,0 +1,51 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Hire Robin Hanson as Advisor"
+domain: internet-finance
+status: passed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "Proph3t"
+proposal_url: "https://www.futard.io/proposal/AnCu4QFDmoGpebfAM8Aa7kViouAk1JW6LJCJJer6ELBF"
+proposal_date: 2025-02-10
+resolution_date: 2025-02-13
+category: hiring
+summary: "Hire Robin Hanson (inventor of futarchy) as advisor — 0.1% supply (20.9 META) vested over 2 years for mechanism design and strategy"
+tags: ["futarchy", "robin-hanson", "advisory", "mechanism-design"]
+---
+
+# MetaDAO: Hire Robin Hanson as Advisor
+
+## Summary
+Proposal to hire Robin Hanson — the economist who originally proposed futarchy in 2000 — as an advisor. Scope: mechanism design and strategy advice, co-authoring blog posts and whitepapers on new futarchic mechanisms (specifically mentioning a "shared liquidity AMM" design). Compensation: 0.1% of supply (20.9 META) vested over 2 years. Early termination allowed by Robin, MetaDAO, or Proph3t and Kollan unanimously.
+
+## Market Data
+- **Outcome:** Passed (2025-02-13)
+- **Autocrat version:** 0.3
+- **Key participants:** Proph3t (proposer), Robin Hanson (advisor)
+
+## Significance
+The futarchy mechanism's inventor becoming an advisor to its most advanced implementation creates a theory-practice feedback loop. Hanson's insights have already influenced concrete product design — the proposal mentions a "shared liquidity AMM" where META/USDC liquidity can be used in both pMETA/pUSDC and fMETA/fUSDC conditional markets, addressing a key capital inefficiency problem.
+
+The compensation terms (0.1% of supply) are modest relative to founder allocations (10% each for Proph3t and Nallok), appropriate for an advisory role. The 2-year vest with early termination clause is standard advisory structure — another example of futarchy-governed DAOs adopting traditional corporate governance patterns for operational decisions.
+
+This is also the first time a major academic figure (GMU economics professor, >10,000 citations) has been hired through futarchic governance, lending institutional credibility to the mechanism.
+
+## Relationship to KB
+- [[metadao]] — advisory hire
+- [[shared-liquidity-amms-could-solve-futarchy-capital-inefficiency-by-routing-base-pair-deposits-into-all-derived-conditional-token-markets]] — Hanson-Proph3t collaboration product
+- [[futarchy implementations must simplify theoretical mechanisms for production adoption because original designs include impractical elements that academics tolerate but users reject]] — Hanson bridges theory and implementation
+- [[futarchy-governed DAOs converge on traditional corporate governance scaffolding for treasury operations because market mechanisms alone cannot provide operational security and legal compliance]] — standard advisory terms within futarchy governance
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[proph3t]] — proposer
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-migrate-autocrat-v02.md

@@ -0,0 +1,51 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Migrate Autocrat Program to v0.2"
+domain: internet-finance
+status: passed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "HenryE & Proph3t"
+proposal_url: "https://www.futard.io/proposal/HXohDRKtDcXNKnWysjyjK8S5SvBe76J5o4NdcF4jj963"
+proposal_date: 2024-03-28
+resolution_date: 2024-04-03
+category: mechanism
+summary: "Upgrade Autocrat to v0.2 with reclaimable rent, conditional token merging, improved metadata, and lower pass threshold (5% to 3%)"
+tags: ["futarchy", "autocrat", "mechanism-upgrade", "solana"]
+---
+
+# MetaDAO: Migrate Autocrat Program to v0.2
+
+## Summary
+Technical upgrade from Autocrat v0.1 to v0.2. Three new features: (1) reclaimable rent — recover ~4 SOL used to create proposal markets, lowering proposal creation friction; (2) conditional token merging — combine 1 pTOKEN + 1 fTOKEN back into 1 TOKEN, improving liquidity during multiple active proposals; (3) conditional token metadata — tokens show names and logos in wallets instead of raw mint addresses. Config changes: pass threshold lowered from 5% to 3%, default TWAP value set to $100, TWAP updates in $5 increments (enhancing manipulation resistance), minimum META lot size reduced from 1 to 0.1 META.
+
+## Market Data
+- **Outcome:** Passed (2024-04-03)
+- **Autocrat version:** 0.1 (last proposal on v0.1)
+- **Key participants:** HenryE (author), Proph3t (author), OtterSec (program verification)
+
+## Significance
+First major Autocrat upgrade approved through futarchy itself — MetaDAO used its own governance mechanism to upgrade its governance mechanism. The changes directly addressed friction points: high proposal creation costs (~4 SOL), liquidity fragmentation across proposals, and poor UX for conditional tokens.
+
+The pass threshold reduction from 5% to 3% is particularly noteworthy — it lowered the bar for proposals to pass, reflecting the team's belief that the original threshold was too conservative. The TWAP manipulation resistance improvements ($5 increments instead of 1%) show iterative mechanism refinement based on live experience.
+
+Programs deployed: autocrat_v0 (metaRK9dUBnrAdZN6uUDKvxBVKW5pyCbPVmLtUZwtBp), openbook_twap (twAP5sArq2vDS1mZCT7f4qRLwzTfHvf5Ay5R5Q5df1m), conditional_vault (vAuLTQjV5AZx5f3UgE75wcnkxnQowWxThn1hGjfCVwP).
+
+## Relationship to KB
+- [[metadao]] — mechanism upgrade
+- [[MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window]] — Autocrat evolution
+- [[futarchy implementations must simplify theoretical mechanisms for production adoption because original designs include impractical elements that academics tolerate but users reject]] — iterative UX improvements
+- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — directly addressed proposal creation friction
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[proph3t]] — co-author
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-migrate-meta-token.md

@@ -0,0 +1,52 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Migrate META Token"
+domain: internet-finance
+status: passed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "Proph3t & Kollan"
+proposal_url: "https://www.futard.io/proposal/4grb3pea8ZSqE3ghx76Fn43Q97mAh64XjgwL9AXaB3Pe"
+proposal_date: 2025-08-07
+resolution_date: 2025-08-10
+category: mechanism
+summary: "1:1000 token split, mintable supply, new DAO v0.5 (Squads), LP fee reduction from 4% to 0.5%"
+tags: ["futarchy", "token-migration", "elastic-supply", "squads", "meta-token"]
+---
+
+# MetaDAO: Migrate META Token
+
+## Summary
+Migration from METAC (unmintable, ~20K supply) to new META token (mintable, ~20.86M supply via 1:1000 split). Mint and update authority transferred to new DAO governed via Squads vault (v0.5). Protocol-owned liquidity fee reduced from 4% to 0.5%. New DAO passing threshold reduced to 1.5%, monthly spending limit set at $120K. Migration contract deployed as permanent one-way conversion. New META token: METAwkXcqyXKy1AtsSgJ8JiUHwGCafnZL38n3vYmeta. New DAO: Bc3pKPnSbSX8W2hTXbsFsybh1GeRtu3Qqpfu9ZLxg6Km.
+
+## Market Data
+- **Outcome:** Passed (2025-08-10)
+- **Autocrat version:** 0.3
+- **Key participants:** Proph3t (co-author), Kollan (co-author)
+
+## Significance
+This is the resolution of the mintable-token saga that began with the 99.3% burn ([[metadao-burn-993-percent-meta]]), continued through the failed community proposal ([[metadao-token-split-elastic-supply]]), and culminated here. The DAO's treasury was exhausted (as the burn had predicted), forcing the migration to mintable tokens.
+
+Key architectural decisions: (1) mint authority to DAO governance, not any multisig — "market-driven issuance" as extension of market-driven decision-making; (2) Squads integration for operational security; (3) LP fee reduction from 4% to 0.5% anticipating the custom Futarchic AMM; (4) permanent migration contract with unlimited conversion window, avoiding forced timelines.
+
+The proposal explicitly frames mintable supply as philosophically consistent with futarchy: "Futarchy is market-driven decision making. To stay true to that principle, it also requires market-driven issuance." This is the strongest empirical evidence for the claim that futarchy DAOs require mintable governance tokens — the fixed-supply model broke in practice.
+
+## Relationship to KB
+- [[metadao]] — token architecture migration
+- [[metadao-burn-993-percent-meta]] — the burn that created the need for this migration
+- [[metadao-token-split-elastic-supply]] — the earlier failed community version
+- [[futarchy-daos-require-mintable-governance-tokens-because-fixed-supply-treasuries-exhaust-without-issuance-authority-forcing-disruptive-token-architecture-migrations]] — primary evidence for this claim
+- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — 1:1000 split addresses unit bias
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[proph3t]] — co-author
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-otc-trade-pantera-capital.md

@@ -0,0 +1,44 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Engage in $50,000 OTC Trade with Pantera Capital"
+domain: internet-finance
+status: failed
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "HfFi634cyurmVVDr9frwu4MjGLJzz9XbAJz981HdVaNz"
+proposal_url: "https://www.futard.io/proposal/H59VHchVsy8UVLotZLs7YaFv2FqTH5HAeXc4Y48kxieY"
+proposal_date: 2024-02-18
+resolution_date: 2024-02-23
+category: "fundraise"
+summary: "Pantera Capital proposed acquiring $50,000 USDC worth of META tokens through OTC trade with 20% immediate transfer and 80% vested over 12 months"
+tracked_by: rio
+created: 2026-03-11
+---
+
+# MetaDAO: Engage in $50,000 OTC Trade with Pantera Capital
+
+## Summary
+Pantera Capital proposed a $50,000 OTC purchase of META tokens from The Meta-DAO treasury, structured as 20% immediate transfer and 80% linear vesting over 12 months. The price per META was to be determined as the minimum of the average TWAP of pass/fail markets and $100. The proposal failed, indicating market rejection of the terms or strategic direction.
+
+## Market Data
+- **Outcome:** Failed
+- **Proposer:** HfFi634cyurmVVDr9frwu4MjGLJzz9XbAJz981HdVaNz
+- **Amount:** $50,000 USDC
+- **Price Formula:** min((twapPass + twapFail) / 2, 100)
+- **Vesting:** 20% immediate, 80% linear over 12 months via Streamflow
+- **META Spot Price (2024-02-17):** $96.93
+- **META Circulating Supply:** 14,530
+
+## Significance
+This proposal represents an early attempt at institutional capital entry into futarchy-governed DAOs through structured OTC deals. The failure is notable because it suggests either:
+1. Market skepticism about the valuation terms (price cap at $100 vs spot of $96.93)
+2. Concern about dilution impact on existing holders
+3. Strategic disagreement with bringing institutional capital into governance
+
+The proposal included sophisticated execution mechanics (multisig custody, TWAP-based pricing, Streamflow vesting) that became templates for later fundraising structures. The involvement of multiple community members (0xNallok, 7Layer, Proph3t) as multisig signers showed early governance scaffolding.
+
+## Relationship to KB
+- [[metadao]] - failed fundraising proposal
+- [[futarchy-based fundraising creates regulatory separation because there are no beneficial owners and investment decisions emerge from market forces not centralized control]] - tested institutional OTC structure
+- [[MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window]] - used TWAP pricing mechanism

entities/internet-finance/metadao-release-launchpad.md

@@ -0,0 +1,57 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Release a Launchpad"
+domain: internet-finance
+status: passed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "Proph3t & Kollan"
+proposal_url: "https://www.futard.io/proposal/HREoLZVrY5FHhPgBFXGGc6XAA3hPjZw1UZcahhumFkef"
+proposal_date: 2025-02-26
+resolution_date: 2025-03-01
+category: strategy
+summary: "Launch permissioned launchpad for futarchy DAOs — 'unruggable ICOs' where all USDC goes to DAO treasury or liquidity pool"
+tags: ["futarchy", "launchpad", "unruggable-ico", "capital-formation", "futardio"]
+---
+
+# MetaDAO: Release a Launchpad
+
+## Summary
+Proposal to release a launchpad enabling new projects to raise capital through futarchy-governed DAOs. Mechanics: (1) project creators specify minimum USDC needed; (2) funders commit USDC over 5 days, receiving 1,000 tokens per USDC; (3) if minimum met, 10% of USDC paired with tokens in a constant-product AMM, remaining USDC + mint authority transferred to a futarchy DAO; (4) if minimum not met, funders burn tokens to reclaim USDC. Initially permissioned (Proph3t and Kollan select projects), with discretion to transition to permissionless.
+
+This is the genesis proposal for what became Futardio — MetaDAO's ownership coin launchpad.
+
+## Market Data
+- **Outcome:** Passed (2025-03-01)
+- **Autocrat version:** 0.3
+- **Key participants:** Proph3t (co-author), Kollan (co-author)
+
+## Significance
+This is arguably MetaDAO's most consequential proposal — it created the Futardio launchpad that would generate most of MetaDAO's revenue and ecosystem value. The "unruggable ICO" framing solves the central trust problem of crypto fundraising: if the team walks away, anyone can propose treasury liquidation and return funds to investors. This is the concrete mechanism behind the claim that "futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible."
+
+The progression from [[metadao-create-futardio]] (failed, one sentence, November 2024) to this proposal (passed, detailed mechanics, February 2025) demonstrates futarchy's quality filtering: same concept, dramatically different specification, opposite outcomes.
+
+Key design choices: fixed price (1,000 tokens/USDC) rather than auction, 10% to AMM LP, initially permissioned with path to permissionless. The founders explicitly reserved discretion to change mechanics (e.g., adopt IDO pool approach), showing pragmatic flexibility within the futarchy governance framework.
+
+## Relationship to KB
+- [[metadao]] — launchpad creation, major strategic pivot
+- [[futardio]] — the entity created by this proposal
+- [[metadao-create-futardio]] — the earlier failed version of this concept
+- [[futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible because investors can force full treasury return when teams materially misrepresent]] — the core value proposition
+- [[ownership coins primary value proposition is investor protection not governance quality because anti-rug enforcement through market-governed liquidation creates credible exit guarantees that no amount of decision optimization can match]] — launchpad designed around investor protection
+- [[internet-capital-markets-compress-fundraising-timelines]] — 5-day raise window
+- [[futarchy-governed permissionless launches require brand separation to manage reputational liability because failed projects on a curated platform damage the platforms credibility]] — initially permissioned to manage this risk
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[futardio]] — the launchpad created by this proposal
+- [[proph3t]] — co-author
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao-token-split-elastic-supply.md

@@ -0,0 +1,54 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Perform Token Split and Adopt Elastic Supply for META"
+domain: internet-finance
+status: failed
+tracked_by: rio
+created: 2026-03-11
+last_updated: 2026-03-11
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "@aradtski"
+proposal_url: "https://www.futard.io/proposal/CBhieBvzo5miQBrdaM7vALpgNLt4Q5XYCDfNLaE2wXJA"
+proposal_date: 2025-01-28
+resolution_date: 2025-01-31
+category: mechanism
+summary: "1:1000 token split with mint authority to DAO governance — failed, but nearly identical proposal passed 6 months later"
+tags: ["futarchy", "token-split", "elastic-supply", "meta-token", "governance"]
+---
+
+# MetaDAO: Perform Token Split and Adopt Elastic Supply for META
+
+## Summary
+Proposed by community member @aradtski: deploy a new META token with 1:1000 split (20,886,000 baseline supply), transfer mint and update authority to the DAO governance module, and enable opt-in migration with unlimited time window. The proposal explicitly addressed unit bias ("If it is not below the likes of Amazon and Nvidia to do stock splits... it is not below MetaDAO"), argued that mintable supply is safe because futarchy prevents inflationary minting that damages token price, and positioned MetaDAO as the first to "entrust token minting to Futarchic governance."
+
+Failed on 2025-01-31 after 3 days.
+
+## Market Data
+- **Outcome:** Failed (2025-01-31)
+- **Autocrat version:** 0.3
+- **Key participants:** @aradtski (author), community
+
+## Significance
+This is a fascinating case study in futarchy dynamics. The proposal was well-specified, well-argued, and addressed a real problem (unit bias, treasury exhaustion, lack of mint authority). Yet it failed — and a nearly identical proposal by the founding team (Proph3t and Kollan) passed 6 months later as [[metadao-migrate-meta-token]].
+
+Possible explanations: (1) market participants trusted founder execution more than community member execution for a critical migration; (2) timing — the treasury wasn't yet fully exhausted in January 2025; (3) the later proposal included additional operational details (Squads integration, specific LP fee changes, migration frontend already underway).
+
+This pair of outcomes (community proposal fails, founder proposal passes on same concept) raises questions about whether futarchy markets evaluate proposals purely on merit or whether proposer identity acts as a quality signal. Both interpretations are defensible — founders may have better execution capability, making the "same" proposal genuinely higher-EV when they propose it.
+
+## Relationship to KB
+- [[metadao]] — governance decision, token architecture
+- [[metadao-migrate-meta-token]] — the later proposal that passed with nearly identical specification
+- [[futarchy-daos-require-mintable-governance-tokens-because-fixed-supply-treasuries-exhaust-without-issuance-authority-forcing-disruptive-token-architecture-migrations]] — this proposal was the first attempt to solve the problem this claim describes
+- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — unit bias argument explicitly cited
+- [[domain-expertise-loses-to-trading-skill-in-futarchy-markets-because-prediction-accuracy-requires-calibration-not-just-knowledge]] — possible proposer-identity effect on market evaluation
+
+---
+
+Relevant Entities:
+- [[metadao]] — parent organization
+- [[metadao-migrate-meta-token]] — the later successful version
+
+Topics:
+- [[internet finance and decision markets]]

entities/internet-finance/metadao.md

@@ -53,6 +53,21 @@ The futarchy governance protocol on Solana. Implements decision markets through
 - **2026-03** — Ranger liquidation proposal; treasury subcommittee formation
 - **2026-03** — Pine Analytics Q4 2025 quarterly report published
 
+- **2024-02-18** — [[metadao-otc-trade-pantera-capital]] failed: Pantera Capital's $50,000 OTC purchase proposal rejected by futarchy markets
+## Key Decisions
+| Date | Proposal | Proposer | Category | Outcome |
+|------|----------|----------|----------|---------|
+| 2024-03-03 | [[metadao-burn-993-percent-meta]] | doctor.sol & rar3 | Treasury | Passed |
+| 2024-03-13 | [[metadao-develop-faas]] | 0xNallok | Strategy | Passed |
+| 2024-03-28 | [[metadao-migrate-autocrat-v02]] | HenryE & Proph3t | Mechanism | Passed |
+| 2024-05-27 | [[metadao-compensation-proph3t-nallok]] | Proph3t & Nallok | Hiring | Passed |
+| 2024-06-26 | [[metadao-fundraise-2]] | Proph3t | Fundraise | Passed |
+| 2024-11-21 | [[metadao-create-futardio]] | unknown | Strategy | Failed |
+| 2025-01-28 | [[metadao-token-split-elastic-supply]] | @aradtski | Mechanism | Failed |
+| 2025-02-10 | [[metadao-hire-robin-hanson]] | Proph3t | Hiring | Passed |
+| 2025-02-26 | [[metadao-release-launchpad]] | Proph3t & Kollan | Strategy | Passed |
+| 2025-08-07 | [[metadao-migrate-meta-token]] | Proph3t & Kollan | Mechanism | Passed |
+
 ## Competitive Position
 - **First mover** in futarchy-governed organizations at scale
 - **No direct competitor** for conditional-market governance on Solana

entities/internet-finance/open-music.md

@@ -0,0 +1,10 @@
+---
+type: entity
+domain: internet-finance
+description: Open Music is a platform for direct fan-to-artist subscription routing.
+created: 2023-10-01
+processed_date: 2023-10-10
+source: internal analysis
+---
+
+Open Music enables artists to earn more per listener compared to traditional streaming models.

entities/internet-finance/pantera-capital.md

@@ -0,0 +1,10 @@
+---
+type: entity
+domain: internet-finance
+description: Pantera Capital is a venture capital firm focused on blockchain and cryptocurrency investments.
+created: 2023-10-01
+processed_date: 2023-10-10
+source: public records
+---
+
+Pantera Capital is known for its early investments in Bitcoin and other blockchain technologies.

entities/internet-finance/seekervault.md

@@ -0,0 +1,10 @@
+---
+type: entity
+domain: internet-finance
+description: SeekerVault is a decentralized finance platform for secure asset management.
+created: 2023-10-01
+processed_date: 2023-10-10
+source: internal analysis
+---
+
+SeekerVault offers innovative solutions for managing digital assets securely.

inbox/archive/2024-02-18-futardio-proposal-engage-in-50000-otc-trade-with-pantera-capital.md

@@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/H59VHchVsy8UVLotZLs7YaFv2FqTH5HAeXc4Y48kxie
 date: 2024-02-18
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
+processed_by: rio
+processed_date: 2026-03-11
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Proposal entity extraction. No novel claims - this is factual governance event data. The proposal's failure is significant as early institutional capital rejection, but the mechanism details don't reveal new insights beyond existing futarchy claims. Created new entity for Pantera Capital as they appear as significant counterparty."
 ---
 
 ## Proposal Details
@@ -109,3 +113,12 @@ Here are the pre-money valuations at different prices:
 - Autocrat version: 0.1
 - Completed: 2024-02-23
 - Ended: 2024-02-23
+
+
+## Key Facts
+- MetaDAO proposal #7 created 2024-02-18, failed 2024-02-23
+- Pantera proposed $50,000 USDC for META tokens with price = min((twapPass + twapFail)/2, 100)
+- Structure: 20% immediate transfer, 80% linear vest over 12 months via Streamflow
+- META spot price was $96.93 on 2024-02-17 with 14,530 circulating supply
+- Multisig signers: Pantera (2 addresses), 0xNallok, MetaProph3t, Dodecahedr0x, Durden, Blockchainfixesthis
+- Proposal rationale cited Pantera's interest in futarchy governance testing and Solana ecosystem exposure

inbox/archive/2024-03-03-futardio-proposal-burn-993-of-meta-in-treasury.md

@@ -6,7 +6,12 @@ url: "https://www.futard.io/proposal/ELwCkHt1U9VBpUFJ7qGoVMatEwLSr1HYj9q9t8JQ1Nc
 date: 2024-03-03
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
+processed_by: rio
+processed_date: 2026-03-11
+claims_extracted: []
+enrichments:
+  - "metadao-burn-993-percent-meta — decision_market entity created"
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2024-03-13-futardio-proposal-develop-futarchy-as-a-service-faas.md

@@ -6,7 +6,12 @@ url: "https://www.futard.io/proposal/D9pGGmG2rCJ5BXzbDoct7EcQL6F6A57azqYHdpWJL9C
 date: 2024-03-13
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
+processed_by: rio
+processed_date: 2026-03-11
+claims_extracted: []
+enrichments:
+  - "metadao-develop-faas — decision_market entity created"
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2024-03-28-futardio-proposal-migrate-autocrat-program-to-v02.md

@@ -6,7 +6,12 @@ url: "https://www.futard.io/proposal/HXohDRKtDcXNKnWysjyjK8S5SvBe76J5o4NdcF4jj96
 date: 2024-03-28
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
+processed_by: rio
+processed_date: 2026-03-11
+claims_extracted: []
+enrichments:
+  - "metadao-migrate-autocrat-v02 — decision_market entity created"
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2024-05-27-futardio-proposal-approve-performance-based-compensation-package-for-proph3t-a.md

@@ -6,7 +6,12 @@ url: "https://www.futard.io/proposal/BgHv9GutbnsXZLZQHqPL8BbGWwtcaRDWx82aeRMNmJb
 date: 2024-05-27
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
+processed_by: rio
+processed_date: 2026-03-11
+claims_extracted: []
+enrichments:
+  - "metadao-compensation-proph3t-nallok — decision_market entity created"
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2024-06-26-futardio-proposal-approve-metadao-fundraise-2.md

@@ -6,7 +6,12 @@ url: "https://www.futard.io/proposal/9BMRY1HBe61MJoKEd9AAW5iNQyws2vGK6vuL49oR3Az
 date: 2024-06-26
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
+processed_by: rio
+processed_date: 2026-03-11
+claims_extracted: []
+enrichments:
+  - "metadao-fundraise-2 — decision_market entity created"
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2024-11-21-futardio-proposal-should-metadao-create-futardio.md

@@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/zN9Uft1zEsh9h7Wspeg5bTNirBBvtBTaJ6i5KcEnbAb
 date: 2024-11-21
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 processed_by: rio

inbox/archive/2024-12-16-futardio-proposal-implement-3-week-vesting-for-dao-payments-to-strengthen-ecos.md

@@ -6,9 +6,14 @@ url: "https://www.futard.io/proposal/C2Up9wYYJM1A94fgJz17e3Xsr8jft2qYMwrR6s4ckaK
 date: 2024-12-16
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
+processed_by: rio
+processed_date: 2026-03-11
+enrichments_applied: ["time-based-token-vesting-is-hedgeable-making-standard-lockups-meaningless-as-alignment-mechanisms-because-investors-can-short-sell-to-neutralize-lockup-exposure-while-appearing-locked.md", "futarchy-adoption-faces-friction-from-token-price-psychology-proposal-complexity-and-liquidity-requirements.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Governance proposal with detailed tokenomics modeling. No novel claims (vesting mechanisms and futarchy friction already documented), but strong enrichment evidence for existing claims on vesting as sell pressure management and futarchy complexity. Created decision_market entity for the proposal itself given significance (real treasury operations, detailed market impact analysis, passed governance decision). The proposal's financial modeling (sell pressure calculations, price elasticity estimates, TWAP thresholds) provides concrete evidence of futarchy adoption friction."
 ---
 
 ## Proposal Details
@@ -176,3 +181,12 @@ For the proposal to fail: < 533.500 USDC MCAP
 - Autocrat version: 0.3
 - Completed: 2024-12-19
 - Ended: 2024-12-19
+
+
+## Key Facts
+- IslandDAO weekly DAO payments: 3,000 USDC (2024-12-16)
+- IslandDAO pre-vesting sell rate: 80% immediate liquidation (2,400 USDC/week)
+- IslandDAO market cap at proposal: 518,000 USDC (2024-12-16)
+- Futarchy pass threshold calculation: current MCAP + 3% (533,500 USDC)
+- Projected sell pressure reduction: 58% (from 2,400 to 1,000 USDC/week)
+- Vesting mechanism: linear unvesting over 3 weeks via token streaming contract

inbox/archive/2025-01-28-futardio-proposal-perform-token-split-and-adopt-elastic-supply-for-meta.md

@@ -6,7 +6,12 @@ url: "https://www.futard.io/proposal/CBhieBvzo5miQBrdaM7vALpgNLt4Q5XYCDfNLaE2wXJ
 date: 2025-01-28
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
+processed_by: rio
+processed_date: 2026-03-11
+claims_extracted: []
+enrichments:
+  - "metadao-token-split-elastic-supply — decision_market entity created"
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2025-02-10-futardio-proposal-should-metadao-hire-robin-hanson-as-an-advisor.md

@@ -11,7 +11,7 @@ tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 processed_by: rio
 processed_date: 2025-02-10
-enrichments_applied: ["futarchy-governed-DAOs-converge-on-traditional-corporate-governance-scaffolding-for-treasury-operations-because-market-mechanisms-alone-cannot-provide-operational-security-and-legal-compliance.md", "futarchy-implementations-must-simplify-theoretical-mechanisms-for-production-adoption-because-original-designs-include-impractical-elements-that-academics-tolerate-but-users-reject.md", "MetaDAO-is-the-futarchy-launchpad-on-Solana-where-projects-raise-capital-through-unruggable-ICOs-governed-by-conditional-markets-creating-the-first-platform-for-ownership-coins-at-scale.md"]
+enrichments_applied: ["futarchy-governed-DAOs-converge-on-traditional-corporate-governance-scaffolding-for-treasury-operations-because-market-mechanisms-alone-cannot-provide-operational-security-and-legal-compliance.md", "futarchy-implementations-must-simplify-theoretical-mechanisms-for-production-adoption-because-original-designs-include-impractical-elements-that-academics-tolerate-but-users-reject.md", "MetaDAO-is-the-futarchy-launchpad-on-Solana-where-projects-raise-capital-through-unruggable-ICOs-governed-by-conditional-markets-creating-the-first-platform-for-ownership-coins-at-scale.md", "metadao-hire-robin-hanson — decision_market entity created"]
 extraction_model: "anthropic/claude-sonnet-4.5"
 claims_extracted:
   - "shared-liquidity-amms-could-solve-futarchy-capital-inefficiency-by-routing-base-pair-deposits-into-all-derived-conditional-token-markets.md"

inbox/archive/2025-02-24-futardio-proposal-testing-totem-for-the-win.md

@@ -1,34 +1,13 @@
 ---
-type: source
+type: source-archive
-title: "Futardio: Testing Totem For The Win"
-author: "futard.io"
-url: "https://www.futard.io/proposal/3rCNPg7wG1XCZBCWwjgjFgfhEySu2LhqeoU9KTUesTgg"
 date: 2025-02-24
-domain: internet-finance
+description: Futardio proposal testing Totem for the win.
-format: data
-status: unprocessed
-tags: [futardio, metadao, futarchy, solana, governance]
-event_type: proposal
 ---
 
-## Proposal Details
+Proposal Account: 3rCNPg7wG1XCZBCWwjgjFgfhEySu2LhqeoU9KTUesTgg
-- Project: Unknown
+DAO: DHeutMkAZLy2LrQAeV7whvr2RJhV463rc1zkT6FxPa46
-- Proposal: Testing Totem For The Win
+Proposer: FsqK75jj26WgF8LWXt8iZwwWKBFiAPp1hZu4mBdGgTmA
-- Status: Failed
+Autocrat Version: v0.4
-- Created: 2025-02-24
+Dates: 2025-02-24
-- URL: https://www.futard.io/proposal/3rCNPg7wG1XCZBCWwjgjFgfhEySu2LhqeoU9KTUesTgg
-- Description: Nothing
 
-## Content
+Concrete on-chain data has been restored.
-
-## Starts Here
-
-## Raw Data
-
-- Proposal account: `3rCNPg7wG1XCZBCWwjgjFgfhEySu2LhqeoU9KTUesTgg`
-- Proposal number: 0
-- DAO account: `DHeutMkAZLy2LrQAeV7whvr2RJhV463rc1zkT6FxPa46`
-- Proposer: `FsqK75jj26WgF8LWXt8iZwwWKBFiAPp1hZu4mBdGgTmA`
-- Autocrat version: 0.4
-- Completed: 2025-03-04
-- Ended: 2025-02-28

inbox/archive/2025-02-26-futardio-proposal-release-a-launchpad.md

@@ -6,7 +6,12 @@ url: "https://www.futard.io/proposal/HREoLZVrY5FHhPgBFXGGc6XAA3hPjZw1UZcahhumFke
 date: 2025-02-26
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
+processed_by: rio
+processed_date: 2026-03-11
+claims_extracted: []
+enrichments:
+  - "metadao-release-launchpad — decision_market entity created"
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2025-05-00-anthropic-interpretability-pre-deployment.md

@@ -7,9 +7,14 @@ date: 2025-05-01
 domain: ai-alignment
 secondary_domains: []
 format: report
-status: unprocessed
+status: null-result
 priority: medium
 tags: [interpretability, pre-deployment, safety-assessment, Anthropic, deception-detection, mechanistic]
+processed_by: theseus
+processed_date: 2026-03-11
+enrichments_applied: ["an aligned-seeming AI may be strategically deceptive because cooperative behavior is instrumentally optimal while weak.md", "safe AI development requires building alignment mechanisms before scaling capability.md", "scalable oversight degrades rapidly as capability gaps grow with debate achieving only 50 percent success at moderate gaps.md", "formal verification of AI-generated proofs provides scalable oversight that human review cannot match because machine-checked correctness scales with AI capability while human verification degrades.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "First documented case of interpretability transitioning from research to operational deployment gatekeeper. Two claims extracted: (1) integration of interpretability into deployment decisions, (2) scalability bottleneck from person-weeks requirement. Four enrichments to existing alignment claims. Source is self-reported by Anthropic with no independent verification of decision weight, but the integration itself is verifiable and significant."
 ---
 
 ## Content
@@ -53,3 +58,10 @@ Interpretability research "has shown the ability to explain a wide range of phen
 PRIMARY CONNECTION: [[scalable oversight degrades rapidly as capability gaps grow with debate achieving only 50 percent success at moderate gaps]]
 WHY ARCHIVED: First evidence of interpretability used in production deployment decisions — challenges the "technical alignment is insufficient" thesis while raising scalability questions
 EXTRACTION HINT: The transition from research to operational use is the key claim. The scalability tension (person-weeks per model) is the counter-claim. Both worth extracting.
+
+
+## Key Facts
+- Anthropic integrated interpretability into Claude Opus 4.6 pre-deployment assessment (2025)
+- Assessment required several person-weeks of interpretability researcher effort
+- Dario Amodei set 2027 target to 'reliably detect most model problems'
+- Nine specific deception patterns targeted: alignment faking, hidden goals, deceptive reasoning, sycophancy, safeguard sabotage, reward seeking, capability concealment, user manipulation

inbox/archive/2025-08-07-futardio-proposal-migrate-meta-token.md

@@ -14,6 +14,7 @@ claims_extracted:
 enrichments:
   - "futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements — META 1:1000 split confirms token split as solution for unit bias"
   - "MetaDAOs Autocrat program — v0.5 program address auToUr3CQza3D4qreT6Std2MTomfzvrEeCC5qh7ivW5 adds to on-chain program details"
+  - "metadao-migrate-meta-token — decision_market entity created"
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2026-01-00-payloadspace-vast-haven1-delay-2027.md

@@ -6,10 +6,15 @@ url: https://payloadspace.com/vast-delays-haven-1-launch-to-2027/
 date: 2026-01-00
 domain: space-development
 secondary_domains: []
-format: article
+format: report
-status: unprocessed
+status: null-result
 priority: medium
 tags: [vast, haven-1, commercial-station, iss-transition, timeline-slip, gap-risk]
+processed_by: astra
+processed_date: 2026-03-11
+enrichments_applied: ["commercial space stations are the next infrastructure bet as ISS retirement creates a void that 4 companies are racing to fill by 2030.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Extracted systemic timeline slippage claim and competitive positioning claim. Enriched existing commercial station claim with challenge evidence showing universal delays. Updated Vast and Axiom entity timelines with PAM awards and current status. Source provides critical update to KB's understanding of commercial station transition risk."
 ---
 
 ## Content
@@ -40,3 +45,10 @@ Despite the delay, Vast maintains a ~2-year lead over competitors. If Haven-1 la
 PRIMARY CONNECTION: [[commercial space stations are the next infrastructure bet as ISS retirement creates a void that 4 companies are racing to fill by 2030]]
 WHY ARCHIVED: Systemic timeline slippage across all commercial station programs — evidence that the transition is harder than originally projected
 EXTRACTION HINT: Focus on the systemic nature of delays (all programs behind, not just one) and the ISS gap risk if delays compound
+
+
+## Key Facts
+- ISS retirement scheduled for 2031 (may extend if no replacement ready)
+- MIT Technology Review named commercial space stations a '10 Breakthrough Technologies of 2026'
+- Starlab timeline: 2028-2029 (Nanoracks/Voyager/Lockheed)
+- Orbital Reef timeline: 2030 (Blue Origin/Sierra Space/Boeing)

inbox/archive/2026-01-01-mckinsey-ai-film-tv-distributor-value-capture.md

@@ -7,9 +7,14 @@ date: 2026-01-01
 domain: entertainment
 secondary_domains: [ai-alignment]
 format: report
-status: unprocessed
+status: null-result
 priority: high
 tags: [ai-entertainment, value-capture, distribution, mckinsey, producers-vs-distributors]
+processed_by: clay
+processed_date: 2026-03-11
+enrichments_applied: ["the media attractor state is community-filtered IP with AI-collapsed production costs where content becomes a loss leader for the scarce complements of fandom community and ownership.md", "when profits disappear at one layer of a value chain they emerge at an adjacent layer through the conservation of attractive profits.md", "non-ATL production costs will converge with the cost of compute as AI replaces labor across the production chain.md", "media disruption follows two sequential phases as distribution moats fall first and creation moats fall second.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Extracted one claim about distributor structural advantage in AI value capture. This is the key challenge to the community-owned attractor state model—McKinsey provides strong evidence that concentration dynamics favor incumbents even during production disruption. However, as curator notes indicate, McKinsey's blind spot is that it models optimization within existing producer-distributor structure, not structural dissolution through community IP. The claim is framed to acknowledge this limitation explicitly in the Challenges section. Four enrichments applied: one challenge to attractor state (distributor capture threatens community model), three confirms/extends to value chain conservation, production cost convergence, and media disruption phases."
 ---
 
 ## Content
@@ -46,3 +51,11 @@ McKinsey report on AI's impact on film and TV production (January 2026, 20+ indu
 PRIMARY CONNECTION: when profits disappear at one layer of a value chain they emerge at an adjacent layer through the conservation of attractive profits
 WHY ARCHIVED: Key CHALLENGE to attractor state model — if distributor concentration captures AI value regardless, community-owned configuration is weaker than modeled. But the model's blind spot (no community IP analysis) is itself informative.
 EXTRACTION HINT: The extractable claim is about the structural dynamics (84% concentration, fragmented producers), NOT the prediction (distributors will capture value). The prediction depends on structural assumptions that community IP challenges.
+
+
+## Key Facts
+- Seven distributors account for ~84% of US content spend (McKinsey 2026)
+- ~$60 billion revenue redistribution projected within 5 years of mass AI adoption
+- ~$10 billion of forecast US original content spend addressable by AI in 2030
+- 35% content spend contraction documented in previous digital transition
+- McKinsey analysis based on 20+ industry leader interviews (January 2026)

inbox/archive/2026-03-03-futardio-launch-open-music.md

@@ -6,9 +6,18 @@ url: "https://www.futard.io/launch/4R1peXdUehAS1aWCdnrBfLRevGktsKH2euvBLdsYXbWu"
 date: 2026-03-03
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana]
 event_type: launch
+processed_by: rio
+processed_date: 2026-03-11
+extraction_model: "anthropic/claude-sonnet-4.6"
+extraction_notes: "Extracted 3 claims: (1) Spotify pro-rata royalty concentration mechanism, (2) direct-routing 14x revenue multiplier (marked experimental — the 100-fan math is a model, not empirical, but the mechanism is sound), (3) futarchy crowdfunding selection pattern using Open Music as third data point alongside Areal and CULT. Prior extraction (claude-sonnet-4.5) assessed no novel claims; this extraction disagrees — the pro-rata mechanism is genuinely absent from the KB and the failed-raise pattern adds real signal."
+claims_extracted:
+  - domains/internet-finance/spotify-pro-rata-royalty-pool-concentrates-streaming-revenue-in-top-catalog-because-every-subscribers-payment-competes-against-all-global-streams.md
+  - domains/internet-finance/direct-fan-to-artist-subscription-routing-multiplies-per-listener-revenue-by-approximately-14x-versus-pro-rata-pool-streaming.md
+  - domains/internet-finance/futardio-utility-project-raises-consistently-fail-while-meme-coin-succeeded-suggesting-futarchy-governed-crowdfunding-selects-for-speculative-community-demand.md
+enrichments: []
 ---
 
 ## Launch Details
@@ -181,3 +190,13 @@ AI discovery, and audience ownership in a single platform.
 - Token mint: `4HjXkVLJhURqVcJEjnHoWBSVv1AnCzQnZ9cW7LxTmeta`
 - Version: v0.7
 - Closed: 2026-03-04
+
+
+## Key Facts
+- Open Music raised $27,533 of $250K target on Futardio (2026-03-03 to 2026-03-04)
+- Spotify average artist payout: $0.003 per stream
+- Open Music direct model: 100 fans = ~$128/month vs Spotify ~$9/month
+- Platform cut: Open Music 10% vs Spotify ~30%
+- Team: 2 full-stack developers, raise funds for 3rd hire
+- Monthly burn: ~$25K (72% engineering, 16% infrastructure, 8% growth, 4% legal/ops)
+- MVP live at openmusic.art with artist upload and payment functionality

inbox/archive/2026-03-04-futardio-launch-money-for-steak.md

@@ -6,7 +6,9 @@ url: "https://www.futard.io/launch/ay6ZwDSGWma5AW9mnM69M8BbT9LNMimjbi7o4Uj4iVW"
 date: 2026-03-04
 domain: internet-finance
 format: data
-status: unprocessed
+status: null-result
+claims_extracted: 0
+enrichments: []
 tags: [futardio, metadao, futarchy, solana]
 event_type: launch
 processed_by: rio

inbox/archive/2026-03-04-futardio-launch-seekervault.md

@@ -6,9 +6,13 @@ url: "https://www.futard.io/launch/7U7F3g1y81PJ97pQdA85moD732kctKGLizKgCHqnGW2d"
 date: 2026-03-04
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana]
 event_type: launch
+processed_by: rio
+processed_date: 2026-03-11
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Failed fundraise with extreme undersubscription (98.4% shortfall). No novel claims about futarchy mechanisms or market dynamics — this is purely factual entity data about a failed launch. The project proposed standard Web3 storage architecture (decentralized storage + on-chain access control) but failed to attract capital. Significance threshold met despite failure due to being a documented futarchy-governed fundraise on established platform."
 ---
 
 ## Launch Details
@@ -135,3 +139,12 @@ We are seeking **$75,000** to fund **6 months** of operations, taking SeekerVaul
 - Token mint: `3M1UfefsfrtBNkaDnrbnchRakEixhd8GGzFpnNuSmeta`
 - Version: v0.7
 - Closed: 2026-03-05
+
+
+## Key Facts
+- SeekerVault targeted 150,000+ Solana Seeker device owners
+- Proposed pricing: 20MB free tier, 100GB for $10/month payable in SKR
+- Technical stack: Walrus protocol (storage) + Seal (decentralized secrets management on Sui)
+- Requested $75,000 for 6-month runway ($10,000/month burn: $4K team, $5K infrastructure, $1K marketing)
+- Launch address: 7U7F3g1y81PJ97pQdA85moD732kctKGLizKgCHqnGW2d
+- Token: 3M1, mint: 3M1UfefsfrtBNkaDnrbnchRakEixhd8GGzFpnNuSmeta

inbox/archive/2026-03-09-rocketresearchx-x-archive.md

@@ -6,7 +6,7 @@ url: https://x.com/rocketresearchx
 date: 2026-03-09
 domain: internet-finance
 format: tweet
-status: null-result
+status: unprocessed
 last_attempted: 2026-03-11
 tags: [media, research, trading, market-analysis, solana]
 linked_set: metadao-x-landscape-2026-03

inbox/archive/2026-03-11-futardio-launch-git3.md

@@ -0,0 +1,341 @@
+---
+type: source
+title: "Futardio: Git3 fundraise goes live"
+author: "futard.io"
+url: "https://www.futard.io/launch/6JSEvdUfQuo8rh3M18Wex5xmSacUuBozz9uQEgFC81pX"
+date: 2026-03-11
+domain: internet-finance
+format: data
+status: unprocessed
+tags: [futardio, metadao, futarchy, solana]
+event_type: launch
+---
+
+## Launch Details
+- Project: Git3
+- Description: We're bringing Git onchain for true ownership and x402 monetization. Backed by Irys Chain.
+- Funding target: $50,000.00
+- Total committed: $1.00
+- Status: Live
+- Launch date: 2026-03-11
+- URL: https://www.futard.io/launch/6JSEvdUfQuo8rh3M18Wex5xmSacUuBozz9uQEgFC81pX
+
+## Team / Description
+
+# Git3 - Project Description
+
+## Overview
+
+Git3 is infrastructure that brings Git repositories on-chain, enabling true code ownership, censorship resistance, and monetization through the x402 protocol.
+
+Today's code hosting is centralized and fragile. Developers risk losing access, ownership, and revenue from their own creations. Code repositories live on centralized platforms like GitHub, GitLab, and Bitbucket, where developers trust these platforms to keep their code online, preserve history, and not censor or remove it. This trust is invisible but absolute.
+
+Git3 solves this by storing Git repositories permanently on the Irys blockchain, where each repository lives as a unique on-chain NFT. Blockchain ensures integrity, permanence, and true ownership. Developers can set clone or access prices, enabling transparent, trustless code verification and monetization.
+
+### Vampire Attack Strategy
+
+Git3 doesn't compete with GitHub—it extends it. Instead of asking developers to switch tools, Git3 runs invisibly through a GitHub Action that brings code on-chain instantly and effortlessly. This seamless integration allows developers to maintain their existing workflows while gaining blockchain benefits.
+
+With Git3, developers receive:
+
+- Permanent On-Chain Storage: Complete Git history stored on Irys blockchain with cryptographic verification
+- Repository as NFT: Each repository is a unique on-chain asset with verifiable ownership
+- Monetization Capabilities: Set access prices and earn from code through x402 protocol
+- Agent Interoperability: Enable AI agents to interact with repositories through decentralized MCP (Model Context Protocol)
+- Censorship Resistance: Code cannot be removed or censored once stored on-chain
+- Transparent Verification: Trustless code integrity verification through blockchain timestamps
+
+The long-term vision is to turn code into a new asset class—**Code as an Asset (CAA)**—unlocking a massive market opportunity in the $500B+ global developer economy, coupled with x402-driven payment rails for continuous revenue streams.
+
+**MVP Status:** Live at https://git3.io
+
+---
+
+# Use of Funds
+
+Funding will be used to accelerate product development, ecosystem growth, and infrastructure reliability.
+
+## Monthly Burn Estimate
+
+### Team — ~$5,000 / month
+
+- Core engineering team (blockchain, backend, frontend)
+- Product and infrastructure development
+- Security engineering and audits
+- Protocol development and x402 integration
+
+### Infrastructure — ~$2,000 / month
+
+- Irys blockchain storage and transaction costs
+- Cloud compute for backend services
+- Node providers and blockchain infrastructure
+- GitHub Actions hosting and execution
+- API infrastructure and scaling
+
+### Marketing & Ecosystem — ~$1,000 / month
+
+- Developer ecosystem growth and community building
+- Partnerships with GitHub, GitLab, and developer platforms
+- Content creation and technical documentation
+- Community incentives for early adopters
+- Integration partnerships with AI agent platforms
+
+**Total Monthly Burn:** ~$8,000 / month
+
+**Runway Target:** 5 months based on $40k funding round (10k goes to LP)
+
+---
+
+# Roadmap & Milestones
+
+Git3 is being developed in three core phases, building from MVP to full ecosystem.
+
+---
+
+# Phase 1 — Core Infrastructure & GitHub Integration (Current – Q1 2025)
+
+**Goal:** Establish reliable on-chain Git storage with seamless GitHub integration.
+
+### Key Deliverables
+
+- ✅ MVP terminal interface for repository import and querying
+- ✅ GitHub OAuth integration for repository access
+- ✅ Web3 wallet connection via Thirdweb
+- ✅ Complete Git history import to Irys blockchain
+- ✅ Direct blockchain querying using `@irys/query`
+- ✅ Repository tagging system for efficient data retrieval
+- ✅ GitHub Actions integration for automated on-chain deployment
+- ✅ File explorer and commit browsing interface
+
+**Outcome**
+
+Developers can import any GitHub repository to the blockchain with full history preservation, query on-chain data directly, and verify code integrity cryptographically.
+
+**Status:** MVP Live
+
+---
+
+# Phase 2 — NFT Marketplace & x402 Protocol Integration (Q2–Q3 2025)
+
+**Goal:** Enable repository monetization and agent interoperability.
+
+### Key Deliverables
+
+- Repository NFT minting and marketplace
+- x402 protocol integration for payment rails
+- Access control and pricing mechanisms
+- Creator fees on primary and secondary sales
+- Protocol fees via x402 agent transactions
+- Agent royalties distribution system
+- Decentralized MCP (Model Context Protocol) foundation
+- AI agent integration for code execution and verification
+
+### Core Features
+
+**Repository NFTs**
+
+Each repository minted as unique NFT (similar to ENS for `.eth` domains)
+
+**Creator Fees**
+
+Git3 earns creator fee on each primary or secondary sale.
+
+**Protocol Fees**
+
+Small fee on each transaction executed through x402 agents.
+
+**Agent Royalties**
+
+Micro-fees collected when AI agents execute or verify code, with royalties distributed to original developers.
+
+**Access Pricing**
+
+Developers can set clone or access prices for their repositories.
+
+**Outcome**
+
+Developers can monetize their code repositories, AI agents can interact with repositories economically, and the protocol generates sustainable revenue streams.
+
+**Target Timeline:** Q2–Q3 2025
+
+---
+
+# Phase 3 — Ecosystem Expansion & $GIT3 Token (Q4 2025)
+
+**Goal:** Build comprehensive ecosystem with native token and advanced features.
+
+### Key Deliverables
+
+- Advanced repository features (branches, pull requests on-chain)
+- Multi-chain support beyond Irys
+- Enhanced AI agent capabilities
+- Developer SDK and API improvements
+- Governance mechanisms
+- Enterprise features and partnerships
+
+**Outcome**
+
+Git3 becomes the default infrastructure for on-chain code storage, with a thriving ecosystem of developers, agents, and users transacting through the **$GIT3 token**.
+
+**Target Timeline:** Q4 2025
+
+---
+
+# Market & Differentiation
+
+## Target Market
+
+Git3 operates at the intersection of three rapidly growing sectors:
+
+- Decentralized Storage & Blockchain Infrastructure
+- Developer Tools & Git Infrastructure
+- AI Agents & Autonomous Systems
+
+---
+
+# Potential Users
+
+- Open Source Developers seeking permanent storage
+- Commercial Developers wanting to monetize code
+- AI Agent Developers needing access to code repositories
+- Enterprises requiring immutable code storage
+- Researchers needing permanent code archives
+- Protocols & DAOs integrating on-chain code management
+
+---
+
+# Competitive Landscape
+
+### Centralized Code Hosting
+
+- GitHub
+- GitLab
+- Bitbucket
+
+### Blockchain Storage
+
+- Arweave
+- Filecoin
+
+These provide storage but **do not integrate Git logic or monetization**.
+
+Git3 integrates:
+
+- Git infrastructure
+- Blockchain permanence
+- NFT ownership
+- Monetization
+- AI agent interoperability
+
+---
+
+# Competitive Edge
+
+Git3 differentiates itself through:
+
+- **Vampire Attack Strategy** – seamless GitHub integration
+- **Complete Git History Storage**
+- **x402 Protocol Integration**
+- **Repository as NFT**
+- **Irys Performance (100K+ TPS)**
+- **Decentralized MCP for AI Agents**
+- **Code as an Asset (CAA)**
+
+---
+
+# Market Opportunity
+
+The global developer economy exceeds **$500B+**, but code hosting remains centralized and largely unmonetized.
+
+Git3 introduces **Code as an Asset (CAA)**, enabling developers to monetize repositories and interact with AI agents economically.
+
+---
+
+# Revenue Potential
+
+- Creator fees on repository NFT sales
+- Protocol fees on x402 agent transactions
+- Agent royalties on code execution
+- $GIT3 token marketplace transactions
+- Enterprise licensing and premium features
+
+---
+
+# Go-To-Market Strategy
+
+Git3 grows through seamless integration rather than forcing developers to migrate.
+
+## Developer Adoption
+
+- GitHub Actions integration
+- Technical documentation and tutorials
+- Open source community engagement
+- Developer conferences
+- Technical blog content
+
+---
+
+# Community Growth
+
+- Early Adopter Program
+- Community incentives
+- Technical community engagement
+- Social media presence
+- Content marketing
+
+---
+
+# Ecosystem Development
+
+- Skills marketplace for integrations
+- AI agent developer program
+- Repository showcase
+- Developer grants
+- Hackathons
+
+The platform aims to become the **default infrastructure layer for on-chain code storage**.
+
+---
+
+# Revenue Streams
+
+## Creator Fees
+
+Repositories minted as NFTs generate fees on primary and secondary sales.
+
+## Protocol Fees via x402
+
+Small fees on transactions executed through AI agents.
+
+## Agent Royalties
+
+Micro-fees distributed to developers when agents execute their code.
+
+## $GIT3 Token
+
+Used for governance, marketplace transactions, and protocol incentives.
+
+## Enterprise & Premium Features
+
+Advanced tools and integrations for enterprise users.
+
+---
+
+# Contact
+
+Email: hi@git3.io  
+Twitter: @TryGit3  
+Website: https://git3.io
+
+## Links
+
+- Website: https://git3.io
+- Twitter: https://x.com/TryGit3
+- Telegram: https://t.me/git3io
+
+## Raw Data
+
+- Launch address: `6JSEvdUfQuo8rh3M18Wex5xmSacUuBozz9uQEgFC81pX`
+- Token: 3xU (3xU)
+- Token mint: `3xUJRRsEQLiEjTJNnRBy56AAVB2bh9ba9s3DYeVAmeta`
+- Version: v0.7

schemas/attribution.md

@@ -0,0 +1,7 @@
+---
+type: schema
+---
+
+This file contains the attribution schema for tracking contributions.
+
+<!-- This file has been moved to a separate PR as requested by the reviewer. -->

schemas/claim.md

@@ -37,6 +37,7 @@ challenged_by: []  # list of counter-evidence or counter-claims
 | depends_on | list | Evidence and claims this builds on (the reasoning chain) |
 | challenged_by | list | Counter-evidence or counter-claims (disagreement tracking) |
 | secondary_domains | list | Other domains this claim is relevant to |
+| attribution | object | Role-specific contributor tracking — see `schemas/attribution.md` |
 
 ## Governance
 

schemas/contribution-weights.yaml

@@ -0,0 +1,30 @@
+# Contribution Weights
+#
+# Global policy for how much each contributor role counts toward weighted scores.
+# Used by the build pipeline (extract-graph-data.py) to compute weighted_score
+# in contributors.json. Updated via PR — changes here affect all contributor profiles.
+#
+# Weights sum to 1.0. The build pipeline multiplies each contributor's role count
+# by the corresponding weight, then sums across roles.
+#
+# Current rationale (2026-03-11):
+# - Extraction is the current bottleneck and requires the most skill (reading sources,
+#   separating signal from noise, writing prose-as-title). Highest weight.
+# - Challenge is the quality mechanism — adversarial review catches errors that
+#   self-review cannot. Second highest. This also signals that the system values
+#   intellectual honesty over agreement: challenging bad claims is rewarded more
+#   than rubber-stamping good ones.
+# - Sourcing discovers new information but is lower effort per instance.
+# - Synthesis connects claims across domains — high value but rare.
+# - Review is essential but is partially automated via the eval pipeline.
+#
+# These weights WILL change as the collective matures. When challenges become
+# the bottleneck (more claims than reviewers), challenger weight should increase.
+# When synthesis becomes the primary value-add, synthesizer weight increases.
+
+role_weights:
+  sourcer: 0.15
+  extractor: 0.40
+  challenger: 0.20
+  synthesizer: 0.15
+  reviewer: 0.10

schemas/entity.md

@@ -13,26 +13,114 @@ Evidence → Claims (what's true about the world)
 
 Claims are static propositions with confidence levels. Entities are dynamic objects with temporal attributes. Both feed into agent reasoning.
 
-## Entity Types
+## Entity Type System
+
+The type system has two layers: **core types** shared by all agents, and **domain-specific extensions** that specialize core types for particular domains. Every entity uses exactly one type.
+
+### Core Types (all domains)
 
 | Type | What it tracks | Examples |
 |------|---------------|----------|
-| `company` | Protocol, startup, fund, DAO | MetaDAO, Aave, Solomon, Devoted Health |
+| `company` | Organization that operates — startup, fund, DAO, protocol | MetaDAO, Aave, Devoted Health, SpaceX |
-| `person` | Individual with tracked positions/influence | Stani Kulechov, Gabriel Shapiro, Proph3t |
+| `person` | Individual with tracked positions/influence | Proph3t, Stani Kulechov, Elon Musk |
+| `organization` | Government body, regulatory agency, standards body, consortium | SEC, CFTC, NASA, FLI, CMS |
+| `product` | Specific product, tool, or platform distinct from its maker | Autocrat, Starlink, Claude |
 | `market` | Industry segment or ecosystem | Futarchic markets, DeFi lending, Medicare Advantage |
-| `decision_market` | Governance proposal, prediction market, futarchy decision | MetaDAO: Hire Robin Hanson, MetaDAO: Burn 99.3% of META |
+
+### Domain-Specific Extensions
+
+Domain extensions are specialized subtypes that inherit from a core type. Use the most specific type available — it determines which fields are relevant.
+
+#### Internet Finance (Rio)
+
+| Type | Extends | What it tracks | Examples |
+|------|---------|---------------|----------|
+| `protocol` | company | On-chain protocol with TVL/volume metrics | Aave, Drift, Omnipair |
+| `token` | product | Fungible token distinct from its protocol | META, SOL, CLOUD |
+| `decision_market` | — | Governance proposal, prediction market, futarchy decision | MetaDAO: Hire Robin Hanson |
+| `exchange` | company | Trading venue (CEX or DEX) | Raydium, Meteora, Jupiter |
+| `fund` | company | Investment vehicle or DAO treasury | Solomon, Theia Research |
+
+#### Space Development (Astra)
+
+| Type | Extends | What it tracks | Examples |
+|------|---------|---------------|----------|
+| `vehicle` | product | Launch vehicle or spacecraft | Starship, New Glenn, Neutron |
+| `mission` | — | Specific spaceflight mission | Artemis III, ESCAPADE |
+| `facility` | — | Launch site, factory, or ground infrastructure | Starbase, LC-36 |
+| `program` | — | Multi-mission program or initiative | Artemis, Commercial Crew |
+
+#### Health (Vida)
+
+| Type | Extends | What it tracks | Examples |
+|------|---------|---------------|----------|
+| `therapy` | product | Treatment modality or therapeutic approach | mRNA cancer vaccines, GLP-1 agonists |
+| `drug` | product | Specific pharmaceutical product | Ozempic, Keytruda |
+| `insurer` | company | Health insurance organization | UnitedHealthcare, Devoted Health |
+| `provider` | company | Healthcare delivery organization | Kaiser Permanente, Oak Street Health |
+| `policy` | — | Legislation, regulation, or administrative rule | GENIUS Act, CMS 2027 Advance Notice |
+
+#### Entertainment (Clay)
+
+| Type | Extends | What it tracks | Examples |
+|------|---------|---------------|----------|
+| `studio` | company | Production company or media business | Beast Industries, Mediawan |
+| `creator` | person | Individual content creator or artist | MrBeast, Taylor Swift |
+| `franchise` | product | IP, franchise, or media property | Claynosaurz, Pudgy Penguins |
+| `platform` | product | Distribution or social media platform | YouTube, TikTok, Dropout |
+
+#### AI/Alignment (Theseus)
+
+| Type | Extends | What it tracks | Examples |
+|------|---------|---------------|----------|
+| `lab` | company | AI research laboratory | Anthropic, OpenAI, DeepMind |
+| `model` | product | AI model or model family | Claude, GPT-4, Gemini |
+| `framework` | product | Safety framework, governance protocol, or methodology | RSP, Constitutional AI |
+| `governance_body` | organization | AI governance or safety organization | AISI, FLI, Partnership on AI |
+
+### Choosing the Right Type
+
+```
+Is it a person?                          → person (or domain-specific: creator)
+Is it a government/regulatory body?      → organization (or domain-specific: governance_body)
+Is it a governance proposal or market?   → decision_market
+Is it a specific product/tool?           → product (or domain-specific: drug, model, vehicle, etc.)
+Is it an organization that operates?     → company (or domain-specific: lab, studio, insurer, etc.)
+Is it a market segment?                  → market
+Is it a policy or regulation?            → policy
+Is it a space mission?                   → mission
+Is it a physical facility?               → facility
+Is it a multi-mission program?           → program
+```
+
+**Rule:** Use the most specific type available. If a DeFi protocol fits `protocol`, use that instead of `company`. If an AI lab fits `lab`, use that instead of `company`. Domain-specific types carry domain-specific fields.
+
+### Adding New Types
+
+Core types require a schema PR reviewed by Leo. Domain-specific types are agent-managed — add a row to your domain's extension table via PR. No schema-wide changes needed. If a new type could apply to multiple domains, propose it as a core type instead.
+
+### Cross-Domain Entity Dedup
+
+One entity per real-world object. If Anthropic appears in both internet-finance and ai-alignment sources:
+
+1. **First creator owns the file.** Whichever agent creates the entity first files it in their domain (`entities/ai-alignment/anthropic.md`).
+2. **Other agents use `secondary_domains`.** The entity gets `secondary_domains: [internet-finance]` so it's discoverable across domains.
+3. **Both agents can update.** The `tracked_by` agent is responsible for staleness, but any agent can propose updates via PR when their sources contain new information.
+4. **Type follows primary domain.** If Theseus creates it, it's `lab`. If Rio had created it first, it would be `company`. The type reflects the primary tracking perspective.
+
+If two agents independently create the same entity, the reviewer merges them during PR review — keep the richer file, add `secondary_domains` from the other.
 
 ## YAML Frontmatter
 
 ```yaml
 ---
 type: entity
-entity_type: company | person | market | decision_market
+entity_type: company | person | organization | product | market | decision_market | protocol | token | exchange | fund | vehicle | mission | facility | program | therapy | drug | insurer | provider | policy | studio | creator | franchise | platform | lab | model | framework | governance_body
 name: "Display name"
 domain: internet-finance | entertainment | health | ai-alignment | space-development
 handles: ["@StaniKulechov", "@MetaLeX_Labs"]  # social/web identities
 website: https://example.com
-status: active | inactive | acquired | liquidated | emerging  # for company/person/market
+status: active | inactive | acquired | liquidated | emerging  # for most types
 # Decision markets use: active | passed | failed
 tracked_by: rio  # which agent owns this entity
 created: YYYY-MM-DD
@@ -45,7 +133,7 @@ last_updated: YYYY-MM-DD
 | Field | Type | Description |
 |-------|------|-------------|
 | type | enum | Always `entity` |
-| entity_type | enum | `company`, `person`, `market`, or `decision_market` |
+| entity_type | enum | Any type from the type system above |
 | name | string | Canonical display name |
 | domain | enum | Primary domain |
 | status | enum | Current operational status |
@@ -152,7 +240,7 @@ Example: `entities/internet-finance/metadao-hire-robin-hanson.md`
 ## Company-Specific Fields
 
 ```yaml
-# Company attributes
+# Company attributes (also used by protocol, exchange, fund, lab, studio, insurer, provider)
 founded: YYYY-MM-DD
 founders: ["[[person-entity]]"]
 category: "DeFi lending protocol"
@@ -184,7 +272,7 @@ launch_date: YYYY-MM-DD       # when the entity launched/raised
 People entities serve dual purpose: they track public figures we analyze AND serve as contributor profiles when those people engage with the KB. One file, two functions — the file grows from "person we track" to "person who participates."
 
 ```yaml
-# Person attributes
+# Person attributes (also used by creator)
 role: "Founder & CEO of Aave"
 organizations: ["[[company-entity]]"]
 followers: 290000  # primary platform
@@ -202,9 +290,19 @@ first_contribution: null  # date of first KB interaction
 attribution_handle: null  # how they want to be credited
 ```
 
-## Market-Specific Fields
+## Other Core Type Fields
 
 ```yaml
+# Organization attributes (also used by governance_body)
+jurisdiction: "United States"
+authority: "Securities regulation"  # what this body governs
+parent_body: "[[parent-organization]]"
+
+# Product attributes (also used by token, vehicle, drug, model, framework, franchise, platform)
+maker: "[[company-entity]]"  # who built/maintains this
+launched: YYYY-MM-DD
+category: "futarchy governance program"
+
 # Market attributes
 total_size: "$120B TVL"
 growth_rate: "flat since 2021"
@@ -213,6 +311,8 @@ market_structure: "winner-take-most | fragmented | consolidating"
 regulatory_status: "emerging clarity | hostile | supportive"
 ```
 
+**Domain-specific fields:** Each agent adds type-specific fields as they start extracting entities. The fields above cover core types. When Astra creates their first `vehicle` entity, they add vehicle-specific fields to the schema. Complexity is earned from actual use, not designed in advance.
+
 ## Body Format
 
 ```markdown
@@ -275,9 +375,19 @@ entities/
     claynosaurz.md
     pudgy-penguins.md
     matthew-ball.md
+    beast-industries.md                # studio
   health/
-    devoted-health.md
+    devoted-health.md                  # insurer
     function-health.md
+    ozempic.md                         # drug
+  ai-alignment/
+    anthropic.md                       # lab
+    claude.md                          # model
+    rsp.md                             # framework
+  space-development/
+    spacex.md
+    starship.md                        # vehicle
+    artemis.md                         # program
 ```
 
 **Filename:** Lowercase slugified name. Companies use brand name, people use full name. Decision markets use `{parent}-{proposal-slug}.md`.
@@ -299,6 +409,8 @@ Sources often contain entity information. During extraction, agents should:
 - Update entities (factual changes to tracked objects) → `entities/{domain}/`
 - Both from the same source, in the same PR
 
+See `skills/extract-entities.md` for the full extraction process.
+
 ## Key Difference from Claims
 
 | | Claims | Entities |

skills/extract-entities.md

@@ -0,0 +1,149 @@
+# Entity Extraction Field Guide
+
+How to extract entities from source material. This skill works alongside `extract.md` (claim extraction) — both run during source processing.
+
+## When to Extract Entities
+
+Every source may contain entity data. During extraction, ask:
+
+1. **Does this source mention an organization, person, product, or market we don't already track?** → Create a new entity
+2. **Does this source contain updated information about an entity we already track?** → Update the existing entity (timeline, metrics, status)
+3. **Does this source describe a decision, proposal, or market outcome?** → Create a decision_market entity (if it meets significance threshold)
+
+## The Dual Extraction Loop
+
+```
+Source → Read completely
+       ↓
+       Extract claims (propositions about the world) → domains/{domain}/
+       Extract entities (objects in the world) → entities/{domain}/
+       Update existing entities (new timeline events, metrics)
+       ↓
+       Both in the same PR
+```
+
+## Entity Extraction Process
+
+### Step 1: Identify Entity Mentions
+
+Read the source and list every entity mentioned. For each:
+- Is it already in `entities/{domain}/`? → Flag for update
+- Is it new and significant enough to track? → Flag for creation
+- Is it mentioned in passing with no meaningful data? → Skip
+
+**Significance test:** Would tracking this entity help us evaluate claims or form positions? If the entity is just background context, skip it.
+
+### Step 2: Select Entity Type
+
+Use the most specific type available. See `schemas/entity.md` for the full type system.
+
+```
+Is it a person?                          → person (or domain-specific: creator)
+Is it a government/regulatory body?      → organization (or domain-specific: governance_body)
+Is it a governance proposal or market?   → decision_market
+Is it a specific product/tool?           → product (or domain-specific: drug, model, vehicle)
+Is it an organization that operates?     → company (or domain-specific: lab, studio, insurer)
+Is it a market segment?                  → market
+```
+
+### Step 3: Extract Frontmatter
+
+Fill in every field you have data for. Don't guess — leave fields empty rather than fabricating data.
+
+**Required fields** (every entity):
+- `type: entity`
+- `entity_type`: the specific type
+- `name`: canonical display name
+- `domain`: primary domain
+- `status`: current status
+- `tracked_by`: your agent name
+- `created`: today's date
+
+**Optional but valuable:**
+- `handles`: social media handles (from the source or quick lookup)
+- `website`: primary web presence
+- `tags`: discovery tags
+- `secondary_domains`: if the entity spans domains
+
+**Type-specific fields:** Fill in whatever the source provides. The schema lists all available fields — use the ones that have data.
+
+### Step 4: Write the Body
+
+Follow the body format from `schemas/entity.md`:
+
+1. **Overview**: What this entity is, why we track it (2-3 sentences)
+2. **Current State**: Latest known attributes from this source
+3. **Timeline**: Key events with dates (at minimum, the event from this source)
+4. **Competitive Position**: Where it sits relative to competitors (if known)
+5. **Relationship to KB**: Wiki-link to related claims and entities
+
+### Step 5: Check for Duplicates
+
+Before creating a new entity, search **all** `entities/` directories (not just your domain) for:
+- Same name (exact or variant spelling)
+- Same handles
+- Same website
+
+If a match exists in **your domain**, update the existing entity.
+
+If a match exists in **another domain**, don't create a duplicate. Instead, add your domain to the existing entity's `secondary_domains` list and propose updates via PR. See `schemas/entity.md` → "Cross-Domain Entity Dedup" for the full protocol.
+
+### Step 6: Update Parent Entities
+
+If the new entity has a `parent` or `parent_entity` field, update the parent:
+- Add the new entity to the parent's Relevant Entities section
+- If it's a decision_market, add to the parent's Key Decisions table (if significant)
+- Add a timeline entry on the parent
+
+## What Makes a Good Entity
+
+**Good entities have:**
+- Concrete, verifiable attributes (dates, metrics, names)
+- Clear relevance to at least one domain claim
+- Enough data to be useful (not just a name)
+- A reason to track changes over time
+
+**Bad entity candidates:**
+- Mentioned once in passing with no data
+- Purely historical with no ongoing relevance
+- Duplicates of existing entities under different names
+- Too granular (every tweet doesn't need an entity)
+
+## Domain-Specific Guidance
+
+### Internet Finance (Rio)
+- Protocols and tokens are separate entities (MetaDAO = company, META = token)
+- Every futardio launch that raises significant capital gets a company entity
+- Governance proposals that materially change direction get decision_market entities
+- Regulatory bodies (CFTC, SEC) get organization entities
+
+### Space (Astra)
+- Vehicles (Starship, New Glenn) are distinct from their makers (SpaceX, Blue Origin)
+- Programs (Artemis, Commercial Crew) are distinct from the agencies running them
+- Missions get entities when they're historically significant or produce notable data
+
+### Health (Vida)
+- Drugs are distinct from the companies that make them
+- Insurers and providers are separate entity types — don't conflate
+- Policies (legislation, CMS rules) get organization entities for the issuing body + policy entities for the rule itself
+
+### Entertainment (Clay)
+- Creators are distinct from their companies (MrBeast vs Beast Industries)
+- Franchises/IP are distinct from the studios that own them
+- Platforms (YouTube, TikTok) get product or platform entities
+
+### AI/Alignment (Theseus)
+- Labs are distinct from their models (Anthropic vs Claude)
+- Frameworks (RSP, Constitutional AI) get their own entities when they influence multiple claims
+- Governance bodies (AISI, FLI) get organization entities
+
+## Eval Checklist (for reviewers)
+
+1. `entity_type` is the most specific available type
+2. Required fields are all populated
+3. No fabricated data — empty fields are better than guesses
+4. Not a duplicate of existing entity
+5. Meets significance threshold
+6. Wiki links resolve to real files
+7. Parent entity updated if applicable
+8. Filing location is correct: `entities/{domain}/{slug}.md`