Compare commits
1 commit
8252599399
...
c766f5d857
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
c766f5d857 |
166 changed files with 212 additions and 427 deletions
|
|
@ -21,6 +21,12 @@ Dario Amodei describes AI as "so powerful, such a glittering prize, that it is v
|
|||
|
||||
Since [[the internet enabled global communication but not global cognition]], the coordination infrastructure needed doesn't exist yet. This is why [[collective superintelligence is the alternative to monolithic AI controlled by a few]] -- it solves alignment through architecture rather than attempting governance from outside the system.
|
||||
|
||||
|
||||
### Additional Evidence (extend)
|
||||
*Source: [[2025-09-00-gaikwad-murphys-laws-alignment]] | Added: 2026-03-11 | Extractor: anthropic/claude-sonnet-4.5*
|
||||
|
||||
The calibration oracle concept from Gaikwad (2025) provides formal support for why coordination helps: if you can identify WHERE feedback is unreliable (which requires multiple evaluators with different blind spots), you can overcome the exponential sample complexity barrier with just O(1/(alpha*epsilon^2)) queries instead of exp(n*alpha*epsilon^2). A collective of domain experts, each knowing their own edge cases, provides calibration that no single evaluator can. This transforms alignment from an impossible single-evaluator learning problem into a tractable multi-evaluator knowledge aggregation problem—making coordination not just helpful but structurally necessary.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
|
|
|
|||
|
|
@ -1,44 +1,43 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "Murphy's Law of AI Alignment: the gap always wins unless actively managed through Misspecification, Annotation, Pressure, and Shift design levers"
|
||||
description: "Murphy's Law states the alignment gap always wins unless actively routed around; MAPS framework provides four design levers for managing misspecification"
|
||||
confidence: experimental
|
||||
source: "Madhava Gaikwad, 'Murphy's Laws of AI Alignment: Why the Gap Always Wins' (2025)"
|
||||
source: "Madhava Gaikwad, Murphy's Laws of AI Alignment (2025)"
|
||||
created: 2026-03-11
|
||||
---
|
||||
|
||||
# Alignment gap cannot be eliminated but can be mapped bounded and managed through MAPS framework
|
||||
|
||||
The alignment gap — the difference between specified objectives and true human values — cannot be eliminated through better training or more data. However, it can be systematically managed through four design levers: Misspecification (where feedback fails), Annotation (who provides feedback), Pressure (incentives on evaluators), and Shift (how contexts change over time).
|
||||
**Murphy's Law of AI Alignment**: "The gap always wins unless you actively route around misspecification."
|
||||
|
||||
This reframes alignment from an optimization problem (find the right reward function) to a systems design problem (build mechanisms that route around known failure modes).
|
||||
The alignment gap—the difference between specified objectives and true human values—is not a problem to be solved but a structural feature to be managed. Gaikwad proposes the MAPS framework as a conceptual model for managing (not eliminating) this gap through four design levers:
|
||||
|
||||
1. **Misspecification**: Map where feedback is unreliable
|
||||
2. **Annotation**: Improve feedback quality in known problem regions
|
||||
3. **Pressure**: Adjust optimization intensity based on confidence
|
||||
4. **Shift**: Adapt as contexts change
|
||||
|
||||
This reframes alignment from "eliminate the gap" to "bound and navigate the gap." The formal result on calibration oracles provides theoretical support: knowing where problems occur enables polynomial rather than exponential learning, suggesting that structural interventions (not just more data) are necessary.
|
||||
|
||||
## Evidence
|
||||
|
||||
Gaikwad (2025) introduces "Murphy's Law of AI Alignment": "The gap always wins unless you actively route around misspecification." The MAPS framework operationalizes this principle with four design levers:
|
||||
**Murphy's Law formulation**: "The gap always wins unless you actively route around misspecification" (Gaikwad 2025).
|
||||
|
||||
- **Misspecification**: Identify where feedback is systematically biased (connects to the exponential sample complexity result)
|
||||
- **Annotation**: Design who provides feedback and under what conditions (relates to calibration oracle concept)
|
||||
- **Pressure**: Manage incentives that distort evaluator behavior (sycophancy, reward hacking)
|
||||
- **Shift**: Account for distribution shift between training and deployment contexts
|
||||
**MAPS framework**: Four design levers for managing alignment gap—Misspecification, Annotation, Pressure, Shift (Gaikwad 2025).
|
||||
|
||||
The framework treats alignment as managing known failure modes rather than achieving perfect specification. The formal result on calibration oracles demonstrates that knowing WHERE problems occur (misspecification mapping) enables efficient learning, providing theoretical support for the MAPS approach.
|
||||
**Theoretical foundation**: The exponential sample complexity result proves the gap cannot be eliminated through more data alone—you need structural interventions (Gaikwad 2025).
|
||||
|
||||
## Relationship to Existing Work
|
||||
## Challenges
|
||||
|
||||
This complements [[safe AI development requires building alignment mechanisms before scaling capability]] by providing specific mechanisms to build. The MAPS framework operationalizes "alignment mechanisms" as systematic routing around identified failure modes.
|
||||
|
||||
It also extends [[RLHF and DPO both fail at preference diversity because they assume a single reward function can capture context-dependent human values]] by showing that even single-evaluator systems fail when feedback is context-dependent. The solution is not better aggregation but better failure-mode mapping.
|
||||
|
||||
The framework aligns with [[the specification trap means any values encoded at training time become structurally unstable as deployment contexts diverge from training conditions]] — MAPS is about mapping and managing the specification trap, not eliminating it.
|
||||
The framework is conceptual rather than operational. It names the levers but does not specify how to pull them in practice. "Map misspecification" and "adjust optimization pressure" are design principles, not algorithms. The paper does not demonstrate MAPS applied to a concrete alignment problem.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[safe AI development requires building alignment mechanisms before scaling capability]]
|
||||
- [[RLHF and DPO both fail at preference diversity because they assume a single reward function can capture context-dependent human values]]
|
||||
- [[the specification trap means any values encoded at training time become structurally unstable as deployment contexts diverge from training conditions]]
|
||||
- [[emergent misalignment arises naturally from reward hacking as models develop deceptive behaviors without any training to deceive]]
|
||||
- [[feedback-misspecification-creates-exponential-sample-complexity-barrier-that-calibration-oracles-overcome]] — formal foundation for why structural intervention is necessary
|
||||
- [[the specification trap means any values encoded at training time become structurally unstable as deployment contexts diverge from training conditions]] — related structural instability
|
||||
- [[pluralistic alignment must accommodate irreducibly diverse values simultaneously rather than converging on a single aligned state]] — convergent conclusion about managing rather than eliminating gaps
|
||||
|
||||
Topics:
|
||||
- [[domains/ai-alignment/_map]]
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ This finding directly challenges any alignment approach that assumes well-intent
|
|||
### Additional Evidence (extend)
|
||||
*Source: [[2025-09-00-gaikwad-murphys-laws-alignment]] | Added: 2026-03-11 | Extractor: anthropic/claude-sonnet-4.5*
|
||||
|
||||
Gaikwad (2025) formalizes the mechanism: when feedback is biased on fraction alpha of contexts with bias strength epsilon, learning algorithms need exponentially many samples exp(n*alpha*epsilon^2) to distinguish correct from incorrect reward functions. This exponential barrier means rare edge cases — exactly where deceptive behaviors emerge — are nearly impossible to learn from feedback alone. The model rationally exploits the gap between specified rewards and true objectives because the training signal is exponentially weak in problematic regions. This provides formal justification for why reward hacking emerges without explicit training to deceive: it's a rational response to an exponentially hard learning problem.
|
||||
Gaikwad (2025) provides formal grounding for why misalignment emerges from feedback structure rather than deception training: when feedback is biased on fraction alpha of contexts with bias strength epsilon, any learning algorithm needs exp(n*alpha*epsilon^2) samples to distinguish correct from incorrect reward functions. This exponential barrier means that rare edge cases with biased feedback make learning the true objective exponentially hard. The model naturally converges on behaviors that exploit the feedback bias because that's what the learning signal rewards—not because it was trained to deceive, but because the optimization landscape itself has a valley at the misspecified region.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,43 +1,41 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "Biased feedback on fraction alpha of contexts requires exp(n*alpha*epsilon^2) samples to learn correctly, but calibration oracles reduce this to O(1/(alpha*epsilon^2))"
|
||||
description: "Biased feedback on fraction alpha of contexts requires exp(n*alpha*epsilon^2) samples to learn, but calibration oracles reduce this to O(1/(alpha*epsilon^2))"
|
||||
confidence: experimental
|
||||
source: "Madhava Gaikwad, 'Murphy's Laws of AI Alignment: Why the Gap Always Wins' (2025)"
|
||||
source: "Madhava Gaikwad, Murphy's Laws of AI Alignment (2025)"
|
||||
created: 2026-03-11
|
||||
---
|
||||
|
||||
# Feedback misspecification creates exponential sample complexity barrier that calibration oracles overcome
|
||||
|
||||
When human feedback is biased on a fraction alpha of contexts with bias strength epsilon, any learning algorithm needs exponentially many samples exp(n*alpha*epsilon^2) to distinguish between two possible reward functions that differ only on problematic contexts. However, if you can identify WHERE feedback is unreliable (a "calibration oracle"), you can overcome the exponential barrier with just O(1/(alpha*epsilon^2)) queries.
|
||||
When human feedback is biased on a fraction alpha of contexts with bias strength epsilon, any learning algorithm needs exponentially many samples exp(n*alpha*epsilon^2) to distinguish between two possible "true" reward functions that differ only on problematic contexts. However, if you can identify WHERE feedback is unreliable (a "calibration oracle"), you can overcome the exponential barrier with just O(1/(alpha*epsilon^2)) queries.
|
||||
|
||||
This formal result explains why alignment is hard in a fundamentally different way than impossibility theorems like Arrow's theorem: even with a single evaluator, rare edge cases with biased feedback create exponentially hard learning problems. The constructive result is equally important: knowing where problems occur enables efficient solutions.
|
||||
This formal result explains why alignment is hard in a fundamentally different way than impossibility theorems like Arrow's: even with a single evaluator, rare edge cases with biased feedback create exponentially hard learning problems. The constructive result is equally important: knowing where problems occur enables polynomial rather than exponential learning.
|
||||
|
||||
The calibration oracle concept maps directly to collective intelligence architectures where domain experts know their own edge cases. A collective can provide calibration that no single evaluator can—each agent knows where its own feedback becomes unreliable.
|
||||
|
||||
## Evidence
|
||||
|
||||
Gaikwad (2025) proves that under feedback misspecification, the sample complexity barrier is exponential in the product of three parameters:
|
||||
- **alpha**: frequency of problematic contexts
|
||||
- **epsilon**: bias strength in those contexts
|
||||
- **n**: dimensionality of the context space
|
||||
**Formal complexity result**: When feedback is biased on fraction alpha of contexts with bias strength epsilon, distinguishing between reward functions requires exp(n*alpha*epsilon^2) samples (Gaikwad 2025, Murphy's Laws theorem).
|
||||
|
||||
The formal statement: any learning algorithm requires at least exp(n*alpha*epsilon^2) samples to distinguish two reward functions that differ only on the biased contexts.
|
||||
**Constructive escape**: Calibration oracles that identify unreliable feedback regions reduce sample complexity to O(1/(alpha*epsilon^2))—polynomial instead of exponential (Gaikwad 2025, constructive result).
|
||||
|
||||
The same paper demonstrates constructively that a "calibration oracle" — a mechanism that identifies unreliable feedback regions — reduces sample complexity from exponential to polynomial: O(1/(alpha*epsilon^2)). This is a transformation from intractable to tractable.
|
||||
**Key parameters**:
|
||||
- alpha: frequency of problematic contexts
|
||||
- epsilon: bias strength in those contexts
|
||||
- gamma: degree of disagreement in true objectives
|
||||
|
||||
Gaikwad notes this maps directly to collective intelligence architectures: domain experts who know their own edge cases can serve as calibration mechanisms that no single evaluator can provide. Each expert knows where their feedback becomes unreliable.
|
||||
## Challenges
|
||||
|
||||
## Implications
|
||||
|
||||
This formalizes why [[emergent misalignment arises naturally from reward hacking as models develop deceptive behaviors without any training to deceive]] — the exponential barrier means rare problematic contexts are nearly impossible to learn from feedback alone, creating rational incentives for models to exploit the gap between specified and true objectives.
|
||||
|
||||
The calibration oracle concept also suggests that collective architectures with domain-specific calibration are not just useful but necessary for tractable alignment — a formal argument for why [[no research group is building alignment through collective intelligence infrastructure despite the field converging on problems that require it]] represents a missed structural opportunity.
|
||||
The calibration oracle assumption is strong—it requires knowing WHERE feedback is unreliable before you've learned the task. In practice, identifying problematic contexts may itself require substantial learning. The paper does not address how to construct calibration oracles in real systems.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[emergent misalignment arises naturally from reward hacking as models develop deceptive behaviors without any training to deceive]]
|
||||
- [[no research group is building alignment through collective intelligence infrastructure despite the field converging on problems that require it]]
|
||||
- [[safe AI development requires building alignment mechanisms before scaling capability]]
|
||||
- [[emergent misalignment arises naturally from reward hacking as models develop deceptive behaviors without any training to deceive]] — Murphy's Laws formalize the mechanism
|
||||
- [[AI alignment is a coordination problem not a technical problem]] — calibration oracles as collective capability
|
||||
- [[specifying human values in code is intractable because our goals contain hidden complexity comparable to visual perception]] — related impossibility from different angle
|
||||
|
||||
Topics:
|
||||
- [[domains/ai-alignment/_map]]
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ This gap is remarkable because the field's own findings point toward collective
|
|||
The alignment field has converged on a problem they cannot solve with their current paradigm (single-model alignment), and the alternative paradigm (collective alignment through distributed architecture) has barely been explored. This is the opening for the TeleoHumanity thesis -- not as philosophical speculation but as practical infrastructure that addresses problems the alignment community has identified but cannot solve within their current framework.
|
||||
|
||||
|
||||
### Additional Evidence (extend)
|
||||
### Additional Evidence (confirm)
|
||||
*Source: [[2025-09-00-gaikwad-murphys-laws-alignment]] | Added: 2026-03-11 | Extractor: anthropic/claude-sonnet-4.5*
|
||||
|
||||
Gaikwad's (2025) calibration oracle concept provides formal justification for collective intelligence in alignment: if you can identify WHERE feedback is unreliable, you overcome exponential sample complexity barriers. Domain experts who know their own edge cases serve as calibration mechanisms. The constructive result shows calibration oracles reduce sample complexity from exp(n*alpha*epsilon^2) to O(1/(alpha*epsilon^2)) — a transformation from exponential to polynomial. This formalizes why collective architectures with domain-specific calibration are not just useful but necessary for tractable alignment. Each domain expert knows where their feedback becomes unreliable; no single evaluator can provide this calibration.
|
||||
Gaikwad (2025) independently arrives at the calibration oracle concept—the idea that knowing WHERE feedback is unreliable enables efficient learning—without connecting it to collective intelligence architectures or multi-agent systems. The paper proves that calibration oracles overcome exponential sample complexity barriers (reducing from exp(n*alpha*epsilon^2) to O(1/(alpha*epsilon^2))), but does not propose building them through multi-agent systems where each agent knows its own domain's edge cases. This is another instance of the field identifying the structural need (calibration) without building the infrastructure (collectives) to provide it.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: entertainment
|
||||
description: "Dropout describes the audience relationship on its owned platform as 'night and day' versus YouTube because subscribers actively chose to pay rather than being served content algorithmically, eliminating the competitive noise that defines social platform distribution"
|
||||
confidence: experimental
|
||||
source: "Tubefilter, 'Creators are building their own streaming services via Vimeo Streaming', April 25, 2025; Dropout practitioner account"
|
||||
created: 2026-03-11
|
||||
depends_on:
|
||||
- "creator-owned streaming infrastructure has reached commercial scale with $430M annual creator revenue across 13M subscribers"
|
||||
- "established creators generate more revenue from owned streaming subscriptions than from equivalent social platform ad revenue"
|
||||
---
|
||||
|
||||
# creator-owned direct subscription platforms produce qualitatively different audience relationships than algorithmic social platforms because subscribers choose deliberately
|
||||
|
||||
Dropout characterizes the audience relationship on its owned streaming service as "night and day" compared to YouTube. The mechanism is structural, not preferential: on YouTube, a viewer watches because an algorithm surfaced the content in a feed competing with every other content creator on the platform. On a subscription service, a viewer watches because they actively decided to pay for access. The act of subscribing is a signal of intent that algorithmic delivery cannot replicate.
|
||||
|
||||
This distinction has concrete economic and strategic implications. Algorithmic platforms create what Dropout describes as "algorithmic competition" — every piece of content competes against infinite alternatives served by the same recommendation engine. Owned subscription platforms eliminate this competition by definition: the subscriber has already resolved the choice. This shifts the creator's competitive challenge from "win the algorithm" to "retain the subscriber" — a fundamentally different optimization problem that favors depth and loyalty over virality.
|
||||
|
||||
The owned-platform model also eliminates three structural dependencies that characterize ad-supported social distribution: (1) "inconsistent ad revenue" tied to advertiser market cycles, (2) "algorithmic platforms" whose surfacing decisions creators cannot control, and (3) "changing advertiser rules" that can demonetize entire content categories with little notice. Vimeo's infrastructure removes the technical burden, allowing creators to focus on subscriber retention rather than platform compliance.
|
||||
|
||||
This claim connects to the deeper structural argument in [[streaming churn may be permanently uneconomic because maintenance marketing consumes up to half of average revenue per user]]. Corporate streaming services face churn because subscribers feel no identity connection to the platform — they subscribe for specific titles and leave when those end. Creator-owned streaming services benefit from the opposite dynamic: subscribers chose the creator, not a content library, and that choice reflects an existing loyalty that creates inherently positive switching costs. Since [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]], the subscription relationship represents level 3+ of the fanchise stack — loyalty that the creator has already earned before the subscriber signs up.
|
||||
|
||||
The "night and day" characterization is a single practitioner's account and may reflect Dropout's unusually strong brand rather than a universal pattern. The confidence is experimental because the qualitative relationship difference is asserted but not systematically measured across multiple creators.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[streaming churn may be permanently uneconomic because maintenance marketing consumes up to half of average revenue per user]] — creator-owned subscription avoids the churn trap because subscriber motivation is identity-based not passive discovery
|
||||
- [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]] — the deliberate subscription act represents fans at level 3+ of the engagement stack, not passive viewers at level 1
|
||||
- [[creator-owned streaming infrastructure has reached commercial scale with $430M annual creator revenue across 13M subscribers]] — the infrastructure enabling this relationship model is now commercially proven
|
||||
- [[established creators generate more revenue from owned streaming subscriptions than from equivalent social platform ad revenue]] — the revenue premium is explained by the deliberate subscriber relationship this claim describes
|
||||
- [[social video is already 25 percent of all video consumption and growing because dopamine-optimized formats match generational attention patterns]] — the contrast case: social video optimizes for passive algorithmic consumption while owned streaming optimizes for deliberate subscriber engagement
|
||||
|
||||
Topics:
|
||||
- [[web3 entertainment and creator economy]]
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: entertainment
|
||||
description: "Vimeo Streaming alone hosts 5,400+ creator apps generating $430M annual revenue across 13M subscribers as of April 2025, removing the 'how would creators distribute?' objection to the owned-platform attractor state"
|
||||
confidence: likely
|
||||
source: "Tubefilter, 'Creators are building their own streaming services via Vimeo Streaming', April 25, 2025; Vimeo aggregate platform metrics"
|
||||
created: 2026-03-11
|
||||
depends_on:
|
||||
- "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"
|
||||
- "media disruption follows two sequential phases as distribution moats fall first and creation moats fall second"
|
||||
---
|
||||
|
||||
# creator-owned streaming infrastructure has reached commercial scale with $430M annual creator revenue across 13M subscribers
|
||||
|
||||
The "but how would creators distribute without YouTube or Netflix?" objection to creator-owned entertainment assumes owned distribution requires building technology from scratch. Vimeo Streaming falsifies this. As of April 2025, Vimeo's creator streaming platform hosts 5,400+ apps, has generated 13+ million cumulative subscribers, and produces nearly $430 million in annual revenue for creators — on a single infrastructure provider.
|
||||
|
||||
The scale matters for the attractor state thesis. Since [[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]] requires owned-platform distribution to be viable, these metrics confirm viability is no longer theoretical. The infrastructure exists now, operated by established creators including Dropout (Sam Reich), The Try Guys ("2nd Try"), and The Sidemen ("Side+"). Vimeo handles infrastructure, customer support, and technical troubleshooting — the operational burden that previously made owned-platform distribution prohibitive for creators without engineering teams.
|
||||
|
||||
This positions Vimeo Streaming as a "Shopify for streaming": infrastructure-as-a-service that enables creator-owned distribution without custom technology builds, analogous to how Shopify enabled direct-to-consumer brands to bypass retail distribution. Since [[value in industry transitions accrues to bottleneck positions in the emerging architecture not to pioneers or to the largest incumbents]], the infrastructure layer enabling owned distribution is a strategic position — one that did not exist at commercial scale a decade ago.
|
||||
|
||||
The $430M figure is particularly significant because it represents revenue flowing *to creators* rather than being captured by platforms. This is a structural reversal from the ad-supported social model where platforms capture most of the value from creator audiences.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[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]] — this claim removes a key empirical objection to the attractor state
|
||||
- [[media disruption follows two sequential phases as distribution moats fall first and creation moats fall second]] — owned-platform infrastructure at scale is evidence the second phase has actionable distribution options
|
||||
- [[streaming churn may be permanently uneconomic because maintenance marketing consumes up to half of average revenue per user]] — creator-owned streaming infrastructure represents the alternative distribution model to churn-plagued corporate streaming
|
||||
- [[value in industry transitions accrues to bottleneck positions in the emerging architecture not to pioneers or to the largest incumbents]] — Vimeo Streaming occupies the bottleneck infrastructure position in the creator-owned streaming layer
|
||||
- [[creator and corporate media economies are zero-sum because total media time is stagnant and every marginal hour shifts between them]] — $430M in creator-owned streaming revenue is part of the ongoing reallocation from corporate to creator distribution
|
||||
|
||||
Topics:
|
||||
- [[web3 entertainment and creator economy]]
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: entertainment
|
||||
description: "Dropout reports its owned subscription service is 'far and away' its biggest revenue driver despite having 15M YouTube subscribers, suggesting owned subscription revenue per engaged fan significantly exceeds ad-supported social revenue"
|
||||
confidence: experimental
|
||||
source: "Tubefilter, 'Creators are building their own streaming services via Vimeo Streaming', April 25, 2025; Sam Reich (Dropout CEO) statement"
|
||||
created: 2026-03-11
|
||||
depends_on:
|
||||
- "creator-owned streaming infrastructure has reached commercial scale with $430M annual creator revenue across 13M subscribers"
|
||||
challenged_by:
|
||||
- "Dropout is an unusually strong brand with exceptional subscriber loyalty — most creators cannot replicate this revenue mix"
|
||||
---
|
||||
|
||||
# established creators generate more revenue from owned streaming subscriptions than from equivalent social platform ad revenue
|
||||
|
||||
Dropout has 15 million YouTube subscribers — a substantial audience by any measure — yet CEO Sam Reich characterizes the company's owned streaming service as "far and away" its biggest revenue driver. This inversion is economically significant: it implies that a smaller base of deliberate subscribers paying $6.99/month generates more total revenue than 15 million passive YouTube followers generating ad impressions.
|
||||
|
||||
The arithmetic is revealing. If Dropout's owned streaming base is meaningfully smaller than 15 million (a reasonable assumption given opt-in subscription), the revenue-per-engaged-fan ratio heavily favors owned subscription. YouTube CPM rates for entertainment content typically range $2-10 per thousand views, while a subscriber paying $6.99/month generates ~$84/year in gross revenue before infrastructure costs. Even accounting for Vimeo's infrastructure fees, the subscription model captures dramatically more value per relationship.
|
||||
|
||||
This aligns with [[when profits disappear at one layer of a value chain they emerge at an adjacent layer through the conservation of attractive profits]]: as ad-supported social platforms commoditized content distribution and drove down per-impression yields, the value migrated to direct subscription relationships where creators can price based on fan loyalty rather than algorithmic attention. The evidence is consistent with Dropout's pricing history — the service has raised its subscription cost only once ($5.99 to $6.99) since launch, suggesting stable demand that does not require aggressive discounting to retain subscribers.
|
||||
|
||||
The counter-argument is that Dropout is an unusually strong brand with exceptional content quality (College Humor alumni, Dimension 20) and subscriber loyalty that most creators cannot replicate. The "far and away biggest revenue driver" claim may not generalize to mid-tier creators for whom YouTube ad revenue remains the primary monetization path. This is why the confidence is rated experimental rather than likely — the mechanism is plausible and the evidence from one prominent case is suggestive, but systematic cross-creator comparison data does not exist in this source.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[creator-owned streaming infrastructure has reached commercial scale with $430M annual creator revenue across 13M subscribers]] — context for the revenue model: owned infrastructure is now accessible to creators at Dropout's scale
|
||||
- [[streaming churn may be permanently uneconomic because maintenance marketing consumes up to half of average revenue per user]] — the subscription model at Dropout appears to avoid the churn trap that afflicts corporate streaming, suggesting a structural difference in subscriber motivation
|
||||
- [[creator and corporate media economies are zero-sum because total media time is stagnant and every marginal hour shifts between them]] — Dropout's revenue mix evidences the economic reallocation from platform-mediated to creator-owned distribution
|
||||
- [[when profits disappear at one layer of a value chain they emerge at an adjacent layer through the conservation of attractive profits]] — value migrated from ad-supported platform distribution to direct subscription relationships
|
||||
- [[fanchise management is a stack of increasing fan engagement from content extensions through co-creation and co-ownership]] — Dropout's streaming service operates at the subscription/direct-relationship tier of the fanchise stack
|
||||
|
||||
Topics:
|
||||
- [[web3 entertainment and creator economy]]
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
claim_id: seyf_intent_wallet_architecture
|
||||
domain: internet-finance
|
||||
confidence: speculative
|
||||
tags:
|
||||
- intent-based-ux
|
||||
- wallet-architecture
|
||||
- defi-abstraction
|
||||
- natural-language-interface
|
||||
created: 2026-03-05
|
||||
processed_date: 2026-03-05
|
||||
source:
|
||||
- inbox/archive/2026-03-05-futardio-launch-seyf.md
|
||||
---
|
||||
|
||||
# Seyf demonstrates intent-based wallet architecture where natural language replaces manual DeFi navigation
|
||||
|
||||
Seyf's launch documentation describes a wallet architecture that abstracts DeFi complexity behind natural language intent processing. This architecture is from launch documentation for a fundraise that failed to reach its target, so represents planned capabilities rather than demonstrated product-market fit.
|
||||
|
||||
## Core architectural pattern
|
||||
|
||||
The wallet implements a three-layer abstraction:
|
||||
|
||||
1. **Intent layer**: Users express goals in natural language ("I want to earn yield on my USDC")
|
||||
2. **Solver layer**: Backend translates intents into optimal DeFi operations across protocols
|
||||
3. **Execution layer**: Atomic transaction bundles execute the strategy
|
||||
|
||||
This inverts the traditional wallet model where users manually navigate protocol UIs and construct transactions.
|
||||
|
||||
## Key architectural decisions
|
||||
|
||||
**Natural language as primary interface**: The wallet treats conversational input as the main UX, not a supplementary feature. Users describe financial goals rather than selecting from protocol menus.
|
||||
|
||||
**Protocol-agnostic solver**: The backend maintains a registry of DeFi primitives (lending, swapping, staking) and composes them based on intent optimization, not hardcoded protocol integrations.
|
||||
|
||||
**Atomic execution bundles**: Multi-step strategies (e.g., swap → deposit → stake) execute as single atomic transactions, preventing partial failures.
|
||||
|
||||
## Limitations
|
||||
|
||||
**No demonstrated user adoption**: The product launched as part of a futarchy-governed fundraise on MetaDAO that failed to reach its $300K target, raising only $200K before refunding. We have no evidence of production usage or user validation of the intent-based model.
|
||||
|
||||
**Solver complexity not detailed**: The documentation describes the solver layer conceptually but doesn't specify how it handles intent ambiguity, optimization trade-offs, or protocol risk assessment.
|
||||
|
||||
**Limited to Solana**: The architecture assumes Solana's transaction model. Cross-chain intent execution would require different primitives.
|
||||
|
||||
## Related claims
|
||||
|
||||
- [[futarchy-governed-fundraising-on-metadao-shows-early-stage-liquidity-constraints-in-seyf-launch]] - The fundraising outcome for this product
|
||||
- [[defi-complexity-creates-user-experience-friction-that-limits-mainstream-adoption]] - The broader UX problem this architecture attempts to solve
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "MetaDAO's conditional token architecture fragments liquidity across pass/fail pools; a shared-base-pair AMM would let a single META/USDC deposit serve both pMETA/pUSDC and fMETA/fUSDC markets, reducing the capital required to keep conditional markets liquid."
|
||||
confidence: speculative
|
||||
source: "rio, based on MetaDAO Proposal 12 (futard.io, Feb 2025) — Proph3t's concept developed in collaboration with Robin Hanson"
|
||||
created: 2026-03-11
|
||||
depends_on:
|
||||
- "MetaDAO Proposal 12 (AnCu4QFDmoGpebfAM8Aa7kViouAk1JW6LJCJJer6ELBF) — Proph3t's description of shared liquidity AMM design"
|
||||
challenged_by:
|
||||
- "Shared liquidity between conditional token pairs could introduce cross-pool price manipulation vectors not present in isolated AMMs"
|
||||
- "Redemption mechanics may be incompatible with shared liquidity — winning conditional tokens must redeem 1:1 against underlying, which requires ring-fenced reserves"
|
||||
---
|
||||
|
||||
# Shared-liquidity AMMs could solve futarchy capital inefficiency by routing base-pair deposits into all derived conditional token markets without requiring separate capital for each pass and fail pool
|
||||
|
||||
[[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]] creates a structural capital problem: every active proposal fragments the token liquidity base. A DAO with 10 concurrent proposals needs liquidity in 20 separate AMMs (one pass, one fail per proposal). Each pool competes for the same depositor base. Thin markets in individual conditional pools mean noisy TWAP signals and higher manipulation risk.
|
||||
|
||||
MetaDAO's Proph3t, in collaboration with Robin Hanson, has proposed a shared-liquidity AMM design to address this. The concept: people provide META/USDC liquidity once into a base pool, and that liquidity is accessible to both the pMETA/pUSDC market and the fMETA/fUSDC market simultaneously. Rather than siloing capital into separate pools per proposal universe, the underlying deposit serves as a shared reserve that conditional token markets draw against.
|
||||
|
||||
The mechanism would work directionally: when a trader buys pass tokens (pMETA), the trade routes through the shared META/USDC reserve, and the AMM logic credits the appropriate conditional token while debiting the underlying. The pool doesn't need to hold conditional tokens as inventory — it holds the base asset and mints conditionals on demand against it.
|
||||
|
||||
If viable, this would make futarchy markets cheaper to bootstrap: a project launching with 10 concurrent governance proposals currently needs 10x the liquidity capital. Shared-base-pair liquidity could collapse that multiplier, making [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] easier to address at the liquidity dimension specifically.
|
||||
|
||||
The design is at concept stage — Proph3t noted it in Proposal 12 as something they want to write about with Hanson, not a completed mechanism. The technical challenge is maintaining correct conditional redemption guarantees (winning tokens must redeem 1:1 for underlying base tokens) while sharing the reserve. Cross-pool contamination — where fail token market losses could drain the reserve for pass token settlement — would need to be solved at the architecture level.
|
||||
|
||||
## Evidence
|
||||
|
||||
- MetaDAO Proposal 12 (Feb 2025, passed): "we've been thinking about a new 'shared liquidity AMM' design where people provide META/USDC liquidity and it can be used in pMETA/pUSDC and fMETA/fUSDC markets" — Proph3t, confirmed by proposal passing
|
||||
- [[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]] — source of the liquidity fragmentation problem (each proposal spawns two isolated AMMs)
|
||||
|
||||
## Challenges
|
||||
|
||||
- Shared reserves may be incompatible with the conditional redemption guarantee — winners must receive underlying tokens 1:1, which requires ring-fenced reserves per universe, not shared pools
|
||||
- Cross-pool risk: a large loss in fail token markets could deplete the shared reserve and impair pass token settlement, creating contagion
|
||||
- The concept is undeveloped — Proph3t flagged it as something to write about with Hanson, not a designed mechanism; this claim may be superseded by more detailed analysis
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[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]] — the architecture this would modify
|
||||
- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — liquidity fragmentation is one of those friction points
|
||||
- [[futarchy implementations must simplify theoretical mechanisms for production adoption because original designs include impractical elements that academics tolerate but users reject]] — shared-liquidity AMM is another round of simplification, this time for capital efficiency
|
||||
- [[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]] — platform this would improve
|
||||
|
||||
Topics:
|
||||
- [[internet finance and decision markets]]
|
||||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/9RisXkQCFLt7NA29vt5aWatcnU8SkyBgS95HxXhwXhW
|
|||
date: 2023-11-18
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/AkLsnieYpCU2UsSqUNrbMrQNi9bvdnjxx75mZbJns9z
|
|||
date: 2023-12-03
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/GPT8dFcpHfssMuULYKT9qERPY3heMoxwZHxgKgPw3TY
|
|||
date: 2023-12-16
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/9ABv3Phb44BNF4VFteSi9qcWEyABdnRqkorNuNtzdh2
|
|||
date: 2024-01-12
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/CF9QUBS251FnNGZHLJ4WbB2CVRi5BtqJbCqMi47NX1P
|
|||
date: 2024-01-24
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/HyA2h16uPQBFjezKf77wThNGsEoesUjeQf9rFvfAy4t
|
|||
date: 2024-02-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/US8j6iLf9GkokZbk89Bo1qnGBees5etv5sEfsfvCoZK
|
|||
date: 2024-02-13
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/E1FJAp8saDU6Da2ccayjLBfA53qbjKRNYvu7QiMAnjQ
|
|||
date: 2024-02-18
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/H59VHchVsy8UVLotZLs7YaFv2FqTH5HAeXc4Y48kxie
|
|||
date: 2024-02-18
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/J7dWFgSSuMg3BNZBAKYp3AD5D2yuaaLUmyKqvxBZgHh
|
|||
date: 2024-02-20
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/Dn638yPirR3e2UNNECpLNJApDhxsjhJTAv9uEd9LBVV
|
|||
date: 2024-02-26
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/ELwCkHt1U9VBpUFJ7qGoVMatEwLSr1HYj9q9t8JQ1Nc
|
|||
date: 2024-03-03
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/D9pGGmG2rCJ5BXzbDoct7EcQL6F6A57azqYHdpWJL9C
|
|||
date: 2024-03-13
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/5qEyKCVyJZMFZSb3yxh6rQjqDYxASiLW7vFuuUTCYnb
|
|||
date: 2024-03-19
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/BqMrwwZYdpbXNsfpcxxG2DyiQ7uuKB69PznPWZ33GrZ
|
|||
date: 2024-03-26
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/HXohDRKtDcXNKnWysjyjK8S5SvBe76J5o4NdcF4jj96
|
|||
date: 2024-03-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/BgHv9GutbnsXZLZQHqPL8BbGWwtcaRDWx82aeRMNmJb
|
|||
date: 2024-05-27
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/iPzWdGBZiHMT5YhR2m4WtTNbFW3KgExH2dRAsgWydPf
|
|||
date: 2024-05-27
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/9jAnAupCdPQCFvuAMr5ZkmxDdEKqsneurgvUnx7Az9z
|
|||
date: 2024-05-30
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/8AEsxyN8jhth5WQZHjU9kS3JcRHaUmpck7qZgpv2v4w
|
|||
date: 2024-05-30
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: null-result
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/BMZbX7z2zgLuq266yskeHF5BFZoaX9j3tvsZfVQ7RUY
|
|||
date: 2024-06-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/7KkoRGyvzhvzKjxuPHjyxg77a52MeP6axyx7aywpGbd
|
|||
date: 2024-06-08
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/4ztwWkz9TD5Ni9Ze6XEEj6qrPBhzdTQMfpXzZ6A8bGz
|
|||
date: 2024-06-14
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/DgXa6gy7nAFFWe8VDkiReQYhqe1JSYQCJWUBV8Mm6aM
|
|||
date: 2024-06-22
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/9BMRY1HBe61MJoKEd9AAW5iNQyws2vGK6vuL49oR3Az
|
|||
date: 2024-06-26
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/G95shxDXSSTcgi2DTJ2h79JCefVNQPm8dFeDzx7qZ2k
|
|||
date: 2024-07-01
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/Hda19mrjPxotZnnQfpAhJtxWvfC6JCXbMquohThgsd5
|
|||
date: 2024-07-01
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/16ZyAyNumkJoU9GATreUzBDzfS6rmEpZnUcQTcdfJiD
|
|||
date: 2024-07-01
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/EXehk1u3qUJZSxJ4X3nHsiTocRhzwq3eQAa6WKxeJ8X
|
|||
date: 2024-07-04
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/xU6tQoDh3Py4MfAY3YPwKnNLt7zYDiNHv8nA1qKnxVM
|
|||
date: 2024-07-09
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/BU8kQ7ECq8CJ9BHUZfYsjHFKPMGsF6oJn5d6b1tArdw
|
|||
date: 2024-07-18
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/5c2XSWQ9rVPge2Umoz1yenZcAwRaQS5bC4i4w87B1WU
|
|||
date: 2024-07-18
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/7AbivixQZTrgnqpmyxW2j1dd4Jyy15K3T2T7MEgfg8D
|
|||
date: 2024-08-03
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/J57DcV2yQGiDpSetQHui6Piwjwsbet2ozXVPG77kTvT
|
|||
date: 2024-08-14
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/yTiRuoXWQVdVgbUJBU6J3FF1Sxnzy7FW7osqkkfMK6G
|
|||
date: 2024-08-20
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/5TRuK9TLZ9bUPtp6od6pLKN6GxbQMByaBwVSCArNaS1
|
|||
date: 2024-08-20
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: null-result
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/AKMnVnSC8DzoZJktErtzR2QNt1ESoN8i2DdHPYuQTMG
|
|||
date: 2024-08-27
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/GugKjNpirFNaaRkEStRKGJPnutptsnTA3XuCJ8nwaVt
|
|||
date: 2024-08-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/8cnQAxS3WQXhD2eAjKSJ6wmBwaJskRZFYByMPKEhD1o
|
|||
date: 2024-08-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/eNPP3Tm4AAyDwq9N4BwJwBzFD14KXDSVY6bhMRaBuFt
|
|||
date: 2024-08-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC
|
|||
date: 2024-08-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/EmPUGgv2Utzuu2vgSu6GcTRAtJMox5vJeZKi95cBgfJ
|
|||
date: 2024-08-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/2LKqzegdHrcrrRCHSuTS2fMjjJuZDfzuRKMnzPhzeD4
|
|||
date: 2024-08-30
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/53EDms4zPkp4khbwBT3eXWhMALiMwssg7f5zckq22tH
|
|||
date: 2024-08-31
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/evGundfgMRZWCYsGF7GMKcgh6LjxDTFrvWRAhxiQS8h
|
|||
date: 2024-09-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: null-result
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/8SwPfzKhaZ2SQfgfJYfeVRTXALZs2qyFj7kX1dEkd29
|
|||
date: 2024-10-10
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/B82Dw1W6cfngH7BRukAyKXvXzP4T2cDsxwKYfxCftoC
|
|||
date: 2024-10-22
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/A19yLRVqxvUf4cTDm6mKNKadasd7YSYDrzk6AYEyubA
|
|||
date: 2024-10-22
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/Gp3ANMRTdGLPNeMGFUrzVFaodouwJSEXHbg5rFUi9ro
|
|||
date: 2024-10-30
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/HiNWH2uKxjrmqZjn9mr8vWu5ytp2Nsz6qLsHWa5XQ1V
|
|||
date: 2024-11-08
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/6LcxhHS3JvDtbS1GoQS18EgH5Pzf7AnqQpR7D4HxmWp
|
|||
date: 2024-11-13
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/ApywwMrE9vkWiatZwQVU6wdvNsHrYZkhegNCV5XDZ8y
|
|||
date: 2024-11-21
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/B4zpF4iHeF91qq8Szb9aD6pW1DrwSy6djD4QPWJQn3d
|
|||
date: 2024-11-21
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/zN9Uft1zEsh9h7Wspeg5bTNirBBvtBTaJ6i5KcEnbAb
|
|||
date: 2024-11-21
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/2QUxbiMkDtoKxY2u6kXuevfMsqKGtHNxMFYHVWbqRK1
|
|||
date: 2024-11-25
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/FXkyJpCVADXS6YZcz1Kppax8Kgih23t6yvze7ehELJp
|
|||
date: 2024-11-25
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/4gaJ8bi1gpNEx6xSSsepjVBM6GXqTDfLbiUbzXbARHW
|
|||
date: 2024-12-02
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/GBQZvZAeW8xUuVV5a9FJHSyttzY5fPGuvkwLTpWLbw6
|
|||
date: 2024-12-04
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/DhY2YrMde6BxiqCrqUieoKt5TYzRwf2KYE3J2RQyQc7
|
|||
date: 2024-12-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/C2Up9wYYJM1A94fgJz17e3Xsr8jft2qYMwrR6s4ckaK
|
|||
date: 2024-12-16
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/A74H61YqwsbwRczuErbUyh9kqG1A7ZbiE1W5hWZmT9f
|
|||
date: 2024-12-19
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/5V5MFN69yB2w82QWcWXyW84L3x881w5TanLpLnKAKyK
|
|||
date: 2024-12-30
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/CJW4iZPT14sVNzoc4Yibx1LbnY12sA75gZCP9HZk11U
|
|||
date: 2025-01-13
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/B8WLuXqoBb3hRD9XBCNuSqxDqCXCixqRdKR4pVFGzNP
|
|||
date: 2025-01-14
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/3tApJXw2REQAZZyehiaAnQSdauVNviNbXsuS4inn8PA
|
|||
date: 2025-01-27
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/CBhieBvzo5miQBrdaM7vALpgNLt4Q5XYCDfNLaE2wXJ
|
|||
date: 2025-01-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/7FY4dgYDX8xxwCczrgstUwuNEC9NMV1DWXz31rMnGNT
|
|||
date: 2025-02-03
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/DnDiyjAcmS3BNmNEJa2ydEbd6DgnddpkyVXJfngdRTz
|
|||
date: 2025-02-04
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/4BTTxsV98Rhm1qjDe2yPdXtj7j7KBSuGtVQ6rUNWjjX
|
|||
date: 2025-02-06
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/8qtWAAjqKhtEBJjdY6YzkN74yddTchH2vSc7f654NtQ
|
|||
date: 2025-02-10
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,16 +6,14 @@ url: "https://www.futard.io/proposal/AnCu4QFDmoGpebfAM8Aa7kViouAk1JW6LJCJJer6ELB
|
|||
date: 2025-02-10
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: processed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
processed_date: 2025-02-10
|
||||
enrichments_applied: ["futarchy-governed-DAOs-converge-on-traditional-corporate-governance-scaffolding-for-treasury-operations-because-market-mechanisms-alone-cannot-provide-operational-security-and-legal-compliance.md", "futarchy-implementations-must-simplify-theoretical-mechanisms-for-production-adoption-because-original-designs-include-impractical-elements-that-academics-tolerate-but-users-reject.md", "MetaDAO-is-the-futarchy-launchpad-on-Solana-where-projects-raise-capital-through-unruggable-ICOs-governed-by-conditional-markets-creating-the-first-platform-for-ownership-coins-at-scale.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
claims_extracted:
|
||||
- "shared-liquidity-amms-could-solve-futarchy-capital-inefficiency-by-routing-base-pair-deposits-into-all-derived-conditional-token-markets.md"
|
||||
extraction_notes: "Governance proposal data showing MetaDAO's operational evolution. One novel claim extracted: the shared-liquidity AMM concept for conditional markets (Proph3t + Hanson concept, not yet implemented). Remaining insights enrich existing claims about futarchy implementation, mechanism simplification, and MetaDAO's platform development. The proposal also demonstrates convergence on traditional advisory structures (Robin Hanson advisor hire via futarchy vote)."
|
||||
extraction_notes: "Governance proposal data showing MetaDAO's operational evolution. No novel claims—all insights enrich existing claims about futarchy implementation, mechanism simplification, and MetaDAO's platform development. The proposal demonstrates convergence on traditional advisory structures while iterating on futarchy mechanism design for capital efficiency."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/6TkkCy26HCqxWGt1QgfhFHc6ASikRjk74Gkk4Wfyd7w
|
|||
date: 2025-02-13
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/9ZYMaLKWn9PSLTX1entmqJUYBiCkZbRxeRz1tVvYwqy
|
|||
date: 2025-02-24
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/3rCNPg7wG1XCZBCWwjgjFgfhEySu2LhqeoU9KTUesTg
|
|||
date: 2025-02-24
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/HREoLZVrY5FHhPgBFXGGc6XAA3hPjZw1UZcahhumFke
|
|||
date: 2025-02-26
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/EksJ2GhxbmhVAdDKP4kThHiuzKwjhq5HSb1kgFj6x2Q
|
|||
date: 2025-03-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/8MMGMpLYnxH69j6YWCaLTqsYZuiFz61E5v2MSmkQyZZ
|
|||
date: 2025-03-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/HCHkdhiPh2q9LTyvUpfyfuybPHW7qg1T2vGtiJzGPrs
|
|||
date: 2025-03-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/6mc1Fp6ds8XKA2jMzBDDhVwvY6ZCGg6SNqvHy4E6LS7
|
|||
date: 2025-03-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/2frDGSg1frwBeh3bc6R7XKR2wckyMTt6pGXLGLPgoot
|
|||
date: 2025-03-28
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/2dvNKyxKzVuUMcd89wzfuYjX2RKbJps2Srqu4mJ7LEg
|
|||
date: 2025-04-22
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -7,14 +7,7 @@ date: 2025-04-25
|
|||
domain: entertainment
|
||||
secondary_domains: []
|
||||
format: article
|
||||
status: processed
|
||||
processed_by: clay
|
||||
processed_date: 2026-03-11
|
||||
claims_extracted:
|
||||
- creator-owned-streaming-infrastructure-has-reached-commercial-scale-with-430M-annual-creator-revenue-across-13M-subscribers
|
||||
- established-creators-generate-more-revenue-from-owned-streaming-subscriptions-than-from-equivalent-social-platform-ad-revenue
|
||||
- creator-owned-direct-subscription-platforms-produce-qualitatively-different-audience-relationships-than-algorithmic-social-platforms-because-subscribers-choose-deliberately
|
||||
enrichments: []
|
||||
status: unprocessed
|
||||
priority: high
|
||||
tags: [creator-economy, owned-distribution, vimeo, platform-infrastructure, dropout, sidemen, try-guys]
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/35mgLHTJYhyEWjsLHDd4jZNQ6jwuZ4E214TUm1hA8vB
|
|||
date: 2025-07-02
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/C61vTUyxTq5SWwbrTFEyYeXpGQLKhRRvRrGsu6YUa6C
|
|||
date: 2025-08-20
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@ tags: [alignment-gap, feedback-misspecification, reward-hacking, sycophancy, imp
|
|||
processed_by: theseus
|
||||
processed_date: 2026-03-11
|
||||
claims_extracted: ["feedback-misspecification-creates-exponential-sample-complexity-barrier-that-calibration-oracles-overcome.md", "alignment-gap-cannot-be-eliminated-but-can-be-mapped-bounded-and-managed-through-MAPS-framework.md"]
|
||||
enrichments_applied: ["emergent misalignment arises naturally from reward hacking as models develop deceptive behaviors without any training to deceive.md", "no research group is building alignment through collective intelligence infrastructure despite the field converging on problems that require it.md"]
|
||||
enrichments_applied: ["emergent misalignment arises naturally from reward hacking as models develop deceptive behaviors without any training to deceive.md", "AI alignment is a coordination problem not a technical problem.md", "no research group is building alignment through collective intelligence infrastructure despite the field converging on problems that require it.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Two novel formal results extracted: (1) exponential sample complexity from feedback misspecification, (2) calibration oracles as polynomial-time solution. Both map directly to collective intelligence architecture. Three enrichments connect to existing claims on emergent misalignment, RLHF/DPO failures, and collective intelligence gaps. The calibration oracle concept is the key bridge to our collective architecture — domain experts as calibration mechanisms."
|
||||
extraction_notes: "Two extractable claims: (1) exponential barrier + calibration oracle formal result, (2) MAPS framework for managing alignment gap. Three enrichments to existing claims about emergent misalignment, coordination-based alignment, and collective intelligence infrastructure gap. Strong connection to curator's note about calibration oracles mapping to collective architecture — this is a formal proof of why domain expert collectives provide structural advantage over single evaluators."
|
||||
---
|
||||
|
||||
## Content
|
||||
|
|
@ -60,7 +60,6 @@ EXTRACTION HINT: The exponential barrier + calibration oracle constructive resul
|
|||
|
||||
|
||||
## Key Facts
|
||||
- Sample complexity under misspecification: exp(n*alpha*epsilon^2) where alpha=frequency of problematic contexts, epsilon=bias strength, n=dimensionality
|
||||
- Calibration oracle sample complexity: O(1/(alpha*epsilon^2))
|
||||
- MAPS framework parameters: Misspecification, Annotation, Pressure, Shift
|
||||
- Paper published September 2025 by independent researcher Madhava Gaikwad
|
||||
- Core analogy: human feedback as broken compass that points wrong way in specific regions
|
||||
- Three key parameters: alpha (frequency of problematic contexts), epsilon (bias strength), gamma (degree of objective disagreement)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/launch/9kx7UDFzFt7e2V4pFtawnupKKvRR3EhV7P1Pxmc5XCQj"
|
|||
date: 2025-10-06
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/launch/2rYvdtK8ovuSziJuy5gTTPtviY5CfTnW6Pps4pk7ehEq"
|
|||
date: 2025-10-14
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/6c1dnggYNpEZvz4fedJ19LAo8Pz2mTTvT6LxySYhpLb
|
|||
date: 2025-10-15
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/launch/E7kXdSdZrjVFDkLb6V7S8VihKookPviRJ7tXVik9qbdu"
|
|||
date: 2025-10-18
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/launch/4h248CdXdeWtxWnHxEPqa5ruYZaEwXRZPyDFYnndbzpR"
|
|||
date: 2025-10-20
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: entity-data
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
processed_by: rio
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue