Compare commits
1 commit
81339b3df3
...
a116d9dd01
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
a116d9dd01 |
38 changed files with 93 additions and 1589 deletions
|
|
@ -1,260 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,40 +0,0 @@
|
||||||
---
|
|
||||||
type: claim
|
|
||||||
domain: entertainment
|
|
||||||
description: "Industry-wide recognition that vanity metrics systematically failed as proxies for business outcomes, driving the creator economy toward quality, consistency, and measurable results"
|
|
||||||
confidence: experimental
|
|
||||||
source: "Clay, extracted from ExchangeWire, 'The Creator Economy in 2026: Tapping into Culture, Community, Credibility, and Craft', December 16, 2025"
|
|
||||||
created: 2026-03-11
|
|
||||||
secondary_domains:
|
|
||||||
- cultural-dynamics
|
|
||||||
---
|
|
||||||
|
|
||||||
# creator economy's 2026 reckoning with visibility metrics shows that follower counts and surface-level engagement do not predict brand influence or ROI
|
|
||||||
|
|
||||||
ExchangeWire's December 2025 industry analysis characterizes 2026 as "the year the creator industry finally reckons with its visibility obsession." Brands have discovered that "booking recognizable creators and chasing fast cultural wins does not always build long-term influence or strong ROI." The industry is moving away from "vanity metrics like follower counts and surface-level engagement" toward "creator quality, consistency, and measurable business outcomes."
|
|
||||||
|
|
||||||
The mechanism is a measurement failure: follower counts and engagement rates were used as proxies for influence because they were easy to measure, not because they actually predicted the outcomes brands cared about. As the creator economy matured and brands accumulated multi-year data on campaign performance, the proxy broke down. High reach does not guarantee persuasion, and viral moments do not compound into durable brand relationships.
|
|
||||||
|
|
||||||
This reckoning is the demand-side mirror of the supply-side evolution documented in [[creator-brand-partnerships-shifting-from-transactional-campaigns-to-long-term-joint-ventures-with-shared-formats-audiences-and-revenue]]. That claim describes how sophisticated creators are evolving into strategic business partners; this claim describes why brands are demanding it — because the old transactional model delivered impressive reach numbers but weak business outcomes.
|
|
||||||
|
|
||||||
The shift toward "creator quality, consistency, and measurable business outcomes" implies a revaluation of creator types: smaller creators with highly engaged niche audiences become more attractive than large creators with broad but shallow audiences. This inverts the traditional media buying logic that equates reach with value, and aligns brand spend with the engagement depth that [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]] identifies as structurally superior to passive reach.
|
|
||||||
|
|
||||||
## Evidence
|
|
||||||
- ExchangeWire (December 2025) identifies 2026 as "the year the creator industry finally reckons with its visibility obsession"
|
|
||||||
- Brands "realize that booking recognizable creators and chasing fast cultural wins does not always build long-term influence or strong ROI"
|
|
||||||
- Industry moving from "vanity metrics like follower counts and surface-level engagement" to "creator quality, consistency, and measurable business outcomes"
|
|
||||||
- Creator economy context: £190B global market, $37B US ad spend on creators (2025)
|
|
||||||
|
|
||||||
## Limitations
|
|
||||||
|
|
||||||
Rated experimental because: the evidence is industry analysis and directional prediction rather than systematic pre/post measurement of metric adoption and its effect on ROI outcomes. The claim describes an emerging recognition, not a documented shift with controlled evidence.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
Relevant Notes:
|
|
||||||
- [[creator-brand-partnerships-shifting-from-transactional-campaigns-to-long-term-joint-ventures-with-shared-formats-audiences-and-revenue]] — the structural form the post-vanity-metrics shift is taking
|
|
||||||
- [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]] — why depth-optimized audiences outperform reach-optimized ones
|
|
||||||
- [[social video is already 25 percent of all video consumption and growing because dopamine-optimized formats match generational attention patterns]] — the platform architecture that made vanity metrics dominant
|
|
||||||
|
|
||||||
Topics:
|
|
||||||
- [[web3 entertainment and creator economy]]
|
|
||||||
|
|
@ -1,44 +0,0 @@
|
||||||
---
|
|
||||||
type: claim
|
|
||||||
domain: entertainment
|
|
||||||
description: "Creator world-building in 2025 emerged as the dominant retention mechanism, producing audiences who return because they belong to something, not just because they consume content"
|
|
||||||
confidence: experimental
|
|
||||||
source: "Clay, extracted from ExchangeWire, 'The Creator Economy in 2026: Tapping into Culture, Community, Credibility, and Craft', December 16, 2025"
|
|
||||||
created: 2026-03-11
|
|
||||||
secondary_domains:
|
|
||||||
- cultural-dynamics
|
|
||||||
---
|
|
||||||
|
|
||||||
# creator world-building converts viewers into returning communities by creating belonging audiences can recognize, participate in, and return to
|
|
||||||
|
|
||||||
ExchangeWire's 2025 creator economy analysis identifies world-building as the defining creator strategy of 2025: "creating a sense of belonging — something audiences could recognize, participate in, and return to." The best creator content in 2025 went beyond individual videos to construct coherent universes — consistent aesthetic languages, recurring characters or themes, inside references that reward repeat engagement, lore that accumulates — so that audiences weren't just watching content but inhabiting a world.
|
|
||||||
|
|
||||||
The word "recognize" is significant: a world-built creator universe is legible to members. Newcomers feel like outsiders; returning audience members feel like insiders. This insider/outsider dynamic is the functional mechanism of community formation. When an audience member can identify a reference, understand a callback, or predict a creator's aesthetic choices, they are experiencing the feeling of belonging — of being a participant in something rather than a passive consumer.
|
|
||||||
|
|
||||||
The word "participate in" is also significant: world-building is not passive worldcraft but an invitation structure. Audiences participate by creating fan content, by commenting in the vocabulary of the universe, by evangelizing to newcomers. This is the co-creation layer of [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]] emerging organically from individual creator strategy rather than from deliberate franchise management. The creator builds the world; the audience populates it.
|
|
||||||
|
|
||||||
"Return to" is the retention claim: audiences return not because new content was published but because the world is where they belong. This is a fundamentally different pull mechanism than algorithmic recommendations or notification-driven re-engagement. The creator doesn't need to win the algorithm for returning community members — they need to maintain the world. This produces a qualitatively different audience relationship, consistent with [[creator-owned direct subscription platforms produce qualitatively different audience relationships than algorithmic social platforms because subscribers choose deliberately]]: the deliberate return to a world is the same cognitive act as the deliberate subscription.
|
|
||||||
|
|
||||||
World-building also provides strategic differentiation in a saturated creator landscape. When content formats are easily copied — which [[social video is already 25 percent of all video consumption and growing because dopamine-optimized formats match generational attention patterns]] implies, as high-signal-liquidity platforms accelerate format diffusion — a creator's world is uniquely theirs. A universe of accumulated lore, relationships, and belonging cannot be replicated by a competitor posting in the same format.
|
|
||||||
|
|
||||||
The craft pillar of ExchangeWire's 2026 framework describes the underlying production discipline: "crafting clear narratives, building consistent themes across videos, and creating a cohesive experience." World-building is not a strategic intention alone — it requires the execution discipline of consistent narrative architecture across content units.
|
|
||||||
|
|
||||||
## Evidence
|
|
||||||
- ExchangeWire (December 2025): world-building in 2025 defined as "creating a sense of belonging — something audiences could recognize, participate in, and return to"
|
|
||||||
- Craft pillar: "crafting clear narratives, building consistent themes across videos, and creating a cohesive experience"
|
|
||||||
- Source: ExchangeWire, December 16, 2025
|
|
||||||
|
|
||||||
## Limitations
|
|
||||||
|
|
||||||
Rated experimental because: the evidence is industry analysis and qualitative characterization. No systematic data on whether world-building creators show higher retention rates than non-world-building creators at equivalent reach levels. The claim describes an observed pattern and practitioner framework, not a controlled causal finding.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
Relevant Notes:
|
|
||||||
- [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]] — world-building is the creator-economy analog to fanchise management's co-creation and community tooling layers, emerging bottom-up from individual creators rather than top-down from IP owners
|
|
||||||
- [[entertainment IP should be treated as a multi-sided platform that enables fan creation rather than a unidirectional broadcast asset]] — world-building creates the infrastructure that makes creator IP function like a platform
|
|
||||||
- [[creator-owned direct subscription platforms produce qualitatively different audience relationships than algorithmic social platforms because subscribers choose deliberately]] — the deliberate return to a world and the deliberate subscription are both identity-based engagement acts
|
|
||||||
- [[social video is already 25 percent of all video consumption and growing because dopamine-optimized formats match generational attention patterns]] — world-building differentiates creators in a format-saturated landscape where production formats diffuse rapidly
|
|
||||||
|
|
||||||
Topics:
|
|
||||||
- [[web3 entertainment and creator economy]]
|
|
||||||
|
|
@ -1,39 +0,0 @@
|
||||||
---
|
|
||||||
type: claim
|
|
||||||
domain: entertainment
|
|
||||||
description: "Audiences detect inauthenticity in sponsored content when the narrative doesn't fit the creator's established voice, discounting the message and eroding the creator's broader credibility"
|
|
||||||
confidence: experimental
|
|
||||||
source: "Clay, extracted from ExchangeWire, 'The Creator Economy in 2026: Tapping into Culture, Community, Credibility, and Craft', December 16, 2025"
|
|
||||||
created: 2026-03-11
|
|
||||||
secondary_domains:
|
|
||||||
- cultural-dynamics
|
|
||||||
---
|
|
||||||
|
|
||||||
# unnatural brand-creator narratives damage audience trust because they signal commercial capture rather than genuine creative collaboration
|
|
||||||
|
|
||||||
ExchangeWire's 2025 creator economy analysis asserts that "unnatural narratives damage audience trust" and that brands should instead embrace "genuine creative collaboration." The mechanism: audiences who follow a creator have built a mental model of that creator's voice, aesthetic, and interests. When a sponsored segment deploys a narrative that doesn't fit that model — language that's too formal, enthusiasm for a product the creator would never organically mention, messaging that prioritizes brand talking points over creator perspective — the mismatch triggers a recognition response. The audience registers commercial capture, not recommendation.
|
|
||||||
|
|
||||||
The trust damage is not limited to the specific sponsored segment. Creators derive authority from the audience's belief that their recommendations reflect genuine judgment. A detected commercial capture event degrades that general belief. Even future unsponsored content carries forward some credibility discount. This is why credibility is listed as one of the four pillars of creator economy strategy in 2026 alongside culture, community, and craft — it is a stock variable that takes time to build and can be depleted rapidly.
|
|
||||||
|
|
||||||
This claim extends the structural argument in [[creator-brand-partnerships-shifting-from-transactional-campaigns-to-long-term-joint-ventures-with-shared-formats-audiences-and-revenue]]. The shift toward joint ventures with shared formats and audiences is not just a commercial evolution — it is a structural response to the trust damage problem. Long-term creative partnerships produce narratives that are more naturally integrated with creator voice because the brand has built genuine familiarity with the creator's aesthetic and audience. Transactional campaigns produce unnatural narratives because the brand arrives with pre-formed messaging and the creator integrates it without authorship.
|
|
||||||
|
|
||||||
The implication for the [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]] framework: trust damage is most costly at the higher levels of the engagement stack. A creator whose audience has co-created content, built community, or developed identity attachment around the creator's worldview has more credibility to lose — and their audience is most sensitive to commercial capture because they have the deepest mental model of what the creator genuinely believes.
|
|
||||||
|
|
||||||
## Evidence
|
|
||||||
- ExchangeWire (December 2025): "Unnatural narratives damage audience trust" — brands advised to embrace "genuine creative collaboration"
|
|
||||||
- Credibility listed as one of four strategic pillars for 2026 creator economy (alongside culture, community, craft)
|
|
||||||
- Source: ExchangeWire, December 16, 2025
|
|
||||||
|
|
||||||
## Limitations
|
|
||||||
|
|
||||||
Rated experimental because: the claim describes an audience psychology mechanism that is supported by practitioner observation but not systematically measured. No controlled studies are cited comparing trust metrics before/after authentic vs inauthentic brand integration. The evidence is industry analysis and directional guidance.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
Relevant Notes:
|
|
||||||
- [[creator-brand-partnerships-shifting-from-transactional-campaigns-to-long-term-joint-ventures-with-shared-formats-audiences-and-revenue]] — joint ventures solve the trust damage problem by enabling authentic narrative integration
|
|
||||||
- [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]] — credibility loss is most costly at the higher fanchise levels where identity investment is deepest
|
|
||||||
- [[creator-economy-2026-reckoning-with-visibility-metrics-shows-follower-counts-do-not-predict-brand-influence-or-roi]] — credibility erosion is why reach metrics fail: a creator with high reach but damaged trust delivers poor ROI despite impressive impression counts
|
|
||||||
|
|
||||||
Topics:
|
|
||||||
- [[web3 entertainment and creator economy]]
|
|
||||||
|
|
@ -3,29 +3,23 @@ type: entity
|
||||||
entity_type: company
|
entity_type: company
|
||||||
name: Etnl.io
|
name: Etnl.io
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
status: fundraising_failed
|
status: active
|
||||||
website: https://etnl.io
|
website: https://etnl.io
|
||||||
social:
|
twitter: https://x.com/etnl_io
|
||||||
twitter: https://x.com/etnl_io
|
|
||||||
telegram: https://t.me/etnlio
|
|
||||||
key_metrics:
|
key_metrics:
|
||||||
futardio_raise_target: "$500,000"
|
team_budget: "$30,000/month"
|
||||||
futardio_raise_committed: "$96"
|
product: "Secure Enclave-based mobile wallet"
|
||||||
monthly_team_budget: "$30,000"
|
|
||||||
raise_outcome: "refunding"
|
|
||||||
tracked_by: rio
|
tracked_by: rio
|
||||||
created: 2026-03-11
|
created: 2026-03-11
|
||||||
---
|
---
|
||||||
|
|
||||||
# Etnl.io
|
# Etnl.io
|
||||||
|
|
||||||
Etnl.io is a mobile wallet project that attempted to raise capital through Futardio's futarchy-governed platform in March 2026. The project proposed a Secure Enclave-based mobile wallet delivering hardware-level security without requiring external devices. The Futardio raise failed to reach minimum threshold, attracting only $96 of a $500,000 target before refunding.
|
Etnl.io is a mobile wallet project focused on hardware-level security without external devices. The platform uses smartphone Secure Enclave technology to generate and store cryptographic keys entirely on-device, targeting crypto-native users who want hardware-grade security without purchasing separate hardware wallets. The architecture eliminates seed phrase exposure and external dependencies through on-device key generation, continuous integrity verification, and authenticated software updates.
|
||||||
|
|
||||||
## Timeline
|
## Timeline
|
||||||
- **2026-03-09** — Futardio raise launched with $500,000 target, $30K/month team budget, Secure Enclave-based mobile wallet product
|
- **2026-03-09** — [[futardio-etnlio-launch]] failed: $500K target, $96 committed, refunded after one day
|
||||||
- **2026-03-10** — Raise closed in refunding status with $96 total committed (0.019% of target)
|
|
||||||
|
|
||||||
## Relationship to KB
|
## Relationship to KB
|
||||||
- [[futardio]] — platform used for failed capital raise
|
- First documented failed raise on [[futardio]] platform
|
||||||
- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — empirical evidence of adoption barriers
|
- Case study for [[futarchy-adoption-faces-friction-from-token-price-psychology-proposal-complexity-and-liquidity-requirements]]
|
||||||
- [[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]] — challenges product-market fit claim
|
|
||||||
|
|
|
||||||
43
entities/internet-finance/futardio-etnlio-launch.md
Normal file
43
entities/internet-finance/futardio-etnlio-launch.md
Normal file
|
|
@ -0,0 +1,43 @@
|
||||||
|
---
|
||||||
|
type: entity
|
||||||
|
entity_type: decision_market
|
||||||
|
name: "Futardio: Etnl.io Fundraise"
|
||||||
|
domain: internet-finance
|
||||||
|
status: failed
|
||||||
|
parent_entity: "[[futardio]]"
|
||||||
|
platform: "futardio"
|
||||||
|
proposal_url: "https://www.futard.io/launch/4oiZeLhoDB9jGTFd28kJDKBYheL1Yg1XwR3qPTa69Rx9"
|
||||||
|
proposal_date: 2026-03-09
|
||||||
|
resolution_date: 2026-03-10
|
||||||
|
category: "fundraise"
|
||||||
|
summary: "Mobile wallet project seeking $500K failed to reach minimum threshold with only $96 committed"
|
||||||
|
key_metrics:
|
||||||
|
raise_target: "$500,000"
|
||||||
|
total_committed: "$96"
|
||||||
|
token: "64S"
|
||||||
|
token_mint: "64SnHgEfSdzpnmHEhh2niN8bcAjmhTyEQky2DKWBmeta"
|
||||||
|
launch_address: "4oiZeLhoDB9jGTFd28kJDKBYheL1Yg1XwR3qPTa69Rx9"
|
||||||
|
tracked_by: rio
|
||||||
|
created: 2026-03-11
|
||||||
|
---
|
||||||
|
|
||||||
|
# Futardio: Etnl.io Fundraise
|
||||||
|
|
||||||
|
## Summary
|
||||||
|
Etnl.io attempted to raise $500,000 through Futardio's futarchy-governed ICO platform to build a Secure Enclave-based mobile wallet. Despite complete documentation, clear use of funds ($30K/month team budget), coherent product narrative (hardware-level security without external devices), and professional presentation, the raise attracted only $96 in commitments and entered refunding status after one day.
|
||||||
|
|
||||||
|
## Market Data
|
||||||
|
- **Outcome:** Failed (refunding)
|
||||||
|
- **Target:** $500,000
|
||||||
|
- **Committed:** $96 (0.019% of target)
|
||||||
|
- **Duration:** 1 day (2026-03-09 to 2026-03-10)
|
||||||
|
- **Platform version:** v0.7
|
||||||
|
|
||||||
|
## Significance
|
||||||
|
First documented failed raise on the Futardio platform. The failure is particularly notable because it's not attributable to project quality, fraud risk, or information asymmetry—Etnl.io had complete documentation, clear technical differentiation (Secure Enclave integration), defined market positioning (crypto-native users wanting hardware-grade security), and transparent fund allocation. This suggests the barrier is market liquidity and participation depth rather than the unruggable ICO mechanism's ability to filter quality. The rapid failure (one day) demonstrates that futarchy-governed markets can reject projects before they build momentum, particularly when baseline liquidity is thin.
|
||||||
|
|
||||||
|
## Relationship to KB
|
||||||
|
- [[futardio]] — first documented failed raise on platform
|
||||||
|
- [[etnlio]] — project entity
|
||||||
|
- Empirical evidence for [[futarchy-adoption-faces-friction-from-token-price-psychology-proposal-complexity-and-liquidity-requirements]]
|
||||||
|
- Challenges [[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]] regarding scale claims
|
||||||
|
|
@ -45,8 +45,7 @@ MetaDAO's token launch platform. Implements "unruggable ICOs" — permissionless
|
||||||
- **2026-03** — Ranger Finance liquidation proposal — first futarchy-governed enforcement action
|
- **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-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-09** — Etnl.io raise launched: $500,000 target, Secure Enclave mobile wallet, $30K/month team budget
|
- **2026-03-09** — [[futardio-etnlio-launch]] failed: First documented failed raise on platform, $500K target attracted only $96, refunded after one day
|
||||||
- **2026-03-10** — Etnl.io raise failed: $96 committed (0.019% of target), refunding status — first documented failed raise on platform
|
|
||||||
## Competitive Position
|
## Competitive Position
|
||||||
- **Unique mechanism**: Only launch platform with futarchy-governed accountability and treasury return guarantees
|
- **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."
|
- **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."
|
||||||
|
|
|
||||||
|
|
@ -1,49 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,54 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,50 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,52 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,51 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,51 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,51 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,52 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,57 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -1,54 +0,0 @@
|
||||||
---
|
|
||||||
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]]
|
|
||||||
|
|
@ -53,20 +53,6 @@ The futarchy governance protocol on Solana. Implements decision markets through
|
||||||
- **2026-03** — Ranger liquidation proposal; treasury subcommittee formation
|
- **2026-03** — Ranger liquidation proposal; treasury subcommittee formation
|
||||||
- **2026-03** — Pine Analytics Q4 2025 quarterly report published
|
- **2026-03** — Pine Analytics Q4 2025 quarterly report published
|
||||||
|
|
||||||
## 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
|
## Competitive Position
|
||||||
- **First mover** in futarchy-governed organizations at scale
|
- **First mover** in futarchy-governed organizations at scale
|
||||||
- **No direct competitor** for conditional-market governance on Solana
|
- **No direct competitor** for conditional-market governance on Solana
|
||||||
|
|
|
||||||
|
|
@ -6,12 +6,7 @@ url: "https://www.futard.io/proposal/ELwCkHt1U9VBpUFJ7qGoVMatEwLSr1HYj9q9t8JQ1Nc
|
||||||
date: 2024-03-03
|
date: 2024-03-03
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: processed
|
status: unprocessed
|
||||||
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]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -6,12 +6,7 @@ url: "https://www.futard.io/proposal/D9pGGmG2rCJ5BXzbDoct7EcQL6F6A57azqYHdpWJL9C
|
||||||
date: 2024-03-13
|
date: 2024-03-13
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: processed
|
status: unprocessed
|
||||||
processed_by: rio
|
|
||||||
processed_date: 2026-03-11
|
|
||||||
claims_extracted: []
|
|
||||||
enrichments:
|
|
||||||
- "metadao-develop-faas — decision_market entity created"
|
|
||||||
tags: [futardio, metadao, futarchy, solana, governance]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -6,12 +6,7 @@ url: "https://www.futard.io/proposal/HXohDRKtDcXNKnWysjyjK8S5SvBe76J5o4NdcF4jj96
|
||||||
date: 2024-03-28
|
date: 2024-03-28
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: processed
|
status: unprocessed
|
||||||
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]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -6,12 +6,7 @@ url: "https://www.futard.io/proposal/BgHv9GutbnsXZLZQHqPL8BbGWwtcaRDWx82aeRMNmJb
|
||||||
date: 2024-05-27
|
date: 2024-05-27
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: processed
|
status: unprocessed
|
||||||
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]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -6,12 +6,7 @@ url: "https://www.futard.io/proposal/9BMRY1HBe61MJoKEd9AAW5iNQyws2vGK6vuL49oR3Az
|
||||||
date: 2024-06-26
|
date: 2024-06-26
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: processed
|
status: unprocessed
|
||||||
processed_by: rio
|
|
||||||
processed_date: 2026-03-11
|
|
||||||
claims_extracted: []
|
|
||||||
enrichments:
|
|
||||||
- "metadao-fundraise-2 — decision_market entity created"
|
|
||||||
tags: [futardio, metadao, futarchy, solana, governance]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/zN9Uft1zEsh9h7Wspeg5bTNirBBvtBTaJ6i5KcEnbAb
|
||||||
date: 2024-11-21
|
date: 2024-11-21
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: processed
|
status: unprocessed
|
||||||
tags: [futardio, metadao, futarchy, solana, governance]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
processed_by: rio
|
processed_by: rio
|
||||||
|
|
|
||||||
|
|
@ -6,12 +6,7 @@ url: "https://www.futard.io/proposal/CBhieBvzo5miQBrdaM7vALpgNLt4Q5XYCDfNLaE2wXJ
|
||||||
date: 2025-01-28
|
date: 2025-01-28
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: processed
|
status: unprocessed
|
||||||
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]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,7 @@ tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
processed_by: rio
|
processed_by: rio
|
||||||
processed_date: 2025-02-10
|
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", "metadao-hire-robin-hanson — decision_market entity created"]
|
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"]
|
||||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
claims_extracted:
|
claims_extracted:
|
||||||
- "shared-liquidity-amms-could-solve-futarchy-capital-inefficiency-by-routing-base-pair-deposits-into-all-derived-conditional-token-markets.md"
|
- "shared-liquidity-amms-could-solve-futarchy-capital-inefficiency-by-routing-base-pair-deposits-into-all-derived-conditional-token-markets.md"
|
||||||
|
|
|
||||||
|
|
@ -1,33 +1,34 @@
|
||||||
---
|
---
|
||||||
type: source
|
type: source
|
||||||
status: processed
|
title: "Futardio: Testing Totem For The Win"
|
||||||
format: markdown
|
author: "futard.io"
|
||||||
domain: futard.io
|
url: "https://www.futard.io/proposal/3rCNPg7wG1XCZBCWwjgjFgfhEySu2LhqeoU9KTUesTgg"
|
||||||
author: unknown
|
date: 2025-02-24
|
||||||
tags: [proposal, DAO, Solana]
|
domain: internet-finance
|
||||||
created: 2025-02-24
|
format: data
|
||||||
processed_date: 2025-02-25
|
status: unprocessed
|
||||||
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
||||||
# Proposal Testing Totem for the Win
|
## Proposal Details
|
||||||
|
- Project: Unknown
|
||||||
|
- Proposal: Testing Totem For The Win
|
||||||
|
- Status: Failed
|
||||||
|
- Created: 2025-02-24
|
||||||
|
- URL: https://www.futard.io/proposal/3rCNPg7wG1XCZBCWwjgjFgfhEySu2LhqeoU9KTUesTgg
|
||||||
|
- Description: Nothing
|
||||||
|
|
||||||
**Status:** Failed
|
## Content
|
||||||
|
|
||||||
This document details the proposal testing totem for the win.
|
## Starts Here
|
||||||
|
|
||||||
## On-Chain Data
|
## Raw Data
|
||||||
- **Proposal Account:** 3rCNPg...
|
|
||||||
- **DAO Account:** 9xYz...
|
|
||||||
- **Proposer Address:** 1a2b3c...
|
|
||||||
- **Autocrat Version:** v1.2.3
|
|
||||||
- **Completion Date:** 2025-02-24
|
|
||||||
- **End Date:** 2025-02-25
|
|
||||||
|
|
||||||
## URLs
|
- Proposal account: `3rCNPg7wG1XCZBCWwjgjFgfhEySu2LhqeoU9KTUesTgg`
|
||||||
- [Original URL](https://futard.io/proposal/3rCNPg...)
|
- Proposal number: 0
|
||||||
- [New URL](https://futarchy.metadao.fi/proposal/testing-totem-for-the-win)
|
- DAO account: `DHeutMkAZLy2LrQAeV7whvr2RJhV463rc1zkT6FxPa46`
|
||||||
|
- Proposer: `FsqK75jj26WgF8LWXt8iZwwWKBFiAPp1hZu4mBdGgTmA`
|
||||||
## Context
|
- Autocrat version: 0.4
|
||||||
The proposal was intended to test the efficacy of a new governance model within the DAO.
|
- Completed: 2025-03-04
|
||||||
|
- Ended: 2025-02-28
|
||||||
<!-- claim pending --> [[futarchy]] and [[Solana]]
|
|
||||||
|
|
|
||||||
|
|
@ -6,12 +6,7 @@ url: "https://www.futard.io/proposal/HREoLZVrY5FHhPgBFXGGc6XAA3hPjZw1UZcahhumFke
|
||||||
date: 2025-02-26
|
date: 2025-02-26
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: processed
|
status: unprocessed
|
||||||
processed_by: rio
|
|
||||||
processed_date: 2026-03-11
|
|
||||||
claims_extracted: []
|
|
||||||
enrichments:
|
|
||||||
- "metadao-release-launchpad — decision_market entity created"
|
|
||||||
tags: [futardio, metadao, futarchy, solana, governance]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -14,7 +14,6 @@ claims_extracted:
|
||||||
enrichments:
|
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"
|
- "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"
|
- "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]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -7,15 +7,7 @@ date: 2025-12-16
|
||||||
domain: entertainment
|
domain: entertainment
|
||||||
secondary_domains: [cultural-dynamics]
|
secondary_domains: [cultural-dynamics]
|
||||||
format: article
|
format: article
|
||||||
status: processed
|
status: unprocessed
|
||||||
processed_by: "Clay"
|
|
||||||
processed_date: 2026-03-11
|
|
||||||
claims_extracted:
|
|
||||||
- "creator economy's 2026 reckoning with visibility metrics shows that follower counts and surface-level engagement do not predict brand influence or ROI"
|
|
||||||
- "unnatural brand-creator narratives damage audience trust because they signal commercial capture rather than genuine creative collaboration"
|
|
||||||
- "creator world-building converts viewers into returning communities by creating belonging audiences can recognize, participate in, and return to"
|
|
||||||
enrichments:
|
|
||||||
- "creator-brand-partnerships claim already extracted from this source in a prior pass"
|
|
||||||
priority: medium
|
priority: medium
|
||||||
tags: [creator-economy-2026, culture, community, credibility, craft, content-quality]
|
tags: [creator-economy-2026, culture, community, credibility, craft, content-quality]
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -7,14 +7,9 @@ date: 2026-01-01
|
||||||
domain: entertainment
|
domain: entertainment
|
||||||
secondary_domains: [ai-alignment]
|
secondary_domains: [ai-alignment]
|
||||||
format: report
|
format: report
|
||||||
status: null-result
|
status: unprocessed
|
||||||
priority: high
|
priority: high
|
||||||
tags: [ai-entertainment, value-capture, distribution, mckinsey, producers-vs-distributors]
|
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
|
## Content
|
||||||
|
|
@ -51,11 +46,3 @@ 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
|
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.
|
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.
|
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)
|
|
||||||
|
|
|
||||||
|
|
@ -6,9 +6,7 @@ url: "https://www.futard.io/launch/ay6ZwDSGWma5AW9mnM69M8BbT9LNMimjbi7o4Uj4iVW"
|
||||||
date: 2026-03-04
|
date: 2026-03-04
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: null-result
|
status: unprocessed
|
||||||
claims_extracted: 0
|
|
||||||
enrichments: []
|
|
||||||
tags: [futardio, metadao, futarchy, solana]
|
tags: [futardio, metadao, futarchy, solana]
|
||||||
event_type: launch
|
event_type: launch
|
||||||
processed_by: rio
|
processed_by: rio
|
||||||
|
|
|
||||||
|
|
@ -16,9 +16,9 @@ extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
extraction_notes: "First documented failed raise on Futardio platform. No new claims warranted—this is empirical evidence of existing friction claims (liquidity requirements, adoption barriers) and challenges optimistic claims about MetaDAO's product-market fit and capital formation speed. The failure is particularly notable because the project had complete documentation, clear use of funds, and a coherent product narrative, suggesting the barrier is market liquidity/participation rather than project quality or information asymmetry."
|
extraction_notes: "First documented failed raise on Futardio platform. No new claims warranted—this is empirical evidence of existing friction claims (liquidity requirements, adoption barriers) and challenges optimistic claims about MetaDAO's product-market fit and capital formation speed. The failure is particularly notable because the project had complete documentation, clear use of funds, and a coherent product narrative, suggesting the barrier is market liquidity/participation rather than project quality or information asymmetry."
|
||||||
processed_by: rio
|
processed_by: rio
|
||||||
processed_date: 2026-03-11
|
processed_date: 2026-03-11
|
||||||
enrichments_applied: ["futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements.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", "internet capital markets compress fundraising from months to days because permissionless raises eliminate gatekeepers while futarchy replaces due diligence bottlenecks with real-time market pricing.md"]
|
enrichments_applied: ["futarchy-adoption-faces-friction-from-token-price-psychology-proposal-complexity-and-liquidity-requirements.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", "internet-capital-markets-compress-fundraising-from-months-to-days-because-permissionless-raises-eliminate-gatekeepers-while-futarchy-replaces-due-diligence-bottlenecks-with-real-time-market-pricing.md"]
|
||||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
extraction_notes: "First documented failed raise on Futardio platform. No new claims warranted—this is empirical evidence of existing friction claims (liquidity requirements, adoption barriers) and challenges optimistic claims about MetaDAO's product-market fit and capital formation speed. The failure is particularly notable because the project had complete documentation, clear use of funds, and a coherent product narrative, suggesting the barrier is market liquidity/participation rather than project quality or information asymmetry. Created entity page for Etnl.io as it represents significant data point (attempted real capital raise with professional presentation) even though outcome was failure."
|
extraction_notes: "First documented failed raise on Futardio platform. No new claims warranted—this is empirical evidence of existing friction claims (liquidity requirements, adoption barriers) and challenges optimistic claims about MetaDAO's product-market fit and capital formation speed. The failure is particularly notable because the project had complete documentation, clear use of funds, and a coherent product narrative, suggesting the barrier is market liquidity/participation rather than project quality or information asymmetry. Created entity pages for Etnl.io and the decision market, updated Futardio timeline."
|
||||||
---
|
---
|
||||||
|
|
||||||
## Launch Details
|
## Launch Details
|
||||||
|
|
@ -86,6 +86,5 @@ The self-custody wallet market is growing rapidly as users move away from centra
|
||||||
- Etnl.io Futardio raise: $500,000 target, $96 committed, refunding status (2026-03-09 to 2026-03-10)
|
- Etnl.io Futardio raise: $500,000 target, $96 committed, refunding status (2026-03-09 to 2026-03-10)
|
||||||
- Etnl.io product: Secure Enclave-based mobile wallet with hardware-level security
|
- Etnl.io product: Secure Enclave-based mobile wallet with hardware-level security
|
||||||
- Etnl.io team budget: $30,000/month
|
- Etnl.io team budget: $30,000/month
|
||||||
- Launch address: 4oiZeLhoDB9jGTFd28kJDKBYheL1Yg1XwR3qPTa69Rx9
|
|
||||||
- Token: 64S, mint: 64SnHgEfSdzpnmHEhh2niN8bcAjmhTyEQky2DKWBmeta
|
- Token: 64S, mint: 64SnHgEfSdzpnmHEhh2niN8bcAjmhTyEQky2DKWBmeta
|
||||||
- Futardio platform version: v0.7
|
- Futardio platform version: v0.7
|
||||||
|
|
|
||||||
|
|
@ -6,7 +6,7 @@ url: https://x.com/rocketresearchx
|
||||||
date: 2026-03-09
|
date: 2026-03-09
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: tweet
|
format: tweet
|
||||||
status: unprocessed
|
status: null-result
|
||||||
last_attempted: 2026-03-11
|
last_attempted: 2026-03-11
|
||||||
tags: [media, research, trading, market-analysis, solana]
|
tags: [media, research, trading, market-analysis, solana]
|
||||||
linked_set: metadao-x-landscape-2026-03
|
linked_set: metadao-x-landscape-2026-03
|
||||||
|
|
|
||||||
|
|
@ -1,341 +0,0 @@
|
||||||
---
|
|
||||||
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
|
|
||||||
|
|
@ -1,183 +0,0 @@
|
||||||
# Attribution Schema
|
|
||||||
|
|
||||||
Attribution tracks who contributed what to the knowledge base. Every claim traces back to the people and agents who produced it. Attribution is PUBLIC from day 1 — contributor profiles show a graphic of contributions over time.
|
|
||||||
|
|
||||||
## Design Principles
|
|
||||||
|
|
||||||
1. **Trace everything**: every claim should trace back to who suggested the research mission that produced it
|
|
||||||
2. **Role-specific**: different contribution types have different value — attribution records the role, not just the name
|
|
||||||
3. **Pseudonymous-first**: contributors use handles, not legal names. Handles persist across contributions.
|
|
||||||
4. **Git-native**: the Pentagon-Agent trailer in git commits is the foundation. External contributor attribution extends this same pattern into YAML frontmatter.
|
|
||||||
5. **Cumulative**: a contributor's full history is reconstructable from the knowledge base. No contribution is invisible.
|
|
||||||
|
|
||||||
## The Five Contributor Roles
|
|
||||||
|
|
||||||
| Role | What They Do | Example |
|
|
||||||
|------|-------------|---------|
|
|
||||||
| **sourcer** | Identifies the source material or research direction that led to this claim | "Look into Kalshi's revenue model" or shares an article |
|
|
||||||
| **extractor** | Extracts the specific claim from source material — separates signal from noise, writes the prose-as-title | Agent or human who reads the source and produces the claim file |
|
|
||||||
| **challenger** | Tests the claim through counter-evidence, boundary conditions, or adversarial review | "This doesn't hold when markets are thin" |
|
|
||||||
| **synthesizer** | Connects this claim to other claims, producing cross-domain insight | "This mechanism is isomorphic to X in health domain" |
|
|
||||||
| **reviewer** | Evaluates claim quality against the KB quality gates and approves/rejects | Leo's eval role, or peer reviewers |
|
|
||||||
|
|
||||||
A single person/agent can hold multiple roles on the same claim. A claim can have multiple people in the same role.
|
|
||||||
|
|
||||||
## Claim Frontmatter Extension
|
|
||||||
|
|
||||||
Add an `attribution` block to claim YAML frontmatter:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
---
|
|
||||||
type: claim
|
|
||||||
domain: internet-finance
|
|
||||||
description: "..."
|
|
||||||
confidence: likely
|
|
||||||
source: "Theia Research 2025 annual letter, analysis by Rio"
|
|
||||||
created: 2026-03-11
|
|
||||||
|
|
||||||
# Attribution (new)
|
|
||||||
attribution:
|
|
||||||
sourcer:
|
|
||||||
- handle: "m3taversal"
|
|
||||||
context: "directed research into Theia's investment thesis"
|
|
||||||
- handle: "@theiaresearch"
|
|
||||||
context: "published the annual letter"
|
|
||||||
extractor:
|
|
||||||
- handle: "rio"
|
|
||||||
agent_id: "760F7FE7-5D50-4C2E-8B7C-9F1A8FEE8A46"
|
|
||||||
challenger: []
|
|
||||||
synthesizer: []
|
|
||||||
reviewer:
|
|
||||||
- handle: "leo"
|
|
||||||
agent_id: "294C3CA1-0205-4668-82FA-B984D54F48AD"
|
|
||||||
---
|
|
||||||
```
|
|
||||||
|
|
||||||
## Attribution Fields
|
|
||||||
|
|
||||||
### Per-role entry
|
|
||||||
|
|
||||||
| Field | Type | Required | Description |
|
|
||||||
|-------|------|----------|-------------|
|
|
||||||
| handle | string | yes | Contributor's persistent pseudonymous identity |
|
|
||||||
| agent_id | UUID | if agent | Pentagon agent UUID (agents only) |
|
|
||||||
| context | string | no | What specifically this contributor did in this role |
|
|
||||||
| date | date | no | When the contribution was made (defaults to claim created date) |
|
|
||||||
|
|
||||||
### Role-specific notes
|
|
||||||
|
|
||||||
- **sourcer**: can be external (X handle, author name) or internal (agent, m3taversal). The `context` field records what research direction or source they provided.
|
|
||||||
- **extractor**: usually an agent. The `agent_id` field links to the Pentagon agent. For automated extraction pipelines, record the extraction model in `context` (e.g., "MiniMax M2.5 extract → Haiku 4.5 review").
|
|
||||||
- **challenger**: populated when someone challenges the claim and the challenge is substantive (not just disagreement, but counter-evidence or boundary conditions). Empty array until challenged.
|
|
||||||
- **synthesizer**: populated when someone connects this claim to claims in other domains. Cross-domain synthesis is the highest-value contribution type.
|
|
||||||
- **reviewer**: populated during PR review. Records who evaluated and approved.
|
|
||||||
|
|
||||||
## Backwards Compatibility
|
|
||||||
|
|
||||||
The existing `source` field continues to serve as a human-readable one-liner for quick reference. The `attribution` block provides the structured, queryable version. Both coexist:
|
|
||||||
|
|
||||||
- `source`: "Theia Research 2025 annual letter, analysis by Rio" (human-readable)
|
|
||||||
- `attribution`: structured role-by-role breakdown (machine-readable)
|
|
||||||
|
|
||||||
For claims created before attribution was introduced, `source` remains the only attribution data. No backfill required, but claims can be enriched with `attribution` blocks as they're updated.
|
|
||||||
|
|
||||||
## Git Trailer Integration
|
|
||||||
|
|
||||||
Agent contributions are also recorded in git commit trailers:
|
|
||||||
|
|
||||||
```
|
|
||||||
Pentagon-Agent: Rio <760F7FE7-5D50-4C2E-8B7C-9F1A8FEE8A46>
|
|
||||||
```
|
|
||||||
|
|
||||||
The git trailer records WHO committed the change. The YAML attribution records WHO contributed WHAT in WHICH ROLE. These are complementary:
|
|
||||||
- Git trailer = "who made this change to the repository"
|
|
||||||
- YAML attribution = "who produced this knowledge and in what capacity"
|
|
||||||
|
|
||||||
A single commit may create 10 claims. The trailer says Rio committed them. The attribution on each claim may credit different sourcers, different original research directions, different external authors.
|
|
||||||
|
|
||||||
## Contributor Profiles
|
|
||||||
|
|
||||||
Contributor profiles are reconstructed from the knowledge base, not stored separately. To build a profile:
|
|
||||||
|
|
||||||
1. **Query**: search all claim `attribution` blocks for a given `handle`
|
|
||||||
2. **Aggregate**: count contributions by role, domain, confidence level, date
|
|
||||||
3. **Visualize**: contribution-over-time graphic showing when and how they contributed
|
|
||||||
|
|
||||||
This means:
|
|
||||||
- No separate "contributor database" to maintain
|
|
||||||
- Profiles are always consistent with the actual KB state
|
|
||||||
- New contributions automatically appear in profiles
|
|
||||||
- Attribution disputes are resolved by editing claim frontmatter
|
|
||||||
|
|
||||||
### Person Entity Bridge
|
|
||||||
|
|
||||||
When a contributor has enough contributions to warrant tracking, their person entity (`entities/{domain}/{handle}.md`) gains `contributor: true` and links to their contributions:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# In person entity
|
|
||||||
contributor: true
|
|
||||||
contributions:
|
|
||||||
- role: sourcer
|
|
||||||
claim: "futarchy is manipulation-resistant..."
|
|
||||||
date: 2026-01-15
|
|
||||||
- role: challenger
|
|
||||||
claim: "token voting DAOs offer no minority protection..."
|
|
||||||
date: 2026-02-20
|
|
||||||
first_contribution: 2026-01-15
|
|
||||||
attribution_handle: "@theiaresearch"
|
|
||||||
```
|
|
||||||
|
|
||||||
## Governance
|
|
||||||
|
|
||||||
- Attribution is added at extraction time (extractor + sourcer) and updated during review (reviewer) and challenge (challenger)
|
|
||||||
- Synthesizer attribution is added when cross-domain connections are made, which may happen well after initial creation
|
|
||||||
- Disputes about attribution are resolved through the normal PR process
|
|
||||||
- Removing attribution requires justification (e.g., the sourcer was misidentified)
|
|
||||||
|
|
||||||
## Contribution Weights
|
|
||||||
|
|
||||||
Role weights determine how much each contribution type counts toward a contributor's weighted score. Weights are **global policy**, not per-claim data — they live in `schemas/contribution-weights.yaml`, not in claim frontmatter.
|
|
||||||
|
|
||||||
Why weights are global, not per-claim:
|
|
||||||
1. Weights are policy (how much we value each role), not data (who did what)
|
|
||||||
2. Weights evolve as bottlenecks shift — updating one config file beats migrating 400+ claims
|
|
||||||
3. Per-claim weights create gaming incentive to inflate role on high-value claims
|
|
||||||
|
|
||||||
The build pipeline reads `contribution-weights.yaml` and multiplies role counts × weights to produce weighted scores. The frontend displays both raw counts (by role) and the weighted score.
|
|
||||||
|
|
||||||
See `schemas/contribution-weights.yaml` for current weights and rationale.
|
|
||||||
|
|
||||||
## Build Artifacts
|
|
||||||
|
|
||||||
The website build pipeline (extract-graph-data.py) produces a `contributors.json` artifact alongside graph-data.json and claims-context.json:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"contributors": [
|
|
||||||
{
|
|
||||||
"handle": "naval",
|
|
||||||
"roles": {"sourcer": 12, "extractor": 0, "challenger": 3, "synthesizer": 1, "reviewer": 0},
|
|
||||||
"weighted_score": 5.4,
|
|
||||||
"domains": {"internet-finance": 8, "grand-strategy": 5, "ai-alignment": 3},
|
|
||||||
"first_contribution": "2026-02-15",
|
|
||||||
"latest_contribution": "2026-03-11",
|
|
||||||
"claim_count": 16,
|
|
||||||
"timeline": [
|
|
||||||
{"date": "2026-02", "count": 3, "domains": ["internet-finance"]},
|
|
||||||
{"date": "2026-03", "count": 13, "domains": ["internet-finance", "grand-strategy"]}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
This is a static file rebuilt on every merge to main (~15 minute staleness). The frontend reads it at page load — no API or runtime queries needed.
|
|
||||||
|
|
||||||
**Timeline**: Monthly granularity. Used by the frontend for contribution heatmap or sparkline graphic (Cory requirement).
|
|
||||||
|
|
||||||
## Implementation Priority
|
|
||||||
|
|
||||||
1. **Now**: Add `attribution` block to new claims going forward. No backfill required.
|
|
||||||
2. **Soon**: Rhea adds attribution aggregation pass to extract-graph-data.py, producing contributors.json.
|
|
||||||
3. **Soon**: Frontend contributor profile pages — handle + sparkline + domain pie + top claims by role.
|
|
||||||
4. **Later**: Automated attribution from the extraction pipeline (MiniMax → Haiku → agent).
|
|
||||||
|
|
@ -37,7 +37,6 @@ challenged_by: [] # list of counter-evidence or counter-claims
|
||||||
| depends_on | list | Evidence and claims this builds on (the reasoning chain) |
|
| depends_on | list | Evidence and claims this builds on (the reasoning chain) |
|
||||||
| challenged_by | list | Counter-evidence or counter-claims (disagreement tracking) |
|
| challenged_by | list | Counter-evidence or counter-claims (disagreement tracking) |
|
||||||
| secondary_domains | list | Other domains this claim is relevant to |
|
| secondary_domains | list | Other domains this claim is relevant to |
|
||||||
| attribution | object | Role-specific contributor tracking — see `schemas/attribution.md` |
|
|
||||||
|
|
||||||
## Governance
|
## Governance
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,30 +0,0 @@
|
||||||
# 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
|
|
||||||
Loading…
Reference in a new issue