Compare commits
16 commits
b78a2b8f71
...
6707bd81af
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
6707bd81af | ||
| 4097f6c859 | |||
| 7b079f8c3c | |||
| 1ee2a08d71 | |||
| daf5f4062a | |||
|
|
81384819e6 | ||
|
|
aa0243699b | ||
|
|
6d946d34f3 | ||
|
|
1eb2844d20 | ||
|
|
6cee2eb84c | ||
|
|
ac068486dc | ||
| 28c4cbba63 | |||
| 48bc3682ef | |||
|
|
3397e518a9 | ||
|
|
a88af1bec7 | ||
|
|
f793686cc5 |
164 changed files with 514 additions and 164 deletions
|
|
@ -0,0 +1,39 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "MixDPO shows distributional β earns +11.2 win rate points on heterogeneous data at 1.02–1.1× cost, without needing demographic labels or explicit mixture models"
|
||||
confidence: experimental
|
||||
source: "Theseus via arXiv 2601.06180 (MixDPO: Modeling Preference Strength for Pluralistic Alignment, Jan 2026)"
|
||||
created: 2026-03-11
|
||||
depends_on:
|
||||
- "RLHF and DPO both fail at preference diversity because they assume a single reward function can capture context-dependent human values"
|
||||
- "pluralistic alignment must accommodate irreducibly diverse values simultaneously rather than converging on a single aligned state"
|
||||
---
|
||||
|
||||
# modeling preference sensitivity as a learned distribution rather than a fixed scalar resolves DPO diversity failures without demographic labels or explicit user modeling
|
||||
|
||||
Standard DPO uses a fixed scalar β to control how strongly preference signals shape training — one value for every example in the dataset. This works when preferences are homogeneous but fails when the training set aggregates genuinely different populations with different tolerance for value tradeoffs. Since [[RLHF and DPO both fail at preference diversity because they assume a single reward function can capture context-dependent human values]], fixed-β DPO is a special case of that failure: it assumes not just one reward function but one preference sensitivity level.
|
||||
|
||||
MixDPO (arXiv 2601.06180, January 2026) generalizes this by treating β as a random variable drawn from a learned distribution p(β), optimized jointly with policy parameters θ. Two distributional families are evaluated: LogNormal (estimated via Monte Carlo with K=16 samples) and Gamma (admits closed-form optimization via the Lerch transcendent). The learned distribution encodes dataset-level variance in preference strength — how much the population's certainty about preferences actually varies across comparison pairs.
|
||||
|
||||
**Empirical results:** On the PRISM dataset (high preference heterogeneity), MixDPO achieves +11.2 win rate points over standard DPO on Pythia-2.8B. Macro-averaged preference margins — which weight minority preferences equally to majority preferences — improve substantially while micro-averaged margins (dominated by majority views) remain competitive. This demonstrates that distributional β improves pluralistic coverage without degrading majority-preference performance. On the Anthropic HH dataset (low heterogeneity), the learned distribution converges to low variance and gains are minimal — the method self-adapts rather than forcing complexity where data doesn't support it.
|
||||
|
||||
**Computational cost:** LogNormal adds 1.02× overhead; Gamma adds 1.1×. Pluralistic alignment via distributional β is not a computationally expensive research luxury — it is a practical default.
|
||||
|
||||
**Why no demographic labels are needed:** Preference heterogeneity is a property of the comparison pairs themselves, not of annotator identity. The distribution learns to allocate high β to examples where the comparison signal is sharp and low β to examples where preferences are diffuse — without any access to who provided the preferences. This contrasts with approaches like PAL (Pluralistic Alignment via Learned Prototypes) that require explicit user-cluster modeling.
|
||||
|
||||
Since [[pluralistic alignment must accommodate irreducibly diverse values simultaneously rather than converging on a single aligned state]], MixDPO is one concrete mechanism for distributional pluralism — the third form in Sorensen et al's taxonomy — implemented at the level of training dynamics rather than model outputs or constitutional specification.
|
||||
|
||||
## Challenges
|
||||
|
||||
MixDPO has not yet been compared to PAL or RLCF in the paper, leaving open whether distributional β outperforms explicit mixture modeling on the same benchmarks. The +11.2 win rate result is from a single preprint on Pythia-2.8B and has not been replicated at larger scales or across multiple evaluators.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[RLHF and DPO both fail at preference diversity because they assume a single reward function can capture context-dependent human values]] — MixDPO is a constructive solution to this failure, not merely a diagnosis
|
||||
- [[pluralistic alignment must accommodate irreducibly diverse values simultaneously rather than converging on a single aligned state]] — distributional β implements the distributional pluralism form without explicit demographic modeling
|
||||
- [[collective intelligence requires diversity as a structural precondition not a moral preference]] — MixDPO preserves preference diversity structurally by encoding it in the training objective rather than averaging it out
|
||||
|
||||
Topics:
|
||||
- [[_map]]
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
type: claim
|
||||
domain: ai-alignment
|
||||
description: "MixDPO's learned β distribution serves dual purpose: it improves pluralistic alignment on heterogeneous data and converges to low variance on homogeneous data, making dataset diversity legible without demographic annotations"
|
||||
confidence: experimental
|
||||
source: "Theseus via arXiv 2601.06180 (MixDPO: Modeling Preference Strength for Pluralistic Alignment, Jan 2026)"
|
||||
created: 2026-03-11
|
||||
depends_on:
|
||||
- "modeling preference sensitivity as a learned distribution rather than a fixed scalar resolves DPO diversity failures without demographic labels or explicit user modeling"
|
||||
- "RLHF and DPO both fail at preference diversity because they assume a single reward function can capture context-dependent human values"
|
||||
---
|
||||
|
||||
# the variance of a learned preference sensitivity distribution diagnoses dataset heterogeneity and collapses to fixed-parameter behavior when preferences are homogeneous
|
||||
|
||||
Alignment methods that handle preference diversity create a design problem: when should you apply pluralistic training and when should you apply standard training? Requiring practitioners to audit their datasets for preference heterogeneity before training is a real barrier — most practitioners lack the demographic data or analytic tools to answer the question reliably.
|
||||
|
||||
MixDPO (arXiv 2601.06180) eliminates this requirement through a self-adaptive property. Because the preference sensitivity parameter β is learned as a distribution jointly with the policy, its variance at convergence encodes information about the dataset it was trained on:
|
||||
|
||||
- **High heterogeneity data (PRISM):** The learned distribution converges to high variance — β must range widely to account for the differing preference strengths across comparison pairs. The +11.2 win rate gain signals that this variance is informationally meaningful, not noise.
|
||||
- **Low heterogeneity data (Anthropic HH):** The learned distribution converges to low variance, approximating a point mass near the standard fixed-β value. Performance gains are minimal — consistent with the interpretation that there is no latent diversity for the distribution to capture.
|
||||
|
||||
This means the learned variance is a post-hoc diagnostic: train once with MixDPO, read the converged variance, and you know whether your dataset had diverse preferences. No demographic labels, no separate audit pipeline, no prior assumption about your data source. The method earns complexity when the data warrants it and collapses to simpler baseline behavior when it does not.
|
||||
|
||||
This self-adaptive collapse property has design implications beyond MixDPO. A well-designed pluralistic alignment method should have this property structurally: if your training data were actually homogeneous, the method should behave as if you had used the simpler approach. Methods that impose complexity regardless of data content add overhead without alignment benefit. The distributional β framework provides a formal instantiation of this principle.
|
||||
|
||||
The interpretability extension is underexplored in the paper: if β variance tracks real preference heterogeneity, it could serve as a dataset quality metric for pluralistic alignment — a way to compare datasets on the dimension of preference diversity without needing annotator identity or demographic composition.
|
||||
|
||||
## Challenges
|
||||
|
||||
The self-adaptive interpretation rests on a single paper's results across two contrasting datasets. Whether learned β variance generalizes as a reliable diversity diagnostic across domains and model scales has not been empirically tested. The MixDPO paper does not analyze the learned distributions in depth — the diagnostic interpretation is partially an inference from the convergence behavior.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[modeling preference sensitivity as a learned distribution rather than a fixed scalar resolves DPO diversity failures without demographic labels or explicit user modeling]] — the mechanism this claim describes the diagnostic property of
|
||||
- [[RLHF and DPO both fail at preference diversity because they assume a single reward function can capture context-dependent human values]] — learned variance provides empirical evidence of whether a dataset falls into this failure mode
|
||||
- [[pluralistic alignment must accommodate irreducibly diverse values simultaneously rather than converging on a single aligned state]] — self-adaptive collapse means pluralistic methods can be used safely even when diversity is unknown in advance
|
||||
|
||||
Topics:
|
||||
- [[_map]]
|
||||
|
|
@ -76,6 +76,25 @@ MycoRealms launch on Futardio demonstrates MetaDAO platform capabilities in prod
|
|||
|
||||
Futardio cult launch (2026-03-03 to 2026-03-04) demonstrates MetaDAO's platform supports purely speculative meme coin launches, not just productive ventures. The project raised $11,402,898 against a $50,000 target in under 24 hours (22,706% oversubscription) with stated fund use for 'fan merch, token listings, private events/partys'—consumption rather than productive infrastructure. This extends MetaDAO's demonstrated use cases beyond productive infrastructure (Myco Realms mushroom farm, $125K) to governance-enhanced speculative tokens, suggesting futarchy's anti-rug mechanisms appeal across asset classes.
|
||||
|
||||
|
||||
### Additional Evidence (extend)
|
||||
*Source: [[2025-12-00-colosseum-stamp-introduction]] | Added: 2026-03-11 | Extractor: anthropic/claude-sonnet-4.5*
|
||||
|
||||
**STAMP as MetaDAO's standardized investment instrument:**
|
||||
|
||||
STAMP is the legal and structural bridge between traditional VC fundraising and futarchy-governed ownership coins. Developed by Colosseum (MetaDAO's first VC investor) in partnership with law firm Orrick, STAMP provides the standardized investment contract for MetaDAO ICOs.
|
||||
|
||||
**Integration with MetaDAO infrastructure:**
|
||||
- Startups set up Cayman SPC/SP entities "through MetaDAO interface," suggesting MetaDAO provides legal infrastructure as a service
|
||||
- Remaining funds transfer to "DAO-controlled treasury" upon ICO launch, implying MetaDAO's futarchy governance takes control post-launch
|
||||
- STAMP provides "market-protected governance via MetaDAO's decision markets post-ICO"
|
||||
|
||||
**Ecosystem positioning:**
|
||||
Colosseum explicitly positions STAMP as "open-source, ecosystem-wide standard — not just for Colosseum," indicating intent to make it the default investment structure for all MetaDAO launches. This standardization is critical for scaling ownership coins: without a uniform legal instrument, each project would need custom legal work, creating friction and cost barriers.
|
||||
|
||||
**The private-to-public transition:**
|
||||
STAMP handles the private capital raise phase (pre-ICO), then hands governance to MetaDAO's conditional markets (post-ICO). The 20% investor cap + DAO-controlled treasury ensures that when governance transitions to futarchy, the treasury has sufficient capital and the community has sufficient token supply to make meaningful decisions.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
|
|
|
|||
|
|
@ -52,6 +52,22 @@ Critically, the proposal nullifies a prior 90-day restriction on buybacks/liquid
|
|||
|
||||
MycoRealms implements unruggable ICO structure with automatic refund mechanism: if $125,000 target not reached within 72 hours, full refunds execute automatically. Post-raise, team has zero direct treasury access — operates on $10,000 monthly allowance with all other expenditures requiring futarchy approval. This creates credible commitment: team cannot rug because they cannot access treasury directly, and investors can force liquidation through futarchy proposals if team materially misrepresents (e.g., fails to publish operational data to Arweave as promised, diverts funds from stated use). Transparency requirement (all invoices, expenses, harvest records, photos published to Arweave) creates verifiable baseline for detecting misrepresentation.
|
||||
|
||||
|
||||
### Additional Evidence (confirm)
|
||||
*Source: [[2025-12-00-colosseum-stamp-introduction]] | Added: 2026-03-11 | Extractor: anthropic/claude-sonnet-4.5*
|
||||
|
||||
**STAMP provides the legal structure that makes futarchy-governed liquidation enforceable:**
|
||||
|
||||
STAMP creates the three-layer enforcement stack that makes investor protection credible:
|
||||
|
||||
1. **Legal enforceability layer:** STAMP creates "legally enforceable claims on token supply during private-to-public transition." Investor allocations "cannot be diluted or reinterpreted later." This is enforced through the Cayman SPC/SP entity structure, which provides a legal wrapper that courts can recognize and enforce.
|
||||
|
||||
2. **Treasury availability layer:** Remaining balance automatically transfers to DAO-controlled treasury upon ICO launch. This ensures funds are available for liquidation if investors trigger it through futarchy governance. Pre-ICO funds are restricted to product development and operating expenses, preventing teams from depleting the treasury before the ICO.
|
||||
|
||||
3. **Governance trigger layer:** STAMP eliminates "post-hoc renegotiation risk" by making the token the sole economic unit. When the ICO goes live and governance transitions to futarchy, investors can propose liquidation through conditional markets if the team has materially misrepresented or failed to deliver.
|
||||
|
||||
The combination of legal structure (Cayman SPC) + treasury constraints (restricted spending) + governance mechanism (futarchy) creates credible investor protection that legacy ICOs lacked. Investors have both legal recourse (enforceable claims) and economic recourse (access to treasury funds through governance).
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,50 @@
|
|||
---
|
||||
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
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
---
|
||||
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]]
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "STAMP caps investor allocation at 20% and mandates DAO treasury control post-ICO, structurally preventing the extraction problem that killed legacy ICOs"
|
||||
confidence: experimental
|
||||
source: "Colosseum, Introducing the Colosseum STAMP (2025-12)"
|
||||
created: 2026-03-11
|
||||
depends_on:
|
||||
- "STAMP replaces SAFE plus token warrant by adding futarchy-governed treasury spending allowances that prevent the extraction problem that killed legacy ICOs"
|
||||
- "Legacy ICOs failed because team treasury control created extraction incentives that scaled with success"
|
||||
---
|
||||
|
||||
# STAMP investment instrument enforces 20 percent investor cap and DAO-controlled treasury to ensure community ownership from day one
|
||||
|
||||
The Colosseum STAMP (Simple Token Agreement, Market Protected) structurally prevents the extraction problem that killed legacy ICOs through two key mechanisms: a hard 20% cap on total investor allocation and mandatory transfer of remaining funds to DAO-controlled treasury upon ICO launch.
|
||||
|
||||
This is significantly more aggressive than typical crypto fundraising, where investors commonly receive 30-50% of total supply. The 20% cap ensures that at least 80% of tokens are available to the community and team (with team allocation separately capped at 10-40% based on milestones), making majority community ownership the default state rather than an aspiration.
|
||||
|
||||
The treasury control mechanism works by restricting pre-ICO funds to product development and operating expenses only. Any remaining balance automatically transfers to the DAO-controlled treasury when the ICO goes live, eliminating the team's ability to extract capital without governance approval. This is enforced through the Cayman SPC/SP entity structure and the STAMP legal agreement.
|
||||
|
||||
Investors receive their predetermined allocation through a 24-month linear unlock schedule starting at ICO launch, preventing immediate dumping while maintaining long-term alignment.
|
||||
|
||||
The instrument also mandates termination of all prior SAFEs and convertible notes upon signing, creating a clean break from traditional equity structures rather than layering token rights on top of existing cap tables. This "clean cap table consolidation" prevents the dual-structure conflicts that plagued earlier crypto fundraising attempts.
|
||||
|
||||
## Evidence
|
||||
|
||||
**From Colosseum STAMP announcement:**
|
||||
- "Investor cap: 20% maximum" — significantly below the 30-50% typical in crypto
|
||||
- "Remaining balance transfers to DAO-controlled treasury upon ICO" — eliminates team extraction post-launch
|
||||
- "Funds restricted to product development and operating expenses" — pre-ICO capital use is constrained
|
||||
- "Prior SAFEs/notes terminated and replaced upon signing" — forces clean migration
|
||||
- "24-month linear unlock schedule once ICO goes live" — prevents immediate investor dumping
|
||||
- "Team allocation: Milestone-based, 10-40% of total supply" — separate from investor cap
|
||||
|
||||
**Mechanism design rationale:**
|
||||
The 20% cap is not arbitrary — it ensures that even with maximum team allocation (40%), at least 40% of supply reaches public ICO participants. This creates a structural majority of non-insider ownership, making governance capture mathematically harder.
|
||||
|
||||
The DAO treasury transfer is the enforcement mechanism for futarchy-governed liquidation. If the team misrepresents or fails to deliver, investors can trigger liquidation through futarchy governance, and the treasury funds are available to return.
|
||||
|
||||
## Challenges
|
||||
|
||||
**Regulatory classification unclear:** The announcement mentions Orrick (top-tier tech law firm) as partner but provides no published legal opinion on STAMP's securities classification. The Cayman SPC structure suggests offshore domicile, which may weaken US regulatory defensibility compared to onshore structures.
|
||||
|
||||
**Single implementation:** This is Colosseum's first deployment of STAMP. The 20% cap and mandatory SAFE termination are untested in practice — we don't yet know if teams will accept these constraints or if investors will demand higher allocations.
|
||||
|
||||
**Enforcement mechanism unspecified:** While the STAMP creates "legally enforceable claims on token supply," the announcement doesn't detail the enforcement process if a team violates the treasury spending restrictions pre-ICO.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[STAMP replaces SAFE plus token warrant by adding futarchy-governed treasury spending allowances that prevent the extraction problem that killed legacy ICOs]]
|
||||
- [[Legacy ICOs failed because team treasury control created extraction incentives that scaled with success]]
|
||||
- [[futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible because investors can force full treasury return when teams materially misrepresent]]
|
||||
- [[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]]
|
||||
- [[domains/internet-finance/_map]]
|
||||
- [[core/mechanisms/_map]]
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
type: claim
|
||||
domain: internet-finance
|
||||
description: "STAMP eliminates the equity layer entirely, treating tokens as the only economic claim, which simplifies cap tables and removes equity-token conflicts"
|
||||
confidence: experimental
|
||||
source: "Colosseum, Introducing the Colosseum STAMP (2025-12)"
|
||||
created: 2026-03-11
|
||||
---
|
||||
|
||||
# STAMP treats token as sole economic unit eliminating dual equity token structure that produces subpar outcomes
|
||||
|
||||
The Colosseum STAMP investment instrument eliminates the dual equity-plus-token structure that has characterized crypto fundraising since SAFTs, treating the token as "the sole economic unit" with no parallel equity claims.
|
||||
|
||||
This is a structural departure from both SAFE+token warrant hybrids (which Colosseum explicitly states are "not sufficient for the next era") and SAFTs (which "left equity question unaddressed"). The dual structure creates conflicts because equity holders and token holders have different incentive profiles — equity holders want traditional exits (acquisition, IPO) while token holders want protocol growth and decentralization.
|
||||
|
||||
Colosseum argues these dual structures "produce subpar outcomes for crypto startups" without specifying the failure mode in the announcement, but the implication is clear: teams face competing pressures from two investor classes with misaligned objectives, and cap table complexity increases legal and governance overhead.
|
||||
|
||||
The STAMP resolves this by making tokens the only claim. Investors receive a predetermined token allocation (capped at 20% of total supply), teams receive milestone-based token allocations (10-40%), and there is no equity layer. The Cayman SPC/SP entity exists purely as a legal wrapper for the token treasury, not as an operating company with equity shareholders.
|
||||
|
||||
For existing startups with traditional equity cap tables, the STAMP enables migration through the Cayman entity structure. The announcement describes this as "clean cap table consolidation" — prior SAFEs and convertible notes are terminated and replaced with STAMP token allocations, eliminating the equity overhang.
|
||||
|
||||
## Evidence
|
||||
|
||||
**From Colosseum announcement:**
|
||||
- "STAMP treats token as 'the sole economic unit' — no dual structure"
|
||||
- "SAFE + token warrant hybrid is 'not sufficient for the next era' of crypto investing"
|
||||
- "SAFT left equity question unaddressed"
|
||||
- "Dual equity + token structure produces 'subpar outcomes for crypto startups'"
|
||||
- "For existing startups: Cayman entity enables migration from traditional equity to token-based ownership. Clean cap table consolidation."
|
||||
- "Prior SAFEs/notes terminated and replaced upon signing"
|
||||
|
||||
**Structural implications:**
|
||||
By eliminating equity, STAMP removes the exit optionality that traditional VCs rely on. There is no acquisition path that pays out equity holders — the only liquidity event is the token ICO and subsequent trading. This likely selects for investors who genuinely believe in protocol-native value capture rather than those hedging with equity upside.
|
||||
|
||||
The "clean cap table consolidation" for existing startups is particularly significant. Many crypto projects raised early equity rounds before pivoting to tokens, creating messy cap tables with both equity and token claims. STAMP forces a one-time conversion, which could be painful (equity holders must accept token allocations instead) but eliminates ongoing dual-structure conflicts.
|
||||
|
||||
## Challenges
|
||||
|
||||
**Investor acceptance unclear:** Traditional VCs are accustomed to equity with liquidation preferences, anti-dilution protection, and board seats. STAMP offers none of this — just a capped token allocation with a 24-month unlock. It's unclear whether top-tier VCs will accept these terms or if STAMP will primarily attract crypto-native funds.
|
||||
|
||||
**Valuation methodology unspecified:** If there's no equity and no traditional valuation, how is the token allocation priced? The announcement doesn't address this. Presumably it's negotiated based on projected token supply and market cap, but without equity comparables, pricing becomes more subjective.
|
||||
|
||||
**Migration friction for existing companies:** Terminating SAFEs and converting equity to tokens requires existing investor consent. If even one early investor refuses, the migration fails. The announcement presents this as a feature ("clean break") but it could be a dealbreaker for companies with complex cap tables.
|
||||
|
||||
---
|
||||
|
||||
Relevant Notes:
|
||||
- [[STAMP replaces SAFE plus token warrant by adding futarchy-governed treasury spending allowances that prevent the extraction problem that killed legacy ICOs]]
|
||||
- [[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]]
|
||||
- [[domains/internet-finance/_map]]
|
||||
- [[core/mechanisms/_map]]
|
||||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/9RisXkQCFLt7NA29vt5aWatcnU8SkyBgS95HxXhwXhW
|
|||
date: 2023-11-18
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: null-result
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,14 +6,16 @@ url: "https://www.futard.io/proposal/AnCu4QFDmoGpebfAM8Aa7kViouAk1JW6LJCJJer6ELB
|
|||
date: 2025-02-10
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: entity-data
|
||||
status: processed
|
||||
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"
|
||||
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."
|
||||
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)."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/6TkkCy26HCqxWGt1QgfhFHc6ASikRjk74Gkk4Wfyd7w
|
|||
date: 2025-02-13
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/35mgLHTJYhyEWjsLHDd4jZNQ6jwuZ4E214TUm1hA8vB
|
|||
date: 2025-07-02
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/launch/9kx7UDFzFt7e2V4pFtawnupKKvRR3EhV7P1Pxmc5XCQj"
|
|||
date: 2025-10-06
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
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: entity-data
|
||||
status: unprocessed
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
processed_by: rio
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/CFZzTU9YBc2ESa9jXeiYsq1sbN2vg346gUunA5NC3iC
|
|||
date: 2025-10-22
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: entity-data
|
||||
status: unprocessed
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/launch/13YpYe4k5GPaD2vZvvY7v7if31S1Wu8yWShkQs8MzLNh"
|
|||
date: 2025-10-23
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: entity-data
|
||||
status: unprocessed
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/G33HJH2J2zRqqcHZKMggkQurvqe1cmaDtfBz3hgmuuA
|
|||
date: 2025-11-07
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: entity-data
|
||||
status: unprocessed
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,10 +6,15 @@ url: https://www.blueorigin.com/news/new-glenn-launches-nasa-escapade-lands-full
|
|||
date: 2025-11-13
|
||||
domain: space-development
|
||||
secondary_domains: []
|
||||
format: article
|
||||
status: unprocessed
|
||||
format: report
|
||||
status: null-result
|
||||
priority: high
|
||||
tags: [blue-origin, new-glenn, reusability, booster-landing, mars, escapade, competition]
|
||||
processed_by: astra
|
||||
processed_date: 2026-03-11
|
||||
enrichments_applied: ["SpaceX vertical integration across launch broadband and manufacturing creates compounding cost advantages that no competitor can replicate piecemeal.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Extracted two claims: (1) Blue Origin's rapid achievement of booster landing demonstrates technology diffusion beyond SpaceX, and (2) patient capital as alternative path to reusability without vertical integration flywheel. Flagged enrichment challenging the SpaceX unreplicable advantages claim—Blue Origin achieved technical capability parity without the Starlink demand flywheel, though economic efficiency remains unproven. Key context: This is the strongest evidence to date that SpaceX single-player dependency in reusable launch is eroding. The 'second attempt' timeline is particularly significant—suggests fundamental engineering is now well-understood across industry."
|
||||
---
|
||||
|
||||
## Content
|
||||
|
|
@ -37,3 +42,13 @@ The same booster was planned for reuse on the NG-3 mission, targeted for late Fe
|
|||
PRIMARY CONNECTION: [[SpaceX vertical integration across launch broadband and manufacturing creates compounding cost advantages that no competitor can replicate piecemeal]]
|
||||
WHY ARCHIVED: Challenges the single-player dependency thesis — Blue Origin is now a demonstrated reusable launch provider without the Starlink flywheel
|
||||
EXTRACTION HINT: Focus on whether "no competitor can replicate piecemeal" still holds — Blue Origin replicated the booster landing capability without the demand flywheel, suggesting the flywheel claim may overstate the barrier
|
||||
|
||||
|
||||
## Key Facts
|
||||
- New Glenn NG-2 mission launched November 13, 2025
|
||||
- NG-2 deployed NASA ESCAPADE twin spacecraft to Mars transfer orbit (arrival September 2027)
|
||||
- Booster 'Never Tell Me the Odds' landed on Landing Platform Vessel Jacklyn, 375 miles offshore Atlantic
|
||||
- NG-1 (January 2025) reached orbit but booster failed to land
|
||||
- Blue Origin is second company after SpaceX to both deploy spacecraft to orbit and land booster
|
||||
- Blue Origin has received $14B+ investment from Jeff Bezos
|
||||
- Same booster planned for reuse on NG-3 mission (targeted late February 2026)
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue